date:20160810

On Friday, August 12, from approximately 21:00 to 23:00 UTC our
Mediawiki instance on wiki.openstack.org will be upgraded from its
present 1.25 pre-release to the latest 1.27 version. We're allotting
two hours in case issues are encountered with the upgrade requiring
us to roll back to a snapshot, but if all goes well the outage will
hopefully be much shorter.

JP Maxwell, who has worked through the upgrade plan over recent
weeks, set up a test instance for us at
https://wiki-upgrade-test.openstack.org/ where interested parties
can perform some preliminary tests over the next couple days and
help us catch any important features/extensions which are broken or
missing. Note this is running from a snapshot of the production
database, so will not reflect content changed at wiki.openstack.org.

Feel free to catch us in #openstack-infra or follow up to this
message if you have any concerns or want additional information on
this maintenance.
-- 
Jeremy Stanley

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

[openstack-dev] Brief Gerrit maintenance 20:00 UTC Friday, August 12

On Friday, August 12, at approximately 20:00 UTC our Gerrit service
on review.openstack.org will be restarted for some minor patch
updates and addition of a Storyboard integration plug-in. The outage
is anticipated to run less than 5 minutes, though could go slightly
longer if issues are encountered forcing us to roll back.

Feel free to catch us in #openstack-infra or follow up to this
message if you have any concerns or want additional information on
this maintenance.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [all][ptl][tc] extra ATCs for newton

On 2016-08-11 08:25:00 +1000 (+1000), Michael Still wrote:
[...]
> At the time I proposed it for the tools directory in the governance repo,
> but it never actually landed.
[...]

For reference: https://review.openstack.org/121730
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Watcher] Promote Alexchadin to the core team.

2016-08-10 Thread Prashanth Hari

+1

On Wed, Aug 10, 2016 at 4:13 AM, Antoine Cabot 
wrote:

> +1
>
> On Thu, Aug 4, 2016 at 9:29 AM, Vincent FRANÇOISE
>  wrote:
> > Alexander Chadin did prove he knew the various moving parts of Watcher
> > by participating the numerous design discussions and blueprints during
> > the last months which makes him a precious asset for our team.
> >
> > So that's a definite +1 for me as well.
> >
> >
> > On 04/08/2016 09:11, Jean-Émile DARTOIS wrote:
> >> Hi all,
> >>
> >> alexchadin has consistently contributed to Watcher for a while. He is
> >> also very active on IRC. Based on his contribution (e.g:
> >> continuously-optimization blueprint) and expertise which adds concrete
> >> value to Watcher, I’d like to promote alexchadin to the core team.
> >>
> >> According to the OpenStack Governance process [1], Please vote +1 or -1
> >> to the nomination.
> >>
> >> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> >>
> >> Best regards,
> >>
> >> jed56
> >>
> >>
> >> Jean-Emile
> >> DARTOIS
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 
> __
> >> OpenStack Development Mailing 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] [all][ptl][tc] extra ATCs for newton

2016-08-10 Thread Michael Still

On Thu, Aug 11, 2016 at 7:38 AM, Doug Hellmann 
wrote:

> Excerpts from Michael Still's message of 2016-08-11 07:27:07 +1000:
> > On Thu, Aug 11, 2016 at 7:12 AM, Doug Hellmann 
> > wrote:
> >
> > > Excerpts from Michael Still's message of 2016-08-11 07:01:37 +1000:
> > > > On Thu, Aug 11, 2016 at 2:24 AM, Doug Hellmann <
> d...@doughellmann.com>
> > > > wrote:
> > > >
> > > > > It's time to make sure we have all of our active technical
> contributors
> > > > > (ATCs) identified for Newton.
> > > > >
> > > > > Following the Foundation bylaws [1] and TC Charter [2], Project
> > > > > teams should identify contributors who have had a significant
> impact
> > > > > this cycle but who would not qualify for ATC status using the
> regular
> > > > > process because they have not submitted a patch.  Contributions
> > > > > might include, but aren't limited to, bug triage, design work, and
> > > > > documentation -- there is a lot of leeway in how teams define
> > > > > contribution for ATC status.
> > > > >
> > > > > The resulting list of names should be submitted as a patch to the
> > > > > "extra-atcs" section in openstack/governance/
> reference/projects.yaml
> > > > > for review by the TC.
> > > > >
> > > > > Although extra ATCs can be nominated at any point, there is a
> > > > > deadline to be included in the electorate for the next release
> > > > > cycle. The ATC list needs to be approved by the TC by 25 Aug, and
> > > > > in order to appear on the TC agenda to be discussed, the proposals
> > > > > need to be submitted by 16 Aug.
> > > > >
> > > > > PTLs can delegate preparing the patch to the governance
> repository, but
> > > > > please +1 the patch indicating that you agree with the list to
> avoid
> > > > > delays in the TC review.
> > > > >
> > > >
> > > > I have a script to generate this that I wrote while Nova PTL. For
> > > example:
> > > >
> > > > ~/src/openstack/nova$ /home/mikal/src/mikalstill/
> > > hacks/tools/extra-atcs.py
> > > > --since=2016-04-01 --expires="September 2017" --program "Compute"
> > >
> > > What data is that pulling?
> > >
> >
> > It is parsing the git commit log for examples of "Co-authored-by"
> entries,
> > and filtering away those where the person also has a primary commit. IIRC
> > last time I did this for real I needed to check that each person was
> also a
> > foundation member, but that was manual as there was no API at the time.
>
> Nice, that sounds like it would be useful to more teams.


At the time I proposed it for the tools directory in the governance repo,
but it never actually landed. The code is at if people want to borrow.
Consider it under the Apache license.

Michael

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

Re: [openstack-dev] [all][ptl][tc] extra ATCs for newton

On 2016-08-11 07:01:37 +1000 (+1000), Michael Still wrote:
> I have a script to generate this that I wrote while Nova PTL.
[...]

Note that, as one requirement for ATC status is being a current
OpenStack Foundation Individual Member, there is still the manual
step of confirming that for each potential extra-ATC.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [all][ptl][tc] extra ATCs for newton

Excerpts from Michael Still's message of 2016-08-11 07:27:07 +1000:
> On Thu, Aug 11, 2016 at 7:12 AM, Doug Hellmann 
> wrote:
> 
> > Excerpts from Michael Still's message of 2016-08-11 07:01:37 +1000:
> > > On Thu, Aug 11, 2016 at 2:24 AM, Doug Hellmann 
> > > wrote:
> > >
> > > > It's time to make sure we have all of our active technical contributors
> > > > (ATCs) identified for Newton.
> > > >
> > > > Following the Foundation bylaws [1] and TC Charter [2], Project
> > > > teams should identify contributors who have had a significant impact
> > > > this cycle but who would not qualify for ATC status using the regular
> > > > process because they have not submitted a patch.  Contributions
> > > > might include, but aren't limited to, bug triage, design work, and
> > > > documentation -- there is a lot of leeway in how teams define
> > > > contribution for ATC status.
> > > >
> > > > The resulting list of names should be submitted as a patch to the
> > > > "extra-atcs" section in openstack/governance/reference/projects.yaml
> > > > for review by the TC.
> > > >
> > > > Although extra ATCs can be nominated at any point, there is a
> > > > deadline to be included in the electorate for the next release
> > > > cycle. The ATC list needs to be approved by the TC by 25 Aug, and
> > > > in order to appear on the TC agenda to be discussed, the proposals
> > > > need to be submitted by 16 Aug.
> > > >
> > > > PTLs can delegate preparing the patch to the governance repository, but
> > > > please +1 the patch indicating that you agree with the list to avoid
> > > > delays in the TC review.
> > > >
> > >
> > > I have a script to generate this that I wrote while Nova PTL. For
> > example:
> > >
> > > ~/src/openstack/nova$ /home/mikal/src/mikalstill/
> > hacks/tools/extra-atcs.py
> > > --since=2016-04-01 --expires="September 2017" --program "Compute"
> >
> > What data is that pulling?
> >
> 
> It is parsing the git commit log for examples of "Co-authored-by" entries,
> and filtering away those where the person also has a primary commit. IIRC
> last time I did this for real I needed to check that each person was also a
> foundation member, but that was manual as there was no API at the time.

Nice, that sounds like it would be useful to more teams.

Doug

> 
> > > Compute: Sonu (sonu.sudhaka...@gmail.com) [September 2017]
> > > Compute: Ahilan Rajadeva (rajad...@us.ibm.com) [September 2017]
> > > Compute: Qiaowei Ren (qiaowei@intel.com) [September 2017]
> > > Compute: Xiaowei Qian (xiaowei.q...@easystack.cn) [September 2017]
> > > Compute: Alin Balutoiu (abalut...@cloudbasesolutions.com) [September
> > 2017]
> > > Compute: Eli Qiao (qiaoliy...@gmail.com) [September 2017]
> > > Compute: Feodor Tersin (fter...@hotmail.com) [September 2017]
> > > Compute: Samuel Matzek (smat...@us.ibm.com) [September 2017]
> > > Compute: Raghuveer Shenoy (rshe...@hp.com) [September 2017]
> > > Compute: Bartosz Fic (bartosz@intel.com) [September 2017]
> > > Compute: Dmitry Guryanov (dgurya...@parallels.com) [September 2017]
> >
> > The format is different now (it goes in the YAML file instead of
> > stand-alone) but the data is the same so it should be easy to adapt the
> > output.
> >
> > Doug
> >
> > >
> > > Matt -- if that's useful feel free to base a governance review on it.
> >
> 
> Michael
> 

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

Re: [openstack-dev] [all][ptl][tc] extra ATCs for newton

2016-08-10 Thread Michael Still

On Thu, Aug 11, 2016 at 7:12 AM, Doug Hellmann 
wrote:

> Excerpts from Michael Still's message of 2016-08-11 07:01:37 +1000:
> > On Thu, Aug 11, 2016 at 2:24 AM, Doug Hellmann 
> > wrote:
> >
> > > It's time to make sure we have all of our active technical contributors
> > > (ATCs) identified for Newton.
> > >
> > > Following the Foundation bylaws [1] and TC Charter [2], Project
> > > teams should identify contributors who have had a significant impact
> > > this cycle but who would not qualify for ATC status using the regular
> > > process because they have not submitted a patch.  Contributions
> > > might include, but aren't limited to, bug triage, design work, and
> > > documentation -- there is a lot of leeway in how teams define
> > > contribution for ATC status.
> > >
> > > The resulting list of names should be submitted as a patch to the
> > > "extra-atcs" section in openstack/governance/reference/projects.yaml
> > > for review by the TC.
> > >
> > > Although extra ATCs can be nominated at any point, there is a
> > > deadline to be included in the electorate for the next release
> > > cycle. The ATC list needs to be approved by the TC by 25 Aug, and
> > > in order to appear on the TC agenda to be discussed, the proposals
> > > need to be submitted by 16 Aug.
> > >
> > > PTLs can delegate preparing the patch to the governance repository, but
> > > please +1 the patch indicating that you agree with the list to avoid
> > > delays in the TC review.
> > >
> >
> > I have a script to generate this that I wrote while Nova PTL. For
> example:
> >
> > ~/src/openstack/nova$ /home/mikal/src/mikalstill/
> hacks/tools/extra-atcs.py
> > --since=2016-04-01 --expires="September 2017" --program "Compute"
>
> What data is that pulling?
>

It is parsing the git commit log for examples of "Co-authored-by" entries,
and filtering away those where the person also has a primary commit. IIRC
last time I did this for real I needed to check that each person was also a
foundation member, but that was manual as there was no API at the time.


> > Compute: Sonu (sonu.sudhaka...@gmail.com) [September 2017]
> > Compute: Ahilan Rajadeva (rajad...@us.ibm.com) [September 2017]
> > Compute: Qiaowei Ren (qiaowei@intel.com) [September 2017]
> > Compute: Xiaowei Qian (xiaowei.q...@easystack.cn) [September 2017]
> > Compute: Alin Balutoiu (abalut...@cloudbasesolutions.com) [September
> 2017]
> > Compute: Eli Qiao (qiaoliy...@gmail.com) [September 2017]
> > Compute: Feodor Tersin (fter...@hotmail.com) [September 2017]
> > Compute: Samuel Matzek (smat...@us.ibm.com) [September 2017]
> > Compute: Raghuveer Shenoy (rshe...@hp.com) [September 2017]
> > Compute: Bartosz Fic (bartosz@intel.com) [September 2017]
> > Compute: Dmitry Guryanov (dgurya...@parallels.com) [September 2017]
>
> The format is different now (it goes in the YAML file instead of
> stand-alone) but the data is the same so it should be easy to adapt the
> output.
>
> Doug
>
> >
> > Matt -- if that's useful feel free to base a governance review on it.
>

Michael

-- 
Rackspace Australia
__
OpenStack Development Mailing 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] [Cinder] Pending removal of Scality volume driver

2016-08-10 Thread Nicolas Trangez

Sean and team,

On Wed, 2016-08-03 at 08:55 -0300, Erlon Cruz wrote:
> Hi sean, I think it would worth to CC the contact info informed in
> the CI
> Wiki (openstack...@scality.com).
> 
> On Tue, Aug 2, 2016 at 4:26 PM, Sean McGinnis 
> wrote:
> 
> > 
> > Tomorrow is the one week grace period. I just ran the last comment
> > script and it still shows it's been 112 days since the Scality CI
> > has
> > reported on a patch.
> > 
> > Please let me know the status of the CI.

Sadly enough, we have been unable to resolve the recent issues in the
system/lab backing our CI server (originally caused by some hardware
migrations), and it's unclear when this would be back in a stable
state. We consider moving to a different service, which would require a
re-install of the CI system (which, given the development on Zuul and
related services since we set it up, may be a healthy thing to do
anyway).

In order to play by the rules of the Cinder community, we propose our
driver to be temporarily removed from the tree, until we get this CI
situation resolved. We are confident the Scality volume driver is in
working shape and is not to be removed for bug/technical reasons. As
such we'll aim for re-inclusion as soon as we get a stable Cinder CI
environment up and running again.

I filed https://review.openstack.org/#/c/353739/ to handle all of this.

Thank you,

Nicolas

-- 

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

Re: [openstack-dev] [all][ptl][tc] extra ATCs for newton

Excerpts from Michael Still's message of 2016-08-11 07:01:37 +1000:
> On Thu, Aug 11, 2016 at 2:24 AM, Doug Hellmann 
> wrote:
> 
> > It's time to make sure we have all of our active technical contributors
> > (ATCs) identified for Newton.
> >
> > Following the Foundation bylaws [1] and TC Charter [2], Project
> > teams should identify contributors who have had a significant impact
> > this cycle but who would not qualify for ATC status using the regular
> > process because they have not submitted a patch.  Contributions
> > might include, but aren't limited to, bug triage, design work, and
> > documentation -- there is a lot of leeway in how teams define
> > contribution for ATC status.
> >
> > The resulting list of names should be submitted as a patch to the
> > "extra-atcs" section in openstack/governance/reference/projects.yaml
> > for review by the TC.
> >
> > Although extra ATCs can be nominated at any point, there is a
> > deadline to be included in the electorate for the next release
> > cycle. The ATC list needs to be approved by the TC by 25 Aug, and
> > in order to appear on the TC agenda to be discussed, the proposals
> > need to be submitted by 16 Aug.
> >
> > PTLs can delegate preparing the patch to the governance repository, but
> > please +1 the patch indicating that you agree with the list to avoid
> > delays in the TC review.
> >
> 
> I have a script to generate this that I wrote while Nova PTL. For example:
> 
> ~/src/openstack/nova$ /home/mikal/src/mikalstill/hacks/tools/extra-atcs.py
> --since=2016-04-01 --expires="September 2017" --program "Compute"

What data is that pulling?

> Compute: Sonu (sonu.sudhaka...@gmail.com) [September 2017]
> Compute: Ahilan Rajadeva (rajad...@us.ibm.com) [September 2017]
> Compute: Qiaowei Ren (qiaowei@intel.com) [September 2017]
> Compute: Xiaowei Qian (xiaowei.q...@easystack.cn) [September 2017]
> Compute: Alin Balutoiu (abalut...@cloudbasesolutions.com) [September 2017]
> Compute: Eli Qiao (qiaoliy...@gmail.com) [September 2017]
> Compute: Feodor Tersin (fter...@hotmail.com) [September 2017]
> Compute: Samuel Matzek (smat...@us.ibm.com) [September 2017]
> Compute: Raghuveer Shenoy (rshe...@hp.com) [September 2017]
> Compute: Bartosz Fic (bartosz@intel.com) [September 2017]
> Compute: Dmitry Guryanov (dgurya...@parallels.com) [September 2017]

The format is different now (it goes in the YAML file instead of
stand-alone) but the data is the same so it should be easy to adapt the
output.

Doug

> 
> Matt -- if that's useful feel free to base a governance review on it.
> 
> Michael
> 

__
OpenStack Development Mailing 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] near term gate optimization opportunity

Based on reading some logs, it looks like requirements updates are
getting regenerated on every requirements land for all open patches,
even if they aren't impacted by it -
https://review.openstack.org/#/c/351991/

patch 10,11,12 in that series are just rebases, all happening within a
couple of hours.

With the check queue at ... 505 changes as of this email, this is
definitely adding some extra load to the system.

It would be a great optimization for someone to look at the script -
https://github.com/openstack-infra/project-config/blob/ab89ab40ed74db306ce10e36341d39f23231f012/jenkins/scripts/propose_update.sh
and make it so that if the commit did not change, don't push a rebased
review.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [all][ptl][tc] extra ATCs for newton

2016-08-10 Thread Michael Still

On Thu, Aug 11, 2016 at 2:24 AM, Doug Hellmann 
wrote:

> It's time to make sure we have all of our active technical contributors
> (ATCs) identified for Newton.
>
> Following the Foundation bylaws [1] and TC Charter [2], Project
> teams should identify contributors who have had a significant impact
> this cycle but who would not qualify for ATC status using the regular
> process because they have not submitted a patch.  Contributions
> might include, but aren't limited to, bug triage, design work, and
> documentation -- there is a lot of leeway in how teams define
> contribution for ATC status.
>
> The resulting list of names should be submitted as a patch to the
> "extra-atcs" section in openstack/governance/reference/projects.yaml
> for review by the TC.
>
> Although extra ATCs can be nominated at any point, there is a
> deadline to be included in the electorate for the next release
> cycle. The ATC list needs to be approved by the TC by 25 Aug, and
> in order to appear on the TC agenda to be discussed, the proposals
> need to be submitted by 16 Aug.
>
> PTLs can delegate preparing the patch to the governance repository, but
> please +1 the patch indicating that you agree with the list to avoid
> delays in the TC review.
>

I have a script to generate this that I wrote while Nova PTL. For example:

~/src/openstack/nova$ /home/mikal/src/mikalstill/hacks/tools/extra-atcs.py
--since=2016-04-01 --expires="September 2017" --program "Compute"
Compute: Sonu (sonu.sudhaka...@gmail.com) [September 2017]
Compute: Ahilan Rajadeva (rajad...@us.ibm.com) [September 2017]
Compute: Qiaowei Ren (qiaowei@intel.com) [September 2017]
Compute: Xiaowei Qian (xiaowei.q...@easystack.cn) [September 2017]
Compute: Alin Balutoiu (abalut...@cloudbasesolutions.com) [September 2017]
Compute: Eli Qiao (qiaoliy...@gmail.com) [September 2017]
Compute: Feodor Tersin (fter...@hotmail.com) [September 2017]
Compute: Samuel Matzek (smat...@us.ibm.com) [September 2017]
Compute: Raghuveer Shenoy (rshe...@hp.com) [September 2017]
Compute: Bartosz Fic (bartosz@intel.com) [September 2017]
Compute: Dmitry Guryanov (dgurya...@parallels.com) [September 2017]

Matt -- if that's useful feel free to base a governance review on it.

Michael

-- 
Rackspace Australia
__
OpenStack Development Mailing 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] static Portgroup support.

2016-08-10 Thread Devananda van der Veen

On 08/09/2016 01:28 AM, Vasyl Saienko wrote:
> Hello Ironic'ers!
> 
> We've recorded a demo that shows how static portgroup works at the moment:
> 
> Flat network scenario: https://youtu.be/vBlH0ie6Lm4
> Multitenant network scenario: https://youtu.be/Kk5Cc_K1tV8

Awesome! Thank you for creating & sharing these demos!

--deva

> 
> Sincerely,
> Vasyl Saienko
> 
> On Tue, Jul 19, 2016 at 3:30 PM, Vasyl Saienko  > wrote:
> 
> Hello Community,
> 
> Current portgroup scenario is not fully clear for me. The related spec [3]
> doesn't clearly describe it. And based on implementation [1] and [2] I 
> guess
> it should work in the following fashion for node with 3 NICs, where eth1 
> and
> eth2 are members of Porgroup Po0/1
> 
> Node network connection info:
> eth1 (aa:bb:cc:dd:ee:f1) <---> Gig0/1
> eth2 (aa:bb:cc:dd:ee:f2) <---> Gig0/2
> eth3 (aa:bb:cc:dd:ee:f3) <---> Gig0/3
>  
> For FLAT network scenario:
> 1. Administrator enrol ironic node.
> 2. Administrator creates a 3 ports for each interface, and a portgroup 
> that
> contains eth0 and eth1 ports.
> 3. The ports Gig0/1 and Gig0/2 are added to portgroup Po0/1 manually on 
> the
> switch.
> 4. When user request to boot an instance, Nova randomly picks interface 
> [2],
> it might be a portgroup or single NIC interface. Proposed change [1] do 
> not
> allow to specify what exactly network type we would like to use single NIC
> or portgroup.
> 
> For multitenancy case:
> All looks the same, in addition administrator adds local_link_connection
> information for each port (local_link_connection 'port_id' field is 
> 'Gig0/1'
> for eth1, 'Gig0/2' for eth2 and 'Gig0/3' for eth3, ). Ironic send this
> information to Neutron who plugs ports to needed network.
> 
> The same user-scenario is available at the moment without any changes to
> Nova or Ironic. The difference is that administrator creates one port for
> single interface eth3 with local_link_connection 'port_id'='Gig0/3',  and 
> a
> port that is a logical representation of portgroup (eth1 and eth2) with
> local_link_connection 'port_id'='Po0/1'. 
> 
> Please let me know if I've missed something or misunderstood current
> portgroup scenario.
> 
> Reference:
> [0] https://review.openstack.org/206163 
> 
> [1] https://review.openstack.org/332177 
> 
> [2]
> 
> https://github.com/openstack/nova/blob/06c537fbe5bb4ac5a3012642c899df815872267c/nova/network/neutronv2/api.py#L270
> 
> 
> [3]
> 
> https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.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

Re: [openstack-dev] [requirements] History lesson please

On Tue, Aug 9, 2016 at 11:54 AM, Hayes, Graham  wrote:

>
> It might not make a difference to deployers / packagers who only deploy
> one project from OpenStack, but they are in the minority - having a
> known good minimum for requirements helps deployers who have multiple
> services to deploy.
>

I'm not sure how true that is.  I think in the largest cloud organizations
the different cloud services are managed by different teams that are
working hard to deliver a stable, well tested, continuously deployed,
*service* that is always rapidly approaching tracking master.

In these organizations it may be that the team ultimately fully responsible
for the successful quality and availability of just a *single* service -
doesn't need to *test* and deploy with the next new minor version of routes
(if their requirements don't mandate it) just to get out the next bug fix -
because they're not *trying* to co-install *all* the services onto a
homogenous fleet?

Even if these kind of teams were let's say... a non-trivial minority... I
don't think their needs should be *ignored*.  I agree with John & Thomas
and am excited to hear about Tony's effort.

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

Re: [openstack-dev] [octavia] Multi-node controller testing

2016-08-10 Thread Stephen Balukoff

Miguel--

There have been a number of tempest patches in the review queue for a long
time now, but I think the reason they're not getting attention is that we
don't want to have to import a massive amount of tempest code into our
repository (which will become stale and need hot-fixing, as has happened
with neutron-lbaas on many occasions), and it appears tempest-lib doesn't
yet support all the stuff we would need to do with it.

People have suggested Rally, but so far nobody has come forth with code, or
a strong desire to push it through.

Stephen

On Tue, Aug 9, 2016 at 5:40 AM, Miguel Angel Ajo Pelayo  wrote:

> On Mon, Aug 8, 2016 at 4:56 PM, Kosnik, Lubosz 
> wrote:
> > Great work with that multi-node setup Miguel.
>
> Thanks, I have to get my hands dirtier with octavia, it's just a tiny
> thing.
>
> > About that multinode Infra is supporting two nodes setup used currently
> by grenade jobs but in my opinion we don’t have any tests which can cover
> that type of testing. We’re still struggling with selecting proper tool to
> test Octavia from integration/functional perspective so probably it’s too
> early to make it happen.
>
>
> Well, any current tests we run should pass equally well in a multi
> node controller, and that's the point, that, regardless of the
> deployment architecture the behaviour shall not change at all. We may
> not need any specific test.
>
>
> > Maybe it’s great start to finally make some decision about testing tools
> and there will be a lot of work for you after that also with setting up an
> infra multi-node job for that.
>
> I'm not fully aware of what are we running today for octavia, so if
> you can give me some pointers about where are those jobs configured,
> and what do they target, it could be a start, to provide feedback.
>
> What are the current options/tools we're considering?
>
>
> >
> > Cheers,
> > Lubosz Kosnik
> > Cloud Software Engineer OSIC
> > lubosz.kos...@intel.com
> >
> >> On Aug 8, 2016, at 7:04 AM, Miguel Angel Ajo Pelayo <
> majop...@redhat.com> wrote:
> >>
> >> Recently, I sent a series of patches [1] to make it easier for
> >> developers to deploy a multi node octavia controller with
> >> n_controllers x [api, cw, hm, hk] with an haproxy in front of the API.
> >>
> >> Since this is the way the service is designed to work (with horizontal
> >> scalability in mind), and we want to have a good guarantee that any
> >> bug related to such configuration is found early, and addressed, I was
> >> thinking that an extra job that runs a two node controller deployment
> >> could be beneficial for the project.
> >>
> >>
> >> If we all believe it makes sense, I would be willing to take on this
> >> work but I'd probably need some pointers and light help, since I've
> >> never dealt with setting up or modifying existing jobs.
> >>
> >> How does this sound?
> >>
> >>
> >> [1] https://review.openstack.org/#/q/status:merged+project:
> openstack/octavia+branch:master+topic:multinode-devstack
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [api] [doc] API status report

2016-08-10 Thread Anne Gentle

Hi all,
I wanted to report on status and answer any questions you all have about
the API reference and guide publishing process.

The expectation is that we provide all OpenStack API information on
developer.openstack.org. In order to meet that goal, it's simplest for now
to have all projects use the RST+YAML+openstackdocstheme+os-api-ref
extension tooling so that users see available OpenStack APIs in a sidebar
navigation drop-down list.

--Migration--
The current status for migration is that all WADL content is migrated
except for trove. There is a patch in progress and I'm in contact with the
team to assist in any way. https://review.openstack.org/#/c/316381/

--Theme, extension, release requirements--
The current status for the theme, navigation, and Sphinx extension tooling
is contained in the latest post from Graham proposing a solution for the
release number switchover and offers to help teams as needed:
http://lists.openstack.org/pipermail/openstack-dev/2016-August/101112.html
I hope to meet the requirements deadline to get those changes landed.
Requirements freeze is Aug 29.

--Project coverage--
The current status for project coverage is that these projects are now
using the RST+YAML in-tree workflow and tools and publishing to
http://developer.openstack.org/api-ref/ so they will be
included in the upcoming API navigation sidebar intended to span all
OpenStack APIs:

designate http://developer.openstack.org/api-ref/dns/
glance http://developer.openstack.org/api-ref/image/
heat http://developer.openstack.org/api-ref/orchestration/
ironic http://developer.openstack.org/api-ref/baremetal/
keystone http://developer.openstack.org/api-ref/identity/
manila http://developer.openstack.org/api-ref/shared-file-systems/
neutron-lib http://developer.openstack.org/api-ref/networking/
nova http://developer.openstack.org/api-ref/compute/
sahara http://developer.openstack.org/api-ref/data-processing/
senlin http://developer.openstack.org/api-ref/clustering/
swift http://developer.openstack.org/api-ref/object-storage/
zaqar http://developer.openstack.org/api-ref/messaging/

These projects are using the in-tree workflow and common tools, but do not
have a publish job in project-config in the jenkins/jobs/projects.yaml file.

ceilometer

--Projects not using common tooling--
These projects have API docs but are not yet using the common tooling, as
far as I can tell. Because of the user experience, I'm making a judgement
call that these cannot be included in the common navigation. I have patched
the projects.yaml file in the governance repo with the URLs I could
screen-scrape, but if I'm incorrect please do patch the projects.yaml in
the governance repo.

astara
cloudkitty
congress
magnum
mistral
monasca
solum
tacker
trove

Please reach out if you have questions or need assistance getting started
with the new common tooling, documented here:
http://docs.openstack.org/contributor-guide/api-guides.html.

For searchlight, looking at http://developer.openstack.org/api-ref/search/
they have the build job, but the info is not complete yet.

One additional project I'm not sure what to do with is networking-nfc,
since I'm not sure it is considered a neutron API. Can I get help to sort
that question out?

--Redirects from old pages--
We have been adding .htaccess redirects from the old
api-ref-servicename.html on developer.openstack.org as teams are
comfortable with the accuracy of information and build stability. Please
help out by patching the api-site repository's .htaccess file when you are
ready to redirect. These projects could be ready for redirects but do not
have them:

designate
glance
heat
sahara
senlin
swift

I'm available for questions so please reach out as needed. I hope this
covers our current status.

A million thank yous to everyone who got us this far! Great teamwork, great
docs work, great UI work, and great API work everyone.
Anne

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

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

On Wed, Aug 10, 2016 at 10:57 AM, Matthew Treinish 
wrote:

>
> http://specs.openstack.org/openstack/qa-specs/specs/tempest/implemented/
> branchless-tempest.html
>
>
>
This was actually a *great* read, thanks for that link!

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

[openstack-dev] [TripleO] additional git repo(s) for tripleo-quickstart

2016-08-10 Thread Wesley Hayutin

Greetings,

In an effort to make TripleO CI composable and managed and governed by the
TripleO project we have  found the need to create additional git repos in
openstack under the TripleO project.  This could also be done outside of
the TripleO project, but ideally it's in TripleO.

I'm proposing the creation of a repo called tripleo-quickstart-extras that
would contain some or all of the current third party roles used with
TripleO-Quickstart.

The context behind this discussion is that we would like to use oooq to
document baremetal deployments to supplement and or replace the current
TripleO documentation.  It would be ideal of the code used to create this
documentation was part of the TripleO project.

We're looking for discussion and permission for a new TripleO git repo to
be created.

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

[openstack-dev] [tc] Storlets to become official - Proposed governance change

2016-08-10 Thread eran


https://review.openstack.org/353693

Thanks!
Eran


__
OpenStack Development Mailing 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] App Catalog IRC meeting Thursday August 11th

2016-08-10 Thread Christopher Aedo

Join us Thursday for our weekly meeting, scheduled for August 11th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Tomorrow we will be talking more about the next steps we will be
taking in implementing GLARE as a back-end for the Community App
Catalog.

Hope to see you there tomorrow!

__
OpenStack Development Mailing 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] [neutron] Feature Classification

2016-08-10 Thread Armando M.

On 10 August 2016 at 10:20, Gupta, Ankur  wrote:

> Hello Neutrinos,
>
>
>
> One of the things, that is required to have ease of use, is good
> documentation.
>
> Similar to what's done for Nova [4], I've decided to prepare Feature
> Classification for Neutron.
>
> Work was already approved, and it got greenlit [1], but we still lack of
> final approval. In the light of N-3 [5] approaching, it would be nice to
> have it merged sooner than later.
>
>
>
> What's Feature Matrix Classification?
>
> The feature classification matrix will provide information about backend
> plugins and the features they support.
>
> It acts as a launching point for users to read about the intent of the
> matrix before reviewing the matrix to find features and plugins that meet
> their needs.
>
> This document will allow deployers and operators to figure out which
> backend plugins will fit their specific use case.
>
>
>
> Framework for documentation is ready [2] and can be merged. It will allow
> to render final version of Feature Matrix.
>
> Feature Matrix is also prepared to be merged [3]. It's rough, initial
> version after several iterations. There are still missing pieces of
> information, but even though, it's better to have something, where we can
> start, than nothing.
>

Thanks for working on this! I realize that I have not given the attention
this deserved, I hope to make it up to you during the mid-cycle.

Cheers,
Armando


>
>
>
>
> [1] https://launchpad.net/bugs/1580327
>
> [2] https://review.openstack.org/#/c/318192/
>
> [3] https://review.openstack.org/#/c/324048/
>
> [4] http://docs.openstack.org/developer/nova/feature_classification.html
>
> [5] http://releases.openstack.org/newton/schedule.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

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

On Wed, Aug 10, 2016 at 10:57 AM, Matthew Treinish 
wrote:

> We also test every incoming
> tempest change on all the stable branches, and nothing can land unless it
> works
> on all supported branches.


Did not know that, pretty awesome!


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

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

2016-08-10 Thread Matthew Treinish

On Wed, Aug 10, 2016 at 09:52:55AM -0700, Clay Gerrard wrote:
> On Wed, Aug 10, 2016 at 7:42 AM, Ben Swartzlander 
> wrote:
> 
> >
> > A big source of problems IMO is that tempest doesn't have stable branches.
> > We use the master branch of tempest to test stable branches of other
> > projects, and tempest regularly adds new features.
> >
> 
> How come not this +1000 just fix this?

Well, mostly because it's actually not a problem and ignores the history on why
tempest is branchless. We actually used to do this pre-icehouse and it actually
made things much worse. What was happening back then was we didn't have enough
activity to keep the stable branches working at all. So we'd go very long
periods where nothing actually could land. We also often wedged ourselves where
master tempest changed to a point where we couldn't sanely backport a fix to
the stable branch. This would often mean that up until right before a stable
release things just couldn't land until someone was actually motivated to try
and dig us out. But, what more often happened was we had to just disable tempest
on the branch, because we didn't have another option. It also turns out that
having different tests across a release boundary meant we weren't actually
validating that the OpenStack APIs were consistent and worked the same. We had
many instances where a projects API just changed between release boundaries,
which violates our API consistency and backwards compatibility guidelines.
Tempest is about verifying the API and just like an other API client it should
work against any OpenStack release.

Doing this has been a huge benefit for making things actually work on the stable
branches. (in fact just thinking back about how broken everything was all the
time back then makes me appreciate it even more) We also test every incoming
tempest change on all the stable branches, and nothing can land unless it works
on all supported branches. It means we have a consistent and stable api across
releases. We do have occasional bugs where a new test or change in tempest
triggers a new race in a project's stable branch. But, that's a real bug and
normally a fix can be backported.(which is the whole point of doing stable
branches) If it can't and the race is bad enough to actively interfere with
things, we have a mechanism to skip the test. (but that's normally a last
resort) Although, these issues tend to come up pretty infrequently in practice,
especially as we slowly ramp up the stability of things over time.

FWIW, a lot of these details are covered in the original spec for implementing
this: (although it's definitely assumes a bit of prior knowledge about the
state of things going on when it was written)

http://specs.openstack.org/openstack/qa-specs/specs/tempest/implemented/branchless-tempest.html

-Matt Treinish

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

Re: [openstack-dev] [requirements] History lesson please

2016-08-10 Thread Ian Cordasco

-Original Message-
From: Chris Friesen 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: August 10, 2016 at 11:50:48
To: openstack-dev@lists.openstack.org 
Subject:  Re: [openstack-dev] [requirements] History lesson please

> On 08/10/2016 04:51 AM, Erno Kuvaja wrote:
> > On Wed, Aug 10, 2016 at 9:27 AM, Thomas Goirand wrote:
>  
> >> Not necessarily. Take for example Swift. It has lower requirements than
> >> other projects in OpenStack. Yet, Swift is fully co-installable with all
> >> other OpenStack projects. They just support lower versions than others.
> >>
> > This just makes lifecycle management total nightmare if different
> > project has different requirements within same release. Lets say we
> > have these projects Swift, X and Y that supports the lower versions,
> > now we decide to deploy Z to that same cloud but Z has higher
> > requirement than Swift, X and Y, so we need to upgrade that
> > requirement at minimum to that new level required by Z.
> >
> > Having 3 options here:
> > 1) We upgrade the requirement to the new level system wide and restart
> > Swift, X and Y to avoid any nasty surprises later down the line, which
> > is risky and disruptive by itself.
> > 2) We containerize/use venv for Z and provide the new version of the
> > dependency just for that.
> > 3) We deploy Z to it's own node.
>  
> As Doug Hellman said earlier in the thread, they recommend to 
> deployers/packages
> that they use the *highest* supported version as listed in 
> upper-constraints.txt.  
>  
> In the case above, if the deployer had done this then bringing in Z would 
> likely
> not have resulted in a need to upgrade any requirements.

I think the point that Erno and I have failed to mention is that often times 
OpenStack is not the only thing being deployed by an operator. So you have a 
range of supported versions in OpenStack + whatever else you may be deploying 
on that hardware. If the version of a dependency from something that is not 
OpenStack fits in one range but not another, you're making it quite hard to 
satisfy this. Granted, if both ranges are equal but still don't allow for the 
third party software constrant to be satisfied that's a separate problem, but 
at least there isn't confusion/disagreement in what the minimum supported 
version from the OpenStack projects is.

Even if that third-party software has a version that can be satisfied from both 
ranges, any operator worth their salt now has to go ahead and do the work to 
verify that version doesn't cause a different behaviour in anything else that's 
using the older version before deploying the new OpenStack service.

--  
Ian Cordasco

__
OpenStack Development Mailing 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] [Cinder] [stable] [all] Changing stable policy for drivers

On Wed, Aug 10, 2016 at 10:21 AM, Matthew Treinish 
wrote:

> But, to keep the gate running
> involves a lot of coordination between multiple projects that are tightly
> coupled. Things like an entire extra set of job definitions in zuul, a
> branch on
> global requirements, a devstack branch, extra devstack-gate logic, a bunch
> of
> extra config options for skips in tempest, extra node types, etc. Keeping
> all
> those things working together is a big part of what stable maint actually
> entails.

that actually makes more sense (sorry I missed any earlier explanation) -
I'm reading this as there is only ever one CI *system* running at a time,
and that system needs to know a bunch about how to *setup* a test job on an
old branches - not that any of the old versions of code or tests or even
the history of the CI system that existed and was able to test them at the
time is GONE - its just that the current deployed system needs to move on...

> That's why at the EOL we tag
> the branch tip and then delete it. Leaving the branch around advertises
> that
> we're in a position to accept new patches to it, which we aren't after the
> EOL.
>
>
Oh wow... so it *is* GONE ;)

And really "we can't test it so no-one can" might be a big part of the
issue that was brought up in the earlier thread.  Maybe trying to support
stable branches longer than 18 months is *not* something can to be broadly
supported inside of OpenStack (there seemed to be some interest in the
etherpad going out to 24 months some day, even though older branches would
have less and less support for new testing capabilities).  But I think the
heart of this thread is "we appreciate the complexity and effort that it
takes to deliver what we have for older branches.  [full stop]  We need a
way to extend some minimal life support into older releases in a way that
is compatible with the current policy.  [full stop] "

Would it be *too* confusing to have "End of Full OpenStack Supported
Official Testing/Life" != "End of a projects commitment to people running
clouds using our software to try and help them be successful"?  Without
having to define unilaterally for every installation that the only option
for success is upgrade to the next about to be abandoned in 6-18 mo major
release?

I think ideally we'd be looking for a way to let them have their cake
without extra work.

OTOH, forking to support old branches seems just as reasonable to me as
well (that's what we do)...

However, I fully admit, I'm probably thinking about it wrong.  :D

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

Re: [openstack-dev] [ironic] About third-party CI

2016-08-10 Thread Clint Byrum

Excerpts from Jim Rollenhagen's message of 2016-08-10 13:21:11 -0400:
> On Wed, Aug 10, 2016 at 1:05 PM, Clint Byrum  wrote:
> > Excerpts from Jim Rollenhagen's message of 2016-08-10 09:21:41 -0400:
> >> 2) A number of drivers do not have third-party CI up, let alone reporting
> >>on patches. Unless someone moves quickly, I strongly suspect the 
> >> following
> >>drivers will be dropped from our tree before the end of Newton. These 
> >> are
> >>the setup.cfg names.
> >>
> >>   agent_amt
> >>   pxe_amt
> >>   fake_amt
> >>   agent_iboot
> >>   pxe_iboot
> >>   fake_iboot
> >>   agent_wol
> >>   pxe_wol
> >>   fake_wol
> >>   agent_vbox
> >>   fake_vbox
> >>   pxe_vbox
> >
> > Do these three need to be 3rd-party? Virtualbox is free software available
> > in at least Ubuntu, so in theory these could just be tested by regular
> > CI. I understand it's intended for windows boxes that can't easily use
> > the SSH variants, but I wonder if it's meaningful enough to run Linux
> > based CI to verify the functionality?
> 
> Yes, that's certainly possible. We already run a lot of jobs in CI so
> I don't want to add too many jobs, but I'd be fine with adding a vbox job.
> If someone wants to do that work this cycle, I'd be happy to keep that
> driver in tree (but I honestly don't have time to do it myself).
> 

Right, I don't use it, and I don't have time or focus to do it, but I
just want it to be clear: if you use that driver, and you want it to
remain in-tree, you don't have to setup a whole 3rd-party CI for it.
You can just run a job in the regular OpenStack CI system.

__
OpenStack Development Mailing 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] [Cinder] [stable] [all] Changing stable policy for drivers

2016-08-10 Thread Matthew Treinish

On Wed, Aug 10, 2016 at 09:56:09AM -0700, Clay Gerrard wrote:
> On Mon, Aug 8, 2016 at 8:31 AM, Matthew Treinish 
> wrote:
> 
> > When we EOL a branch all of the infrastructure for running any ci against
> > it goes away.
> 
> 
> But... like... version control?  I mean I'm sure it's more complicated than
> that or you wouldn't have said this - but I don't understand, sorry.
> 
> Can you elaborate on this?
> 

I did in other parts of the thread. The thing is you're only thinking about the
CI system as involving a single project and repo. But, to keep the gate running
involves a lot of coordination between multiple projects that are tightly
coupled. Things like an entire extra set of job definitions in zuul, a branch on
global requirements, a devstack branch, extra devstack-gate logic, a bunch of
extra config options for skips in tempest, extra node types, etc. Keeping all
those things working together is a big part of what stable maint actually
entails. When we EOL a branch most of the mechanics involved are a matter of
cleaning up all of those pieces everywhere because we don't have the bandwidth
or resources to continue keeping it all working. That's why at the EOL we tag 
the branch tip and then delete it. Leaving the branch around advertises that
we're in a position to accept new patches to it, which we aren't after the EOL.

-Matt Treinish

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

Re: [openstack-dev] [ironic] About third-party CI

2016-08-10 Thread Jim Rollenhagen

On Wed, Aug 10, 2016 at 1:05 PM, Clint Byrum  wrote:
> Excerpts from Jim Rollenhagen's message of 2016-08-10 09:21:41 -0400:
>> 2) A number of drivers do not have third-party CI up, let alone reporting
>>on patches. Unless someone moves quickly, I strongly suspect the following
>>drivers will be dropped from our tree before the end of Newton. These are
>>the setup.cfg names.
>>
>>   agent_amt
>>   pxe_amt
>>   fake_amt
>>   agent_iboot
>>   pxe_iboot
>>   fake_iboot
>>   agent_wol
>>   pxe_wol
>>   fake_wol
>>   agent_vbox
>>   fake_vbox
>>   pxe_vbox
>
> Do these three need to be 3rd-party? Virtualbox is free software available
> in at least Ubuntu, so in theory these could just be tested by regular
> CI. I understand it's intended for windows boxes that can't easily use
> the SSH variants, but I wonder if it's meaningful enough to run Linux
> based CI to verify the functionality?

Yes, that's certainly possible. We already run a lot of jobs in CI so
I don't want to add too many jobs, but I'd be fine with adding a vbox job.
If someone wants to do that work this cycle, I'd be happy to keep that
driver in tree (but I honestly don't have time to do it myself).

// 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] [neutron] Feature Classification

2016-08-10 Thread Gupta, Ankur

Hello Neutrinos,

One of the things, that is required to have ease of use, is good documentation.
Similar to what's done for Nova [4], I've decided to prepare Feature 
Classification for Neutron.
Work was already approved, and it got greenlit [1], but we still lack of final 
approval. In the light of N-3 [5] approaching, it would be nice to have it 
merged sooner than later.

What's Feature Matrix Classification?
The feature classification matrix will provide information about backend 
plugins and the features they support.
It acts as a launching point for users to read about the intent of the matrix 
before reviewing the matrix to find features and plugins that meet their needs.
This document will allow deployers and operators to figure out which backend 
plugins will fit their specific use case.

Framework for documentation is ready [2] and can be merged. It will allow to 
render final version of Feature Matrix.
Feature Matrix is also prepared to be merged [3]. It's rough, initial version 
after several iterations. There are still missing pieces of information, but 
even though, it's better to have something, where we can start, than nothing.


[1] https://launchpad.net/bugs/1580327
[2] https://review.openstack.org/#/c/318192/
[3] https://review.openstack.org/#/c/324048/
[4] http://docs.openstack.org/developer/nova/feature_classification.html
[5] http://releases.openstack.org/newton/schedule.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] About third-party CI

2016-08-10 Thread Clint Byrum

Excerpts from Jim Rollenhagen's message of 2016-08-10 09:21:41 -0400:
> 2) A number of drivers do not have third-party CI up, let alone reporting
>on patches. Unless someone moves quickly, I strongly suspect the following
>drivers will be dropped from our tree before the end of Newton. These are
>the setup.cfg names.
> 
>   agent_amt
>   pxe_amt
>   fake_amt
>   agent_iboot
>   pxe_iboot
>   fake_iboot
>   agent_wol
>   pxe_wol
>   fake_wol
>   agent_vbox
>   fake_vbox
>   pxe_vbox

Do these three need to be 3rd-party? Virtualbox is free software available
in at least Ubuntu, so in theory these could just be tested by regular
CI. I understand it's intended for windows boxes that can't easily use
the SSH variants, but I wonder if it's meaningful enough to run Linux
based CI to verify the functionality?

__
OpenStack Development Mailing 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] [Cinder] [stable] [all] Changing stable policy for drivers

On Mon, Aug 8, 2016 at 8:31 AM, Matthew Treinish 
wrote:

> When we EOL a branch all of the infrastructure for running any ci against
> it goes away.

But... like... version control?  I mean I'm sure it's more complicated than
that or you wouldn't have said this - but I don't understand, sorry.

Can you elaborate on this?

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

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

On Wed, Aug 10, 2016 at 7:42 AM, Ben Swartzlander 
wrote:

>
> A big source of problems IMO is that tempest doesn't have stable branches.
> We use the master branch of tempest to test stable branches of other
> projects, and tempest regularly adds new features.
>

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

Re: [openstack-dev] [requirements] History lesson please

2016-08-10 Thread Chris Friesen


On 08/10/2016 04:51 AM, Erno Kuvaja wrote:

On Wed, Aug 10, 2016 at 9:27 AM, Thomas Goirand  wrote:



Not necessarily. Take for example Swift. It has lower requirements than
other projects in OpenStack. Yet, Swift is fully co-installable with all
other OpenStack projects. They just support lower versions than others.


This just makes lifecycle management total nightmare if different
project has different requirements within same release. Lets say we
have these projects Swift, X and Y that supports the lower versions,
now we decide to deploy Z to that same cloud but Z has higher
requirement than Swift, X and Y, so we need to upgrade that
requirement at minimum to that new level required by Z.

Having 3 options here:
1) We upgrade the requirement to the new level system wide and restart
Swift, X and Y to avoid any nasty surprises later down the line, which
is risky and disruptive by itself.
2) We containerize/use venv for Z and provide the new version of the
dependency just for that.
3) We deploy Z to it's own node.


As Doug Hellman said earlier in the thread, they recommend to deployers/packages 
that they use the *highest* supported version as listed in upper-constraints.txt.


In the case above, if the deployer had done this then bringing in Z would likely 
not have resulted in a need to upgrade any requirements.


Chris

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

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

2016-08-10 Thread Luigi Toscano

On Wednesday, 10 August 2016 12:00:41 CEST Ben Swartzlander wrote:
> On 08/10/2016 11:33 AM, Luigi Toscano wrote:
> > On Wednesday, 10 August 2016 17:00:36 CEST Ihar Hrachyshka wrote:
> >> Luigi Toscano  wrote:
> >>> On Wednesday, 10 August 2016 10:42:41 CEST Ben Swartzlander wrote:
>  On 08/10/2016 04:33 AM, Duncan Thomas wrote:
> > So I tried to get into helping with the cinder stable tree for a
> > while,
> > and while I wasn't very successful (lack of time and an inability to
> > convince my employer it should be a priority), one thing I did notice
> > it
> > that much of the breakage seemed to come from outside cinder - many of
> > the libraries we depend on make backwards incompatible changes by
> > accident, for example. Would it be possible to have a
> > long-term-support
> > branch where we pinned the max version of everything for the gate,
> > pips
> > and devtstack? I'd have thought (and I'm very willing to be corrected)
> > that would make the stable gate, well, stable, such that it required
> > far
> > less work to keep it able to run a basic devstack test plus unit
> > tests.
> > 
> > Does that sound at all sane?
>  
>  A big source of problems IMO is that tempest doesn't have stable
>  branches. We use the master branch of tempest to test stable branches
>  of
>  other projects, and tempest regularly adds new features. This
>  guarantees
>  instability if you rely on tempest anywhere in your gate (and cinder
>  does).
> >>> 
> >>> Orthogonal to the discussion, but: this is not due to the lack of stable
> >>> branch, but that part of the Tempest API are not stable yet. This is
> >>> being
> >>> addressed right now (in scope for Newton).
> >>> Once the Tempest stable API are used, no breakages should happen.
> >> 
> >> Well, it’s only partially true. But what happens when you add a new test
> >> to
> >> tempest/master? It gets executed on all branches, and maybe some of them
> >> are failing it. We can argue that it’s probably a bug revealed, but it
> >> nevertheless requires attention from stable maintainers to solve.
> > 
> > The new test should work on all support branches. As tester I find a lot
> > of
> > advantages of maintaining a unified set of tests than fighting with
> > backports of tests.
> 
> I'm sure it makes YOUR life easier to not have to deal with backports.
> The rest of us who do maintain stable branches though don't appreciate
> it when tempest adds a new feature or a new dependency which breaks the
> stable gate jobs. This happens a few times each release, and tends to
> get fixed within a day or two, which is barely tolerable.

Again, if a new test uncover the bug, why blame the test and not the bug?

If you don't want to fix bugs in stable branches, why keep them?

I don't understand...

> 
> The fact that it happens at all though says that we're "doing it wrong"
> w.r.t. testing of stable branches, and completely explains why we find
> it so challenging to support stuff more than 12 months old. If
> everything we used had stable branches and proper dependency management,
> then it would easy to keep gate job running for years.

Again, if a test uncover a bugs, let fix the bug.

> 
> > There are mechanisms to skip tests based on the cloud capabilities.
> > So this should not be an issue, and if a bug is found that should
> > definitely be viewed as a good thing.
> 
> It's not new tests that cause the problem, because those would be easy
> to skip. It's changes to tempest core which force changes elsewhere.

As I mentioned before, that's something temporary, due to the change of scope 
of Tempest (the core six, the plugin systems) and the stabilization of that's 
ongoing for Newton, so *right now*.
We will forget quickly about all of this once its fixed (more or less like the 
old complains about Neutron - rememeber?). 
Patches always welcome to speed up the Tempest API stabilization.

-- 
Luigi

__
OpenStack Development Mailing 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] [charms] nominating thedac for charms-release team

2016-08-10 Thread Billy Olsen

+1

On Tue, Aug 9, 2016 at 9:13 AM, James Page  wrote:
> On Mon, 8 Aug 2016 at 18:19 Ryan Beisner  wrote:
>>
>> Greetings,
>>
>> I would like to nominate David Ames  for addition to the
>> charms-release team, as he has played a valuable role in the charm release
>> processes.  This change will grant privileges such as new stable branch
>> creation, among other things necessary to facilitate the charm release
>> process.
>
>
> +1
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [all][ptl][tc] extra ATCs for newton

It's time to make sure we have all of our active technical contributors
(ATCs) identified for Newton.

Following the Foundation bylaws [1] and TC Charter [2], Project
teams should identify contributors who have had a significant impact
this cycle but who would not qualify for ATC status using the regular
process because they have not submitted a patch.  Contributions
might include, but aren't limited to, bug triage, design work, and
documentation -- there is a lot of leeway in how teams define
contribution for ATC status.

The resulting list of names should be submitted as a patch to the
"extra-atcs" section in openstack/governance/reference/projects.yaml
for review by the TC.

Although extra ATCs can be nominated at any point, there is a
deadline to be included in the electorate for the next release
cycle. The ATC list needs to be approved by the TC by 25 Aug, and
in order to appear on the TC agenda to be discussed, the proposals
need to be submitted by 16 Aug.

PTLs can delegate preparing the patch to the governance repository, but
please +1 the patch indicating that you agree with the list to avoid
delays in the TC review.

Thanks,
Doug

[1] http://www.openstack.org/legal/technical-committee-member-policy/
[2] 
http://governance.openstack.org/reference/charter.html#voters-for-tc-seats-atc

__
OpenStack Development Mailing 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] [Cinder] [stable] [all] Changing stable policy for drivers

2016-08-10 Thread Mike Perez

On 19:42 Aug 09, Ben Swartzlander wrote:
> Mike, you must have left the midcycle by the time this topic came up. On the
> issue of out-of-tree drivers, I specifically offered this proposal (a
> community managed mechanism for distributing driver bugfix backports) as an
> compromise alternative to try to address the needs of both camps. Everyone
> who was in the room at the time (plus DuncanT who wasn't) agreed that if we
> had that (a way to deal with backports) that they wouldn't want drivers out
> of the tree anymore.
> 
> Your point of view wasn't represented so go ahead and explain why, if we did
> have a reasonable way for bugfixes to get backported to the releases
> customers actually run (leaving that mechanism unspecified for the time
> being), that you would still want the drivers out of the tree.

There is no need to repeat. Read the earlier oppositions in this thread,
thanks.

-- 
Mike Perez

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

2016-08-10 Thread Liz Blanchard

On Wed, Aug 10, 2016 at 11:52 AM, Ben Nemec  wrote:

> On 08/08/2016 09:22 PM, Dan Prince wrote:
> > On Mon, 2016-08-08 at 15:42 -0500, Ben Nemec wrote:
> >> This is something that has existed for a while, but I had been
> >> hesitant
> >> to evangelize it until it was a little more proven.  At this point
> >> I've
> >> used it to generate templates for a number of different environments,
> >> and it has worked well.  I decided it was time to record another demo
> >> and throw it out there for the broader community to look at.  See
> >> details on my blog:
> >> http://blog.nemebean.com/content/tripleo-network-isolation-template-g
> >> enerator
> >>
> >> Most of what you need to know is either there or in the video itself.
> >> Let me know what you think.
> >
> > Very cool. For those that don't like "hand cutting" their own network
> > configuration templates this is a good CLI based generator.
> >
> > Like you mention it would be nice to eventually converge this tool
> > somehow into both the UI and CLI but given that it works with older
> > releases as well it makes sense that it is CLI only for now.
>
> Yeah, my assumption is that at some point the UI will have similar
> functionality.  Ideally the UI would replace this entirely, but I
> suspect that's a ways off and we'll have to see how it plays out for
> people doing CLI installs.
>

Speaking of which...I'd love to work closely with you, Ben, to put together
a wireframe design for the TripleO UI to support something like what you've
done here. It looks awesome and I'd love to understand the use cases a bit
more and how it might work into the current UI flow.

I do have a first draft of a design that allows for some network
configuration that I'd love to get folks thoughts on:
https://invis.io/UM87J4NBQ

Of course, as you mention, this would be something that is looking into the
future for the UI but it would be awesome to start now with wireframes :)

Thanks for sharing this,
Liz


>
> >
> > Dan
> >
> >>
> >> Thanks.
> >>
> >> -Ben
> >>
> >> _
> >> _
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> >> cribe
> >> 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] [Cinder] [stable] [all] Changing stable policy for drivers

2016-08-10 Thread Ben Swartzlander


On 08/10/2016 11:33 AM, Luigi Toscano wrote:

On Wednesday, 10 August 2016 17:00:36 CEST Ihar Hrachyshka wrote:

Luigi Toscano  wrote:

On Wednesday, 10 August 2016 10:42:41 CEST Ben Swartzlander wrote:

On 08/10/2016 04:33 AM, Duncan Thomas wrote:

So I tried to get into helping with the cinder stable tree for a while,
and while I wasn't very successful (lack of time and an inability to
convince my employer it should be a priority), one thing I did notice it
that much of the breakage seemed to come from outside cinder - many of
the libraries we depend on make backwards incompatible changes by
accident, for example. Would it be possible to have a long-term-support
branch where we pinned the max version of everything for the gate, pips
and devtstack? I'd have thought (and I'm very willing to be corrected)
that would make the stable gate, well, stable, such that it required far
less work to keep it able to run a basic devstack test plus unit tests.

Does that sound at all sane?


A big source of problems IMO is that tempest doesn't have stable
branches. We use the master branch of tempest to test stable branches of
other projects, and tempest regularly adds new features. This guarantees
instability if you rely on tempest anywhere in your gate (and cinder
does).


Orthogonal to the discussion, but: this is not due to the lack of stable
branch, but that part of the Tempest API are not stable yet. This is being
addressed right now (in scope for Newton).
Once the Tempest stable API are used, no breakages should happen.


Well, it’s only partially true. But what happens when you add a new test to
tempest/master? It gets executed on all branches, and maybe some of them
are failing it. We can argue that it’s probably a bug revealed, but it
nevertheless requires attention from stable maintainers to solve.


The new test should work on all support branches. As tester I find a lot of
advantages of maintaining a unified set of tests than fighting with backports
of tests.


I'm sure it makes YOUR life easier to not have to deal with backports. 
The rest of us who do maintain stable branches though don't appreciate 
it when tempest adds a new feature or a new dependency which breaks the 
stable gate jobs. This happens a few times each release, and tends to 
get fixed within a day or two, which is barely tolerable.


The fact that it happens at all though says that we're "doing it wrong" 
w.r.t. testing of stable branches, and completely explains why we find 
it so challenging to support stuff more than 12 months old. If 
everything we used had stable branches and proper dependency management, 
then it would easy to keep gate job running for years.



There are mechanisms to skip tests based on the cloud capabilities.
So this should not be an issue, and if a bug is found that should definitely
be viewed as a good thing.


It's not new tests that cause the problem, because those would be easy 
to skip. It's changes to tempest core which force changes elsewhere.


-Ben



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

2016-08-10 Thread Ben Nemec

On 08/08/2016 09:22 PM, Dan Prince wrote:
> On Mon, 2016-08-08 at 15:42 -0500, Ben Nemec wrote:
>> This is something that has existed for a while, but I had been
>> hesitant
>> to evangelize it until it was a little more proven.  At this point
>> I've
>> used it to generate templates for a number of different environments,
>> and it has worked well.  I decided it was time to record another demo
>> and throw it out there for the broader community to look at.  See
>> details on my blog:
>> http://blog.nemebean.com/content/tripleo-network-isolation-template-g
>> enerator
>>
>> Most of what you need to know is either there or in the video itself.
>> Let me know what you think.
> 
> Very cool. For those that don't like "hand cutting" their own network
> configuration templates this is a good CLI based generator.
> 
> Like you mention it would be nice to eventually converge this tool
> somehow into both the UI and CLI but given that it works with older
> releases as well it makes sense that it is CLI only for now.

Yeah, my assumption is that at some point the UI will have similar
functionality.  Ideally the UI would replace this entirely, but I
suspect that's a ways off and we'll have to see how it plays out for
people doing CLI installs.

> 
> Dan
> 
>>
>> Thanks.
>>
>> -Ben
>>
>> _
>> _
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
>> cribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] Nova mascot

On 08/10/2016 11:36 AM, Sean Dague wrote:
> On 08/09/2016 07:30 PM, Heidi Joy Tretheway wrote:
>> TL;DR: If you don’t want a mascot, you don’t have to. But Nova, you’ll
>> be missed. :-)
>>
>> A few notes following up on Matt Riedemann, Clint Byrum, Daniel
>> Berrange’s conversation regarding the Nova mascot…
>>
>> Nova doesn’t have to have a mascot if the majority of the team doesn’t
>> want one. I’m not sure if the Nova community took a vote or if it was
>> more of an informal discussion. We have 53 projects with confirmed
>> logos, and we’re planning some great swag associated with the new
>> project mascots. (I’m surprised the Nova team didn’t immediately request
>> a star nova as their mascot. I’ll give you three guesses what Swift
>> picked...)
> 
> Ok, we've been having a bit of a nova core private email thread just to
> figure out where everyone stood.
> 

"Milestone 3 is a really hard time to have new requests pop up, for
anything really, because right now the whole team is pretty heads down
trying to only *disappoint* no more than 50% of people that are trying
to land
features during the cycle that won't make it."

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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] About third-party CI

2016-08-10 Thread Kurt Taylor

On Wed, Aug 10, 2016 at 8:21 AM, Jim Rollenhagen 
wrote:

> Hi Ironicers,
>
> This email serves as a reminder (and a bit of a call to action) about our
> third party CI policy:
> http://specs.openstack.org/openstack/ironic-specs/specs/
> not-implemented/third-party-ci.html
>
> 1) When I went to find a link to the policy, I realized that it isn't in
> our
>developer docs, but only in our specs repo. Can someone volunteer to
>document this in our dev docs?
>

This will be documented as a part of this patch:
https://review.openstack.org/#/c/353102/


>
> 2) A number of drivers do not have third-party CI up, let alone reporting
>on patches. Unless someone moves quickly, I strongly suspect the
> following
>drivers will be dropped from our tree before the end of Newton. These
> are
>the setup.cfg names.
>
>   agent_amt
>   pxe_amt
>   fake_amt
>   agent_iboot
>   pxe_iboot
>   fake_iboot
>   agent_wol
>   pxe_wol
>   fake_wol
>   agent_vbox
>   fake_vbox
>   pxe_vbox
>   pxe_seamicro
>   fake_seamicro
>   pxe_drac
>   fake_drac
>   pxe_snmp
>   fake_snmp
>   pxe_msftocs
>   fake_msftocs
>
>It's important to note that some ironic folks have taken the burden of
>maintaining some untested drivers in an out-of-tree repo, however this
>is not an official OpenStack project, and not part of the ironic
> governance.
>https://git.openstack.org/cgit/openstack/ironic-staging-drivers
>
> 3) The SSH drivers (pxe_ssh and agent_ssh) that we use for some testing
>currently are planned to be dropped.  First, we need to update
>project-config to make sure all of those jobs are moved to an equivalent
>*_ipmitool job, and drop the _ssh jobs. Then we can go ahead and remove
>the drivers. I'd like a volunteer for this as well, but am happy to take
>it on as needed.
>
> 4) The drivers that use pyghmi (pxe_ipminative and agent_pyghmi) currently
> are
>not tested in ironic's CI. We have multiple jobs for each of the
> ipmitool
>drivers. Instead of making new jobs, we could just move one of the
> ipmitool
>drivers to use the pyghmi drivers (since they both use IPMI, it should
> be
>simple to do so). As with above, I'm happy to do this if there are no
>volunteers.
>
> Thanks for reading (and hopefully volunteering!).
>
> // 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 Development Mailing 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] About third-party CI

2016-08-10 Thread Jim Rollenhagen

On Wed, Aug 10, 2016 at 9:21 AM, Jim Rollenhagen  
wrote:
> Hi Ironicers,
>
> This email serves as a reminder (and a bit of a call to action) about our
> third party CI policy:
> http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/third-party-ci.html
>
> 1) When I went to find a link to the policy, I realized that it isn't in our
>developer docs, but only in our specs repo. Can someone volunteer to
>document this in our dev docs?

Apparently Kurt has this covered: https://review.openstack.org/#/c/353102/

Thanks Kurt!

// jim

> 2) A number of drivers do not have third-party CI up, let alone reporting
>on patches. Unless someone moves quickly, I strongly suspect the following
>drivers will be dropped from our tree before the end of Newton. These are
>the setup.cfg names.
>
>   agent_amt
>   pxe_amt
>   fake_amt
>   agent_iboot
>   pxe_iboot
>   fake_iboot
>   agent_wol
>   pxe_wol
>   fake_wol
>   agent_vbox
>   fake_vbox
>   pxe_vbox
>   pxe_seamicro
>   fake_seamicro
>   pxe_drac
>   fake_drac
>   pxe_snmp
>   fake_snmp
>   pxe_msftocs
>   fake_msftocs
>
>It's important to note that some ironic folks have taken the burden of
>maintaining some untested drivers in an out-of-tree repo, however this
>is not an official OpenStack project, and not part of the ironic 
> governance.
>https://git.openstack.org/cgit/openstack/ironic-staging-drivers
>
> 3) The SSH drivers (pxe_ssh and agent_ssh) that we use for some testing
>currently are planned to be dropped.  First, we need to update
>project-config to make sure all of those jobs are moved to an equivalent
>*_ipmitool job, and drop the _ssh jobs. Then we can go ahead and remove
>the drivers. I'd like a volunteer for this as well, but am happy to take
>it on as needed.
>
> 4) The drivers that use pyghmi (pxe_ipminative and agent_pyghmi) currently are
>not tested in ironic's CI. We have multiple jobs for each of the ipmitool
>drivers. Instead of making new jobs, we could just move one of the ipmitool
>drivers to use the pyghmi drivers (since they both use IPMI, it should be
>simple to do so). As with above, I'm happy to do this if there are no
>volunteers.
>
> Thanks for reading (and hopefully volunteering!).
>
> // 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

Re: [openstack-dev] Nova mascot

On 08/09/2016 07:30 PM, Heidi Joy Tretheway wrote:
> TL;DR: If you don’t want a mascot, you don’t have to. But Nova, you’ll
> be missed. :-)
> 
> A few notes following up on Matt Riedemann, Clint Byrum, Daniel
> Berrange’s conversation regarding the Nova mascot…
> 
> Nova doesn’t have to have a mascot if the majority of the team doesn’t
> want one. I’m not sure if the Nova community took a vote or if it was
> more of an informal discussion. We have 53 projects with confirmed
> logos, and we’re planning some great swag associated with the new
> project mascots. (I’m surprised the Nova team didn’t immediately request
> a star nova as their mascot. I’ll give you three guesses what Swift
> picked...)

Ok, we've been having a bit of a nova core private email thread just to
figure out where everyone stood.

Milestone 3 is a really hard time to have new requests pop up, for
anything really, because right now the whole team is pretty heads down
trying to only no more than 50% of people that are trying to land
features during the cycle that won't make it.

To summarize the sentiment, I think there are many folks that aren't
enthusiastic about mascots. However there are also some that would like
to move forward with something, and not have Nova represented by a
broken image link.

I think given what's been on the public lists, and some of this back
channel, marking Nova down for "star / supernova" would be fine. I
imagine the creative folks working on logos can come up with something
cool around that.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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] [Cinder] [stable] [all] Changing stable policy for drivers

2016-08-10 Thread Luigi Toscano

On Wednesday, 10 August 2016 17:00:36 CEST Ihar Hrachyshka wrote:
> Luigi Toscano  wrote:
> > On Wednesday, 10 August 2016 10:42:41 CEST Ben Swartzlander wrote:
> >> On 08/10/2016 04:33 AM, Duncan Thomas wrote:
> >>> So I tried to get into helping with the cinder stable tree for a while,
> >>> and while I wasn't very successful (lack of time and an inability to
> >>> convince my employer it should be a priority), one thing I did notice it
> >>> that much of the breakage seemed to come from outside cinder - many of
> >>> the libraries we depend on make backwards incompatible changes by
> >>> accident, for example. Would it be possible to have a long-term-support
> >>> branch where we pinned the max version of everything for the gate, pips
> >>> and devtstack? I'd have thought (and I'm very willing to be corrected)
> >>> that would make the stable gate, well, stable, such that it required far
> >>> less work to keep it able to run a basic devstack test plus unit tests.
> >>> 
> >>> Does that sound at all sane?
> >> 
> >> A big source of problems IMO is that tempest doesn't have stable
> >> branches. We use the master branch of tempest to test stable branches of
> >> other projects, and tempest regularly adds new features. This guarantees
> >> instability if you rely on tempest anywhere in your gate (and cinder
> >> does).
> > 
> > Orthogonal to the discussion, but: this is not due to the lack of stable
> > branch, but that part of the Tempest API are not stable yet. This is being
> > addressed right now (in scope for Newton).
> > Once the Tempest stable API are used, no breakages should happen.
> 
> Well, it’s only partially true. But what happens when you add a new test to
> tempest/master? It gets executed on all branches, and maybe some of them
> are failing it. We can argue that it’s probably a bug revealed, but it
> nevertheless requires attention from stable maintainers to solve.

The new test should work on all support branches. As tester I find a lot of 
advantages of maintaining a unified set of tests than fighting with backports 
of tests.
There are mechanisms to skip tests based on the cloud capabilities.
So this should not be an issue, and if a bug is found that should definitely 
be viewed as a good thing.

-- 
Luigi

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

2016-08-10 Thread Zane Bitter


On 09/08/16 21:21, Adam Young wrote:

On 08/09/2016 06:00 PM, Zane Bitter wrote:


In either case a good mechanism might be to use a Heat Software
Deployment via the Heat API directly (i.e. not as part of a stack) to
push changes to the servers. (I say 'push' but it's more a case of
making the data available for os-collect-config to grab it.)


This is the part that interests me most.  The rest, I'll code in python
and we can call either from mistral or from Cron.  What would a stack
like this look like?  Are there comparable examples?


Basically use the "openstack software config create" command to upload a 
script and the "openstack software deployment create" command to deploy 
it to a server. I don't have an example I can point you at, but the data 
is in essentially the same format as the properties of the corresponding 
Heat resources.[1][2] Steve Baker would know if we have any more 
detailed docs.


- ZB

[1] 
http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::SoftwareConfig
[2] 
http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::SoftwareDeployment


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

On 08/10/2016 11:19 AM, Szankin, Maciej wrote:
> While supernova looks super cool on photographs, I frankly have no idea
> how this could look like a logo. You know, the cartoonish style. Tried
> to google for examples, but they do look terrible…

That's why you have graphics designers try a thing.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals

Excerpts from Doug Hellmann's message of 2016-07-29 16:55:22 -0400:
> One of the outcomes of the discussion at the leadership training
> session earlier this year was the idea that the TC should set some
> community-wide goals for accomplishing specific technical tasks to
> get the projects synced up and moving in the same direction.
> 
> After several drafts via etherpad and input from other TC and SWG
> members, I've prepared the change for the governance repo [1] and
> am ready to open this discussion up to the broader community. Please
> read through the patch carefully, especially the "goals/index.rst"
> document which tries to lay out the expectations for what makes a
> good goal for this purpose and for how teams are meant to approach
> working on these goals.
> 
> I've also prepared two patches proposing specific goals for Ocata
> [2][3].  I've tried to keep these suggested goals for the first
> iteration limited to "finish what we've started" type items, so
> they are small and straightforward enough to be able to be completed.
> That will let us experiment with the process of managing goals this
> time around, and set us up for discussions that may need to happen
> at the Ocata summit about implementation.
> 
> For future cycles, we can iterate on making the goals "harder", and
> collecting suggestions for goals from the community during the forum
> discussions that will happen at summits starting in Boston.
> 
> Doug
> 
> [1] https://review.openstack.org/349068 describe a process for managing 
> community-wide goals
> [2] https://review.openstack.org/349069 add ocata goal "support python 3.5"
> [3] https://review.openstack.org/349070 add ocata goal "switch to oslo 
> libraries"
> 

The proposal was discussed at the TC meeting yesterday [4], and
left open to give more time to comment. I've added all of the PTLs
for big tent projects as reviewers on the process patch [1] to
encourage comments from them.

Please also look at the associated patches with the specific goals
for this cycle (python 3.5 support and cleaning up Oslo incubated
code).  So far most of the discussion has focused on the process,
but we need folks to think about the specific things they're going
to be asked to do during Ocata as well.

Doug

[4] http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-09-20.01.log.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] Fernet Key rotation

2016-08-10 Thread Zane Bitter


On 09/08/16 18:28, Fox, Kevin M wrote:

It needs to work in a distributed way...

What happens if the one node you have cron running on doesn't work for a while. 
Keystone breaks?


IIUC it wouldn't break, but your keys wouldn't get rotated so you'd end 
up using the same key until such time as your machine running cron comes 
back again. Adam was suggesting once a month, which honestly ought to be 
enough time to replace the server with the cron job (which, to be clear, 
would also be the undercloud server). The bigger danger is probably in 
forgetting that something is supposed to be running it and never 
rotating the keys. (Maybe keystone should log a warning when the keys 
get too old, if it doesn't already.)



If the undercloud deploys a timed workfow where the workflow can fail over from 
machine to machine, that would work.


Indeed, but note that this depends on an HA undercloud, which isn't a 
thing yet in TripleO. (Mainly because deploying and maintaining an HA 
undercloud is as big of a problem - in fact it's the exact same problem 
- as deploying the overcloud.)


You're correct however that the Mistral approach would get HA for free 
as soon as we have an HA undercloud, whereas the cron approach just 
presents another problem that has to be solved in order to get to an HA 
undercloud (i.e. how to make sure that exactly one machine runs the cron 
job).


cheers,
Zane.

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

Re: [openstack-dev] Nova mascot

2016-08-10 Thread Szankin, Maciej

While supernova looks super cool on photographs, I frankly have no idea how 
this could look like a logo. You know, the cartoonish style. Tried to google 
for examples, but they do look terrible…

From: Bob Ball [mailto:bob.b...@citrix.com]
Sent: Wednesday, August 10, 2016 6:37 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] Nova mascot

> TL;DR: If you don’t want a mascot, you don’t have to. But Nova, you’ll be 
> missed. :-)

It also seems from http://www.openstack.org/project-mascots that the majority 
of OpenStack projects have selected a mascot.  I think it would be a great 
shame if the Nova project didn’t have an easily recognisable image within this 
branding effort while the majority of projects we interact with do have them.  
I think there are a number of cases where the lack of a mascot for such a 
prominent project would be very noticeable, particularly when the other “big” 
projects have one.

Unfortunately, the Vauxhall Nova and Marvel’s Nova are not permitted in the 
rules, so rather than the default being “no logo”  I’d personally just go with 
a supernova[1][2] as it wouldn’t need explanations or deep discussions as to 
whether a field mouse is a better choice than an African sand dog…

Bob

[1] http://www.supernovae.net/images/illustration.jpg
[2] 
https://upload.wikimedia.org/wikipedia/commons/0/09/Artist's_impression_of_supernova_1993J.jpg

__
OpenStack Development Mailing 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] [Zun][Higgins] Proposing Sudipta Biswas and Wenzhi Yu for Zun core reviewer team

2016-08-10 Thread Hongbin Lu

Hi all,

Both Sudipta and Wenzhi have been actively contributing to the Zun project
for a while. Sudipta provided helpful advice for the project roadmap and
architecture design. Wenzhi consistently contributed high quality patches
and insightful reviews. I think both of them are qualified to join the core
team.

I am happy to propose Sudipta and Wenzhi to be core reviewers of Zun team.
According to the OpenStack Governance process [1], we require a minimum of
4 +1 votes from Zun core reviewers within a 1 week voting window (consider
this proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot
get enough votes or there is a veto vote prior to the end of the voting
window, Sudipta and Wenzhi are not able to join the core team and needs to
wait 30 days to reapply.

The voting is open until Wednesday August 17st.

[1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

Best regards,
Hongbin
__
OpenStack Development Mailing 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] [Cinder] [stable] [all] Changing stable policy for drivers

2016-08-10 Thread Hayes, Graham

On 10/08/2016 16:04, Ihar Hrachyshka wrote:
> Luigi Toscano  wrote:
>
>> On Wednesday, 10 August 2016 10:42:41 CEST Ben Swartzlander wrote:
>>> On 08/10/2016 04:33 AM, Duncan Thomas wrote:
 So I tried to get into helping with the cinder stable tree for a while,
 and while I wasn't very successful (lack of time and an inability to
 convince my employer it should be a priority), one thing I did notice it
 that much of the breakage seemed to come from outside cinder - many of
 the libraries we depend on make backwards incompatible changes by
 accident, for example. Would it be possible to have a long-term-support
 branch where we pinned the max version of everything for the gate, pips
 and devtstack? I'd have thought (and I'm very willing to be corrected)
 that would make the stable gate, well, stable, such that it required far
 less work to keep it able to run a basic devstack test plus unit tests.

 Does that sound at all sane?
>>>
>>> A big source of problems IMO is that tempest doesn't have stable
>>> branches. We use the master branch of tempest to test stable branches of
>>> other projects, and tempest regularly adds new features. This guarantees
>>> instability if you rely on tempest anywhere in your gate (and cinder
>>> does).
>>
>> Orthogonal to the discussion, but: this is not due to the lack of stable
>> branch, but that part of the Tempest API are not stable yet. This is being
>> addressed right now (in scope for Newton).
>> Once the Tempest stable API are used, no breakages should happen.
>
> Well, it’s only partially true. But what happens when you add a new test to
> tempest/master? It gets executed on all branches, and maybe some of them
> are failing it. We can argue that it’s probably a bug revealed, but it
> nevertheless requires attention from stable maintainers to solve.

And would a lot of bugs that a new test could expose be non
back-portable? AS they could cause API changes, which is banned in
the back-port policy.

Def-Core faced similar issues with new tests failing previously
validated clouds.

> Ihar
>
> __
> OpenStack Development Mailing 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] [python-bileanclient] [infra] Duplicate entriesin test-requirement.txt

On 2016-08-10 10:46:23 +0800 (+0800), 吕冬兵 wrote:
> The issue still exists after the
> https://review.openstack.org/352490 merged, what else should I do?
> http://logs.openstack.org/58/351458/8/check/gate-python-bileanclient-requirements/fa1119c/console.html

That change was for a script which gets preinstalled onto our job
node images, which we refresh once a day. It looks like you
retriggered that job shortly before replacement images were uploaded
to the provider where it ran, but hopefully if you recheck again you
should see the updated version of the project-requirements-change.py
script get used.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

2016-08-10 Thread Ihar Hrachyshka


Luigi Toscano  wrote:


On Wednesday, 10 August 2016 10:42:41 CEST Ben Swartzlander wrote:

On 08/10/2016 04:33 AM, Duncan Thomas wrote:

So I tried to get into helping with the cinder stable tree for a while,
and while I wasn't very successful (lack of time and an inability to
convince my employer it should be a priority), one thing I did notice it
that much of the breakage seemed to come from outside cinder - many of
the libraries we depend on make backwards incompatible changes by
accident, for example. Would it be possible to have a long-term-support
branch where we pinned the max version of everything for the gate, pips
and devtstack? I'd have thought (and I'm very willing to be corrected)
that would make the stable gate, well, stable, such that it required far
less work to keep it able to run a basic devstack test plus unit tests.

Does that sound at all sane?


A big source of problems IMO is that tempest doesn't have stable
branches. We use the master branch of tempest to test stable branches of
other projects, and tempest regularly adds new features. This guarantees
instability if you rely on tempest anywhere in your gate (and cinder  
does).


Orthogonal to the discussion, but: this is not due to the lack of stable
branch, but that part of the Tempest API are not stable yet. This is being
addressed right now (in scope for Newton).
Once the Tempest stable API are used, no breakages should happen.


Well, it’s only partially true. But what happens when you add a new test to  
tempest/master? It gets executed on all branches, and maybe some of them  
are failing it. We can argue that it’s probably a bug revealed, but it  
nevertheless requires attention from stable maintainers to solve.


Ihar

__
OpenStack Development Mailing 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] [neutron] Neutron Port MAC Address Uniqueness

2016-08-10 Thread Moshe Levi

Miguel, 

I talked to our driver architect and according to him this is vendor 
implementation (according to him this  should work with  Mellanox NIC)
I need to verify that this indeed working. 
I will update after I will prepare SR-IOV setup and try it myself.

-Original Message-
From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com] 
Sent: Wednesday, August 10, 2016 12:04 PM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: Armando M. ; Moshe Levi 
Subject: Re: [openstack-dev] [neutron] Neutron Port MAC Address Uniqueness

@moshe, any insight on this?

I guess that'd depend on the nic internal switch implementation and how the 
switch ARP tables are handled there (per network, or global per switch).

If that's the case for some sr-iov vendors (or all), would it make sense to 
have a global switch to create globally unique mac addresses (for the same 
neutron deployment, of course).

On Wed, Aug 10, 2016 at 7:38 AM, huangdenghui  wrote:
> hi Armando
> I think this feature causes problem in sriov scenario, since sriov 
> NIC don't support the vf has the same mac,even the port belongs to the 
> different network.
>
>
> 发自网易邮箱手机版
>
>
> On 2016-08-10 04:55 , Armando M. Wrote:
>
>
>
> On 9 August 2016 at 13:53, Anil Rao  wrote:
>>
>> Is the MAC address of a Neutron port on a tenant virtual network 
>> globally unique or unique just within that particular tenant network?
>
>
> The latter:
>
> https://github.com/openstack/neutron/blob/master/neutron/db/models_v2.
> py#L139
>
>>
>>
>>
>> Thanks,
>>
>> Anil
>>
>>
>> _
>> _ OpenStack Development Mailing 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] [Cinder] [stable] [all] Changing stable policy for drivers

2016-08-10 Thread Luigi Toscano

On Wednesday, 10 August 2016 10:42:41 CEST Ben Swartzlander wrote:
> On 08/10/2016 04:33 AM, Duncan Thomas wrote:
> > So I tried to get into helping with the cinder stable tree for a while,
> > and while I wasn't very successful (lack of time and an inability to
> > convince my employer it should be a priority), one thing I did notice it
> > that much of the breakage seemed to come from outside cinder - many of
> > the libraries we depend on make backwards incompatible changes by
> > accident, for example. Would it be possible to have a long-term-support
> > branch where we pinned the max version of everything for the gate, pips
> > and devtstack? I'd have thought (and I'm very willing to be corrected)
> > that would make the stable gate, well, stable, such that it required far
> > less work to keep it able to run a basic devstack test plus unit tests.
> > 
> > Does that sound at all sane?
> 
> A big source of problems IMO is that tempest doesn't have stable
> branches. We use the master branch of tempest to test stable branches of
> other projects, and tempest regularly adds new features. This guarantees
> instability if you rely on tempest anywhere in your gate (and cinder does).

Orthogonal to the discussion, but: this is not due to the lack of stable 
branch, but that part of the Tempest API are not stable yet. This is being 
addressed right now (in scope for Newton).
Once the Tempest stable API are used, no breakages should happen.

Ciao
-- 
Luigi

__
OpenStack Development Mailing 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] [Cinder] [stable] [all] Changing stable policy for drivers

2016-08-10 Thread Ben Swartzlander

On 08/10/2016 04:33 AM, Duncan Thomas wrote:

So I tried to get into helping with the cinder stable tree for a while,
and while I wasn't very successful (lack of time and an inability to
convince my employer it should be a priority), one thing I did notice it
that much of the breakage seemed to come from outside cinder - many of
the libraries we depend on make backwards incompatible changes by
accident, for example. Would it be possible to have a long-term-support
branch where we pinned the max version of everything for the gate, pips
and devtstack? I'd have thought (and I'm very willing to be corrected)
that would make the stable gate, well, stable, such that it required far
less work to keep it able to run a basic devstack test plus unit tests.

Does that sound at all sane?

A big source of problems IMO is that tempest doesn't have stable 
branches. We use the master branch of tempest to test stable branches of 
other projects, and tempest regularly adds new features. This guarantees 
instability if you rely on tempest anywhere in your gate (and cinder does).

-Ben Swartzlander

(I'm aware there are community standards for stable currently, but a lot
of this thread is the tail of standards wagging the dog of our goals.
Lets figure out what we want to achieve, and figure out how we can do
that without causing either too much extra work or an unnecessary fall
off in quality, rather than saying we can't do anything because of how
we do things now.)

On 10 August 2016 at 08:54, Tony Breeds > wrote:

On Tue, Aug 09, 2016 at 09:16:02PM -0700, John Griffith wrote:
> Sorry, I wasn't a part of the sessions in Austin on the topic of long
> terms support of Cinder drivers.  There's a lot going on during the 
summits
> these days.

For the record the session in Austin, that I think Matt was
referencing,  were
about stable life-cycles. not cinder specific.

> Yeah, ok... I do see your point here, and as I mentioned I have had this
> conversation with you and others over he years and I don't
disagree.  I also don't have the ability to "force"
> said parties to do things differently.  So when I try and help customers
> that are having issues my only recourse is an out of tree patch, which 
then
> when said distro notices or finds out they don't want to support the
> customer any longer based on the code no longer being "their blessed
> code".  The fact is that the distros hold the power in these situations, 
if
> they happen to own the OS release and the storage then it works out great
> for them, not so much for anybody else.

Right we can't 'force' the distros to participate (if we could we
wouldn't be
having this discussion).  The community has a process and all we can
do is
encourage distros and the like to participate in that process as it
really is
best for them, and us.

> So is the consensus here that the only viable solution is for people to
> invest in keeping the stable branches in general supported longer?  How
> does that work for projects that are interested and have people willing to
> do the work vs projects that don't have the people willing to do the work?
> In other words, Cinder has a somewhat unique problem that Nova, Glance and
> Keystone don't have.  So for Cinder to try and follow the policies,
> processes and philosophies you outlined does that mean that as a project
> Cinder has to try and bend the will of "ALL" of the projects to make this
> happen?  Doesn't seem very realistic to me.

So the 'Cinder' team wont need to do all the will bending, that's
for the
Stable team to do with the support of *everyone* that cares about
the outcome.
That probably doens't fill you with hope, but that is the reality.

> Just one last point and I'll move on from the topic.  I'm not sure where
> this illusion that we're testing all the drivers so well is coming from.
> Sure, we require the steps and facade of 3'rd party CI, but dig a bit
> deeper and you soon find that we're not really testing as much as some
> might think here.

That's probbaly true but if we created a 'mitaka-drivers' branch of
cinder the
gate CI would rapidly degernate to a noop any unit/functional tests
would be
*entirely* 3rd party.

Yours Tony.

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

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

--
--
Duncan Thomas

Re: [openstack-dev] [vitrage] spec for datasource

2016-08-10 Thread Afek, Ifat (Nokia - IL)

From: Yujun Zhang
Date: Tuesday, 9 August 2016 at 14:48

1. How do I register a new datasource in an existing system?
[yujunz] It seems to be in 
https://github.com/openstack/vitrage/blob/master/vitrage/datasources/__init__.py
Not exactly. This file defines the default datasources to be used. You can 
overwrite this list in /etc/vitrage/vitrage.conf. For example:

[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port

2. Is the type of datasource (ALARM/RESOURCE) configured in 
`/etc/vitrage/datasource_values/.yaml` ?

[Ifat]: No, it is configured in the datasource code. For information about 
datasource_values please see [3]
[yujunz] which code file? I found `category: RESOURCE` in the datasource 
configuration file as 
https://github.com/openstack/vitrage/blob/master/doc/source/resource-state-config.rst#format
EntityCategory is defined in 
https://github.com/openstack/vitrage/blob/master/vitrage/common/constants.py
It is used in the transformer files of each datasource.

5. What is the required data format for the datasource driver api? The inline 
comments give some brief description but didn't specify the api signature.
Many thanks.
[Ifat]: This should be part of the datasource documentation that we need to 
add. But basically, the driver should return a dictionary with few predefined 
fields (like datasource type, timestamp), and add whatever data is needed for 
the datasource. Then, the datasource transformer will transform this data into 
a vertex and decide where to connect it to the graph.
[yujunz] So if I understand it correctly, driver and transformer works as a 
pair and the intermediate data format is not exposed to vitrage. It consumes 
data from the sources and convert them into graph
Right.

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

2016-08-10 Thread Adam Young


On 08/09/2016 05:11 PM, Adam Young wrote:
The Fernet token format uses a symmetric key to sign tokens.  In order 
to check the signature, these keys need to be synchronized across all 
of the Keystone servers.



I don't want to pass around nake symmetric keys.  The right way to do 
this is to put them into a PKCS 11 Envelope.  Roughly, this:



1.  Each server generates a keypair and sends the public key to the 
undercloud


2.  undercloud generates a Fernet key

3.  Undercloud puts the Fernet token into a PKCS11 document signed 
with the overcloud nodes public key


4.  Undercloud posts the PKCS11 data to metadata

Sorry, PKCS12.  Not 11.



5.  os-*config Node downloads and stores the proper PKCS11 data

6.  Something unpackst the pkcs11 data and puts the key into the 
Fernet key store


That last step needs to make use of the keystone-manage fernet_rotate 
command.



How do we go about making this happen?  The key rotations should be 
scheduled infrequently; let me throw out monthly as a starting point 
for the discussion, although that is probably way too frequent.  How 
do we schedule this?  Is this a new stack that depends on the Keystone 
role?



__ 


OpenStack Development Mailing 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] Fernet Key rotation

2016-08-10 Thread Adam Young


On 08/09/2016 09:21 PM, Adam Young wrote:

On 08/09/2016 06:00 PM, Zane Bitter wrote:


In either case a good mechanism might be to use a Heat Software 
Deployment via the Heat API directly (i.e. not as part of a stack) to 
push changes to the servers. (I say 'push' but it's more a case of 
making the data available for os-collect-config to grab it.)


This is the part that interests me most.  The rest, I'll code in 
python and we can call either from mistral or from Cron.  What would a 
stack like this look like?  Are there comparable examples?



__ 


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

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


So, another aspect to the  problem is also that this needs to be done 
initially as part of the overcloud deployment.  If we go Fernet, the 
keys need to be in place when the Keystone servers boot.



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

Re: [openstack-dev] [puppet] proposal: start gating on puppet4

2016-08-10 Thread Matt Fischer

+1 from me also. This will help everyone who is trying to transition to it.

On Wed, Aug 10, 2016 at 1:46 AM, Javier Pena  wrote:

>
>
> - Original Message -
> > Hi,
> >
> > Today Puppet OpenStack CI is running unit and functional test jobs
> > against puppet 3 and puppet 4.
> > Unit jobs for puppet 4 are currently voting and pretty stable.
> > Functional jobs for puppet 4 are not voting but also stable.
> >
> > Even if Puppet4 has not been largely adopted by our community [1] yet,
> > I would like to encourage our users to upgrade the version of Puppet.
> > Fedora ships it by default [2] and for Ubuntu, it's also the default
> > since yakkety [3].
> >
> > [1]
> > https://docs.google.com/spreadsheets/d/1iIQ6YmpdOVctS2-
> wCV6SGPP1NSj8nKD9nv_xtZH9loY/edit?usp=sharing
> > [2] http://koji.fedoraproject.org/koji/packageinfo?packageID=3529
> > [3] http://packages.ubuntu.com/yakkety/puppet
> >
> > So here's my proposal, feel free to bring any feedback:
> > - For stable/mitaka CI and stable/liberty nothing will change.
> > - For current master (future stable/newton in a few months), transform
> > non-voting puppet4 jobs into voting and add them to the gate. Also
> > keep puppet3 unit tests jobs, as voting.
> > - After Newton release (during Ocata cycle), change master CI to only
> > gate functional jobs on puppet4 (and remove puppet3 jobs for
> > puppet-openstack-integration); but keep puppet3 unit tests jobs, as
> > voting.
> > - During Ocata cycle, implement a periodic job that will nightly check
> > we can deploy with Puppet3. The periodic job is something our
> > community interested by Puppet 3 will have to monitor and report any
> > new failure so we can address it.
> >
> > That way, we tell our users:
> > - don't worry if you deploy Liberty, Mitaka, Newton, we will
> > officially support Puppet 3.
> > - if you plan to deploy Puppet 4, we'll officially support you
> > starting from Newton.
> > - if you plan to deploy Ocata with Puppet 3, we won't support you
> > anymore since our functional testing jobs will be gone. Though we'll
> > make our best to be backward compatible thanks to our unit  and
> > periodic functional testing jobs.
> >
> > Regarding packaging:
> > - on Ubuntu, we'll continue rely on what provides Puppetlabs because
> > Xenial doesn't provide Puppet4.
> > - on CentOS7, we are working on getting Puppet 4 packaged in RDO and
> > our CI will certainly use it.
> >
> > Any feedback is welcome,
>
> I like the idea. It gives distros enough time to prepare to Puppet 4, and
> we're supposed to write compatible manifests anyway.
>
> Javier
>
> > --
> > 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
>
__
OpenStack Development Mailing 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] [meghdwar] Incubation Patches and irc call agenda

2016-08-10 Thread prakash RAMCHANDRAN

Please join the meeting  for Incubation and ptaches decision 

Meeting Wednesday 10th (14 Hr-15 Hr UTC )   [7AM-8AM PDT]

irc #openstck-megdwar

Follow up1 The last week agenda and actions taken or pending 2 Meghdwar Gateway 
API discussions https://review.openstack.org/#/c/319466/

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


3. What other modules are needed in OpenStack 'meghdwar'   a. Cloudlet 
(existing) - https://github.com/openedgecomputing
   b  Cloudlet Client (existing) - refer see fab install in provisioning
   c. Cloudlet Gateway Management  (Cluster Management) - Under Discussion
   d. python  Cloudlet  Cluster Management - Needs Discussion
   e. Cloudlet Agent - Need Dscussion
   f. Cloudlet horizon plugin for supporting d & e as GUI instead as CLI - 
Testing Murano
4. How do we go about priority - How to build and introduce Cloudlet Library , 
 5. Any other missing items.
ThanksPrakash__
OpenStack Development Mailing 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] [neutron][networking-ovs-dpdk] conntrack security group driver with ovs-dpdk

2016-08-10 Thread Kostiantyn.Volenbovskyi

Hi, 
> [Mooney, Sean K]
> In ovs 2.5 only linux kernel conntrack was supported assuming you had a 4.x
> kernel that supported it. that means that the feature was not available on
> bsd,windows or with dpdk.
Yup, I also thought about something like that.
I think I was at-least-slightly misguided by
http://docs.openstack.org/draft/networking-guide/adv-config-ovsfwdriver.html 
and there is currently a statement 
"The native OVS firewall implementation requires kernel and user space support 
for conntrack, thus requiring minimum versions of the Linux kernel and Open 
vSwitch. All cases require Open vSwitch version 2.5 or newer."

Do you agree that this is something to change? I think it is not OK to state 
OVS 2.6 without that being released, but in case I am not confusing then:
-OVS firewall driver with OVS that uses kernel datapath requires OVS 2.5 and 
Linux kernel 4.3
-OVS firewall driver with OVS that uses userspace datapath with DPDK (aka 
ovs-dpdk  aka DPDK vhost-user aka netdev datapath) doesn't have a Linux kernel 
prerequisite
That is documented in table in " ### Q: Are all features available with all 
datapaths?":
http://openvswitch.org/support/dist-docs/FAQ.md.txt 
where currently 'Connection tracking' row says 'NO' for 'Userspace' - but 
that's exactly what has been merged recently /to become feature of OVS 2.6

Also when it comes to performance I came across 
http://openvswitch.org/pipermail/dev/2016-June/071982.html, but I would guess 
that devil could be the exact flows/ct actions that will be present in 
real-life scenario.


BR, 
Konstantin


> -Original Message-
> From: Mooney, Sean K [mailto:sean.k.moo...@intel.com]
> Sent: Tuesday, August 09, 2016 2:29 PM
> To: Volenbovskyi Kostiantyn, INI-ON-FIT-CXD-ELC
> ; openstack-
> d...@lists.openstack.org
> Subject: RE: [openstack-dev] [neutron][networking-ovs-dpdk] conntrack security
> group driver with ovs-dpdk
> 
> 
> > -Original Message-
> > From: kostiantyn.volenbovs...@swisscom.com
> > [mailto:kostiantyn.volenbovs...@swisscom.com]
> > Sent: Tuesday, August 9, 2016 12:58 PM
> > To: openstack-dev@lists.openstack.org; Mooney, Sean K
> > 
> > Subject: RE: [openstack-dev] [neutron][networking-ovs-dpdk] conntrack
> > security group driver with ovs-dpdk
> >
> > Hi,
> > (sorry for using incorrect threading)
> >
> > > > About 2 weeks ago I did some light testing with the conntrack
> > > > security group driver and the newly
> > > >
> > > > Merged upserspace conntrack support in ovs.
> > > >
> > By 'recently' - whether you mean patch v4
> > http://openvswitch.org/pipermail/dev/2016-June/072700.html
> > or you used OVS 2.5 itself (which I think includes v2 of the same
> > patch series)?
> [Mooney, Sean K] I used http://openvswitch.org/pipermail/dev/2016-
> June/072700.html or specifically i used the following commit
> https://github.com/openvswitch/ovs/commit/0c87efe4b5017de4c5ae99e7b9c3
> 6e8a6e846669
> which is just after userspace conntrack was merged,
> >
> > So in general - I am a bit confused about conntrack support in OVS.
> >
> > OVS 2.5 release notes http://openvswitch.org/pipermail/announce/2016-
> > February/81.html state:
> > "This release includes the highly anticipated support for connection
> > tracking in the Linux kernel.  This feature makes it possible to
> > implement stateful firewalls and will be the basis for future stateful
> > features such as NAT and load-balancing.  Work is underway to bring
> > connection tracking to the userspace datapath (used by DPDK) and the
> > port to Hyper-V."  - in the way that 'work is underway' (=work is
> > ongoing) means that a time of OVS 2.5 release the feature was not
> > 'classified' as ready?
> [Mooney, Sean K]
> In ovs 2.5 only linux kernel conntrack was supported assuming you had a 4.x
> kernel that supported it. that means that the feature was not available on
> bsd,windows or with dpdk.
> 
> In the upcoming ovs 2.6 release conntrack support has been added to the
> Netdev datapath which is used with dpdk and on bsd. As far as I am aware
> windows conntrack support is still Missing but I may be wrong.
> 
> If you are interested the devstack local.conf I used to test that it 
> functioned is
> available here http://paste.openstack.org/show/552434/
> 
> I used an OpenStack vm using the Ubuntu 16.04 and 2 e1000 interfaces to do the
> testing.
> 
> 
> >
> >
> > BR,
> > Konstantin
> >
> >
> >
> > > On Sat, Aug 6, 2016 at 8:16 PM, Mooney, Sean K
> > 
> > > wrote:
> > > > Hi just a quick fyi,
> > > >
> > > > About 2 weeks ago I did some light testing with the conntrack
> > security
> > > > group driver and the newly
> > > >
> > > > Merged upserspace conntrack support in ovs.
> > > >
> > > >
> > > >
> > > > I can confirm that at least form my initial smoke tests where I
> > > >
> > > > Uses netcat ping and ssh to try and establish connections between
> > two
> > > > vms the
> > > >
> > > >

[openstack-dev] Is there a logging_exception_prefix option for Neutron (Juno) ?

2016-08-10 Thread Tom Li

Hi,

Does anyone know if the Neutron Juno release logging conf allows options
such as: logging_exception_prefix, logging_debug_format_suffix,
logging_default_format_string, logging_context_format_string like the other
general OS services?

>From the Juno doc (
http://docs.openstack.org/juno/config-reference/content/section_neutron.conf.html)
the only relevant variables that I found are : log_format and
log_date_format

They seem to be included in Neutron Mitaka release:
http://docs.openstack.org/mitaka/config-reference/networking/sample-configuration-files.html

thanks
-Tom
__
OpenStack Development Mailing 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] About third-party CI

2016-08-10 Thread Jim Rollenhagen

Hi Ironicers,

This email serves as a reminder (and a bit of a call to action) about our
third party CI policy:
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/third-party-ci.html

1) When I went to find a link to the policy, I realized that it isn't in our
developer docs, but only in our specs repo. Can someone volunteer to
document this in our dev docs?

2) A number of drivers do not have third-party CI up, let alone reporting
on patches. Unless someone moves quickly, I strongly suspect the following
drivers will be dropped from our tree before the end of Newton. These are
the setup.cfg names.

agent_amt
pxe_amt
fake_amt
agent_iboot
pxe_iboot
fake_iboot
agent_wol
pxe_wol
fake_wol
agent_vbox
fake_vbox
pxe_vbox
pxe_seamicro
fake_seamicro
pxe_drac
fake_drac
pxe_snmp
fake_snmp
pxe_msftocs
fake_msftocs

It's important to note that some ironic folks have taken the burden of
maintaining some untested drivers in an out-of-tree repo, however this
is not an official OpenStack project, and not part of the ironic governance.
https://git.openstack.org/cgit/openstack/ironic-staging-drivers

3) The SSH drivers (pxe_ssh and agent_ssh) that we use for some testing
currently are planned to be dropped. First, we need to update
project-config to make sure all of those jobs are moved to an equivalent
*_ipmitool job, and drop the _ssh jobs. Then we can go ahead and remove
the drivers. I'd like a volunteer for this as well, but am happy to take
it on as needed.

4) The drivers that use pyghmi (pxe_ipminative and agent_pyghmi) currently are
not tested in ironic's CI. We have multiple jobs for each of the ipmitool
drivers. Instead of making new jobs, we could just move one of the ipmitool
drivers to use the pyghmi drivers (since they both use IPMI, it should be
simple to do so). As with above, I'm happy to do this if there are no
volunteers.

Thanks for reading (and hopefully volunteering!).

// 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] [new][neutron] python-neutronclient 5.1.0 release (newton)

We are chuffed to announce the release of:

python-neutronclient 5.1.0: CLI and Client Library for OpenStack
Networking

This release is part of the newton release series.

With source available at:

https://git.openstack.org/cgit/openstack/python-neutronclient

With package available at:

https://pypi.python.org/pypi/python-neutronclient

Please report issues through launchpad:

https://bugs.launchpad.net/python-neutronclient

For more details, please see below.

5.1.0
^

New Features

* Add "network trunk create", "network trunk list", "network trunk
  set", "network trunk unset", "network trunk delete" and "network
  subport list" OSC commands for trunk resource along with client
  bindings. [Blueprint vlan-aware-vms
  (https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms)]

* Added support to log 'x-openstack-request-id' for each api call.

Changes in python-neutronclient 5.0.0..5.1.0


9f78b63 Add Python 3.5 classifier and venv
092c3e5 Make find_resourceid_by_id public in python binding class
0dbbb9c Updated from global requirements
43403b7 Add long option to network trunk list command
449a1f7 Add trunk commands to openstackclient
84c4216 Move find_resource family to API binding layer
8876ab2 Add client exception for HostNotCompatibleWithFixedIps
45d18eb Remove discover from test-requirements
53e2ad1 Log request-id for each api call
8fe56df Add segment as an attribute to subnet in client


Diffstat (except docs and test files)
-

neutronclient/common/exceptions.py |   4 +
neutronclient/neutron/v2_0/__init__.py |  96 +--
neutronclient/neutron/v2_0/subnet.py   |   6 +
neutronclient/neutron/v2_0/tag.py  |   3 +-
neutronclient/osc/v2/trunk/__init__.py |   0
neutronclient/osc/v2/trunk/network_trunk.py| 380 
neutronclient/v2_0/client.py   | 134 +
.../add-osc-trunk-commands-7e77283a369729c5.yaml   |   8 +
.../notes/log-request-id-64bef955b8292c18.yaml |   3 +
requirements.txt   |   4 +-
setup.cfg  |   8 +
test-requirements.txt  |   1 -
tox.ini|   2 +-
21 files changed, 1346 insertions(+), 103 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 8d91b3c..3ce9a23 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -12 +12 @@ oslo.serialization>=1.10.0 # Apache-2.0
-oslo.utils>=3.15.0 # Apache-2.0
+oslo.utils>=3.16.0 # Apache-2.0
@@ -14 +14 @@ os-client-config>=1.13.1 # Apache-2.0
-keystoneauth1>=2.7.0 # Apache-2.0
+keystoneauth1>=2.10.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index fa8057a..0fa7f50 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -7 +6,0 @@ coverage>=3.6 # Apache-2.0
-discover # BSD



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

Re: [openstack-dev] [requirements] History lesson please

2016-08-10 Thread Matthew Thode

On 08/10/2016 07:30 AM, Ian Cordasco wrote:
> To be clear, I think the requirements work Tony is doing has the potential to 
> make things worse for some subset of deployers/operators.
> 
> --  
> Ian Cordasco

Any change we make has the potential to make things worse for some subset :P

-- 
-- Matthew Thode (prometheanfire)



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] Nova mascot

2016-08-10 Thread Bob Ball

> TL;DR: If you don’t want a mascot, you don’t have to. But Nova, you’ll be 
> missed. :-)

It also seems from http://www.openstack.org/project-mascots that the majority 
of OpenStack projects have selected a mascot.  I think it would be a great 
shame if the Nova project didn’t have an easily recognisable image within this 
branding effort while the majority of projects we interact with do have them.  
I think there are a number of cases where the lack of a mascot for such a 
prominent project would be very noticeable, particularly when the other “big” 
projects have one.

Unfortunately, the Vauxhall Nova and Marvel’s Nova are not permitted in the 
rules, so rather than the default being “no logo”  I’d personally just go with 
a supernova[1][2] as it wouldn’t need explanations or deep discussions as to 
whether a field mouse is a better choice than an African sand dog…

Bob

[1] http://www.supernovae.net/images/illustration.jpg
[2] 
https://upload.wikimedia.org/wikipedia/commons/0/09/Artist's_impression_of_supernova_1993J.jpg

__
OpenStack Development Mailing 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] [new][oslo] taskflow 2.5.0 release (newton)

We are exuberant to announce the release of:

taskflow 2.5.0: Taskflow structured state management library.

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/taskflow

With package available at:

https://pypi.python.org/pypi/taskflow

Please report issues through launchpad:

http://bugs.launchpad.net/taskflow/

For more details, please see below.

Changes in taskflow 2.4.0..2.5.0


b8ed052 Updated from global requirements
ad23e3d Change dependency to use flavors


Diffstat (except docs and test files)
-

requirements.txt  |  2 +-
setup.cfg | 28 
test-requirements.txt | 39 ---
tox.ini   |  4 +++-
4 files changed, 32 insertions(+), 41 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 6e54d79..394337a 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -49 +49 @@ retrying!=1.3.0,>=1.2.3 # Apache-2.0
-cachetools>=1.0.0 # MIT License
+cachetools>=1.1.0 # MIT License



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

Re: [openstack-dev] [requirements] History lesson please

2016-08-10 Thread Ian Cordasco

 

-Original Message-
From: Erno Kuvaja 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: August 10, 2016 at 05:53:14
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [requirements] History lesson please

> On Wed, Aug 10, 2016 at 9:27 AM, Thomas Goirand wrote:
> > On 08/09/2016 08:33 PM, Ian Cordasco wrote:
> >>
> >>
> >> -Original Message-
> >> From: John Dickinson  
> >> Reply: OpenStack Development Mailing List (not for usage questions)  
> >> Date: August 9, 2016 at 13:17:08
> >> To: OpenStack Development Mailing List  
> >> Subject: Re: [openstack-dev] [requirements] History lesson please
> >>
> >>> I'd like to advocate for *not* raising minimum versions very often. Every 
> >>> time some  
> OpenStack
> >>> project raises minimum versions, this change is propagated to all 
> >>> projects, and  
> that
> >>> puts extra burden on anyone who is maintaining packages and dependencies 
> >>> in their  
> own
> >>> deployment. If one project needs a new feature introduced in version 32, 
> >>> but another  
> >>> project claims compatibility with >=28, that's ok. There's no need for 
> >>> the second  
> project
> >>> to raise the minimum version when there isn't a conflict. (This is the 
> >>> position I advocated  
> >>> for at the Austin summit.)
> >>>
> >>> Yes, I know that currently we don't test every possible version 
> >>> permutation. Yes,  
> I know
> >>> that doing that is hard. I'm not ignoring that.
> >>
> >> Right. So with the current set-up, where these requirements are propogated 
> >> to every  
> project, how do projects express their own minimum version requirement?
> >>
> >> Let's assume someone is maintaining their own packages and dependencies.
> >> If (for example) Glance requires a minimum version of Routes and Nova has
> >> a minimum requirement newer than Glance's, they're not coinstallable
> >> (which was the original goal of the requirements team).
> >
> > Not necessarily. Take for example Swift. It has lower requirements than
> > other projects in OpenStack. Yet, Swift is fully co-installable with all
> > other OpenStack projects. They just support lower versions than others.
> >
> This just makes lifecycle management total nightmare if different
> project has different requirements within same release. Lets say we
> have these projects Swift, X and Y that supports the lower versions,
> now we decide to deploy Z to that same cloud but Z has higher
> requirement than Swift, X and Y, so we need to upgrade that
> requirement at minimum to that new level required by Z.
>  
> Having 3 options here:
> 1) We upgrade the requirement to the new level system wide and restart
> Swift, X and Y to avoid any nasty surprises later down the line, which
> is risky and disruptive by itself.
> 2) We containerize/use venv for Z and provide the new version of the
> dependency just for that.
> 3) We deploy Z to it's own node.
>  
> None of these are great user experience or contains significant risk
> on production, makes version management total nightmare and gives us
> more "happy" ops running OS. Having uniform requirements range, at
> least we can be pretty confident that deploying new service from same
> release will drop in and likely at least not break anything else if
> the dependencies are within the range. Obviously we might hit to
> version of dependency that has issue just with Z, but at least the
> damage is contained to the new service.

This is exactly what I was referring to when I said "co-installable". When I 
started learning the ways of OpenStack I had the same very naïve definition 
based on ranges and allowing projects to have different ranges. If a deployer 
is packaging things, all will be fine using a version for their services until 
they add that new service later which requires a higher version.

So again, this leaves us with two options:

- Raise minimum required versions very infrequently (as some seem to prefer) 
and explicitly prohibit use of new features in more recent versions of libraries
- Coordinate minimum version bumps on a more consistent basis to allow projects 
to not duplicate code already present in the libraries they're attempting to use

As a *developer* I'd prefer the latter. As a deployer using OpenStack-Ansible, 
either one is fine because OSA uses upper-constraints as recommended by the 
requirements team. That said, I recognize everyone deploys OpenStack just 
differently enough to cause the second option to be painful. Hence why I said 
"I'd like this to happen" but I never said it must.

To be clear, I think the requirements work Tony is doing has the potential to 
make things worse for some subset of deployers/operators.

--  
Ian Cordasco


__
OpenStack Development Mailing List (not for usage

[openstack-dev] [new][oslo] oslo.versionedobjects 1.15.0 release (newton)

We are glowing to announce the release of:

oslo.versionedobjects 1.15.0: Oslo Versioned Objects library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.versionedobjects

With package available at:

https://pypi.python.org/pypi/oslo.versionedobjects

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.versionedobjects

For more details, please see below.

Changes in oslo.versionedobjects 1.14.0..1.15.0
---

ac4d396 Updated from global requirements


Diffstat (except docs and test files)
-

requirements.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 2e55edb..ca11536 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6,2 +6,2 @@ oslo.concurrency>=3.8.0 # Apache-2.0
-oslo.config>=3.12.0 # Apache-2.0
-oslo.context!=2.6.0,>=2.4.0 # Apache-2.0
+oslo.config>=3.14.0 # Apache-2.0
+oslo.context>=2.4.0 # Apache-2.0



__
OpenStack Development Mailing 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] [new][oslo] oslo.serialization 2.13.0 release (newton)

We are exuberant to announce the release of:

oslo.serialization 2.13.0: Oslo Serialization library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.serialization

With package available at:

https://pypi.python.org/pypi/oslo.serialization

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.serialization

For more details, please see below.

Changes in oslo.serialization 2.12.0..2.13.0


d8e6057 Drop H803 in flake8 ignore list
a73120a Fix serialization of binary strings in Python3


Diffstat (except docs and test files)
-

oslo_serialization/jsonutils.py| 12 +---
tox.ini|  3 +--
3 files changed, 13 insertions(+), 5 deletions(-)




__
OpenStack Development Mailing 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] [new][oslo] oslo.service 1.15.0 release (newton)

We are delighted to announce the release of:

oslo.service 1.15.0: oslo.service library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.service

With package available at:

https://pypi.python.org/pypi/oslo.service

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.service

For more details, please see below.

Changes in oslo.service 1.14.0..1.15.0
--

bde278f Updated from global requirements


Diffstat (except docs and test files)
-

requirements.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 8df3c2b..0d7f994 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -11 +11 @@ oslo.concurrency>=3.8.0 # Apache-2.0
-oslo.config>=3.12.0 # Apache-2.0
+oslo.config>=3.14.0 # Apache-2.0



__
OpenStack Development Mailing 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] [new][oslo] oslo.vmware 2.13.0 release (newton)

We are pleased to announce the release of:

oslo.vmware 2.13.0: Oslo VMware library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.vmware

With package available at:

https://pypi.python.org/pypi/oslo.vmware

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.vmware

For more details, please see below.

Changes in oslo.vmware 2.12.0..2.13.0
-

03faa1c Method to download file to VMware server


Diffstat (except docs and test files)
-

oslo_vmware/image_transfer.py| 30 ++
2 files changed, 56 insertions(+)




__
OpenStack Development Mailing 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] [new][oslo] oslo.rootwrap 5.1.0 release (newton)

We are mirthful to announce the release of:

oslo.rootwrap 5.1.0: Oslo Rootwrap

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.rootwrap

With package available at:

https://pypi.python.org/pypi/oslo.rootwrap

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.rootwrap

For more details, please see below.

Changes in oslo.rootwrap 5.0.0..5.1.0
-

a46b731 Fix parameters of assertEqual are misplaced


Diffstat (except docs and test files)
-

2 files changed, 32 insertions(+), 32 deletions(-)




__
OpenStack Development Mailing 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] [new][oslo] oslo.messaging 5.7.0 release (newton)

We are thrilled to announce the release of:

oslo.messaging 5.7.0: Oslo Messaging API

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.messaging

With package available at:

https://pypi.python.org/pypi/oslo.messaging

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.messaging

For more details, please see below.

Changes in oslo.messaging 5.6.0..5.7.0
--

7c5d039 Move zmq driver options into its own group
51652c5 Updated from global requirements
2003a52 Updated from global requirements
9e61efa [zmq] Use zmq.IMMEDIATE option for round-robin


Diffstat (except docs and test files)
-

oslo_messaging/_cmd/zmq_proxy.py   |   5 +-
oslo_messaging/_drivers/impl_pika.py   |   0
oslo_messaging/_drivers/impl_zmq.py|  96 ++--
.../dealer/zmq_dealer_publisher_proxy.py   |   2 +-
.../_drivers/zmq_driver/client/zmq_client.py   |   8 +-
.../_drivers/zmq_driver/client/zmq_receivers.py|   3 +-
.../zmq_driver/client/zmq_routing_table.py |   3 +-
.../zmq_driver/client/zmq_sockets_manager.py   |   5 +-
.../_drivers/zmq_driver/proxy/zmq_proxy.py |   2 +-
.../_drivers/zmq_driver/proxy/zmq_queue_proxy.py   |  14 ++-
.../server/consumers/zmq_consumer_base.py  |   6 +-
.../server/consumers/zmq_dealer_consumer.py|   2 +-
.../server/consumers/zmq_router_consumer.py|   2 +-
.../_drivers/zmq_driver/server/zmq_server.py   |  13 ++-
oslo_messaging/_drivers/zmq_driver/zmq_address.py  |   4 +-
oslo_messaging/_drivers/zmq_driver/zmq_options.py  | 122 +
oslo_messaging/_drivers/zmq_driver/zmq_socket.py   |  41 ---
oslo_messaging/_drivers/zmq_driver/zmq_updater.py  |   2 +-
oslo_messaging/conffixture.py  |   3 +-
oslo_messaging/opts.py |   5 +-
requirements.txt   |   4 +-
setup-test-env-zmq-proxy.sh|   1 +
setup-test-env-zmq-pub-sub.sh  |   1 +
setup-test-env-zmq.sh  |   1 +
tools/simulator.py |   2 +-
33 files changed, 246 insertions(+), 178 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 27f578b..f58bf6b 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8 +8 @@ futurist!=0.15.0,>=0.11.0 # Apache-2.0
-oslo.config>=3.12.0 # Apache-2.0
+oslo.config>=3.14.0 # Apache-2.0
@@ -20 +20 @@ six>=1.9.0 # MIT
-cachetools>=1.0.0 # MIT License
+cachetools>=1.1.0 # MIT License



__
OpenStack Development Mailing 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] [new][oslo] oslo.reports 1.14.0 release (newton)

We are tickled pink to announce the release of:

oslo.reports 1.14.0: oslo.reports library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.reports

With package available at:

https://pypi.python.org/pypi/oslo.reports

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.reports

For more details, please see below.

Changes in oslo.reports 1.13.0..1.14.0
--

d332969 Updated from global requirements


Diffstat (except docs and test files)
-

test-requirements.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index a180841..a27784d 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -13 +13 @@ sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
-oslo.config>=3.12.0 # Apache-2.0
+oslo.config>=3.14.0 # Apache-2.0



__
OpenStack Development Mailing 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] [new][oslo] oslo.policy 1.14.0 release (newton)

We are joyful to announce the release of:

oslo.policy 1.14.0: Oslo Policy library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.policy

With package available at:

https://pypi.python.org/pypi/oslo.policy

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.policy

For more details, please see below.

Changes in oslo.policy 1.13.0..1.14.0
-

804be59 Revert "Adds debug logging for policy file validation"
1d2b26d Updated from global requirements
b82bfe0 Delete H803 in flake8 ignore
5a65133 Allow policy file to not exist


Diffstat (except docs and test files)
-

oslo_policy/policy.py| 28 ++-
requirements.txt |  2 +-
tox.ini  |  3 +--
4 files changed, 63 insertions(+), 12 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index a954394..bdd7366 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ requests>=2.10.0 # Apache-2.0
-oslo.config>=3.12.0 # Apache-2.0
+oslo.config>=3.14.0 # Apache-2.0



__
OpenStack Development Mailing 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] [new][oslo] oslo.log 3.14.0 release (newton)

We are gleeful to announce the release of:

oslo.log 3.14.0: oslo.log library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.log

With package available at:

https://pypi.python.org/pypi/oslo.log

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.log

For more details, please see below.

Changes in oslo.log 3.13.0..3.14.0
--

8a3fdb3 Updated from global requirements
7757808 Updated from global requirements


Diffstat (except docs and test files)
-

requirements.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index a288b0b..e6a740d 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7,2 +7,2 @@ six>=1.9.0 # MIT
-oslo.config>=3.12.0 # Apache-2.0
-oslo.context!=2.6.0,>=2.4.0 # Apache-2.0
+oslo.config>=3.14.0 # Apache-2.0
+oslo.context>=2.4.0 # Apache-2.0



__
OpenStack Development Mailing 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] [new][oslo] oslo.middleware 3.17.0 release (newton)

We are glowing to announce the release of:

oslo.middleware 3.17.0: Oslo Middleware library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.middleware

With package available at:

https://pypi.python.org/pypi/oslo.middleware

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.middleware

For more details, please see below.

Changes in oslo.middleware 3.16.0..3.17.0
-

37d1a0f Updated from global requirements
23c772c Replace deprecated LOG.warn with LOG.warning


Diffstat (except docs and test files)
-

oslo_middleware/cors.py | 4 ++--
requirements.txt| 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index fdbfbf4..0c6af5d 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7,2 +7,2 @@ Jinja2>=2.8 # BSD License (3 clause)
-oslo.config>=3.12.0 # Apache-2.0
-oslo.context!=2.6.0,>=2.4.0 # Apache-2.0
+oslo.config>=3.14.0 # Apache-2.0
+oslo.context>=2.4.0 # Apache-2.0



__
OpenStack Development Mailing 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] [new][oslo] oslo.config 3.15.0 release (newton)

We are frolicsome to announce the release of:

oslo.config 3.15.0: Oslo Configuration API

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.config

With package available at:

https://pypi.python.org/pypi/oslo.config

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.config

For more details, please see below.

Changes in oslo.config 3.14.0..3.15.0
-

4cf28c7 Advanced Option


Diffstat (except docs and test files)
-

oslo_config/cfg.py  | 49 -
oslo_config/generator.py|  9 ++-
oslo_config/sphinxext.py|  7 ++
5 files changed, 154 insertions(+), 2 deletions(-)




__
OpenStack Development Mailing 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] [new][oslo] oslo.db 4.11.0 release (newton)

We are frolicsome to announce the release of:

oslo.db 4.11.0: Oslo Database library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.db

With package available at:

https://pypi.python.org/pypi/oslo.db

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.db

For more details, please see below.

Changes in oslo.db 4.10.0..4.11.0
-

f3d123a Updated from global requirements
9376e01 Add a hook to process newly created engines


Diffstat (except docs and test files)
-

oslo_db/sqlalchemy/enginefacade.py|  9 -
requirements.txt  |  2 +-
3 files changed, 25 insertions(+), 2 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 6befe2a..5bfff26 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9 +9 @@ oslo.i18n>=2.1.0 # Apache-2.0
-oslo.config>=3.12.0 # Apache-2.0
+oslo.config>=3.14.0 # Apache-2.0



__
OpenStack Development Mailing 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] [new][oslo] oslo.context 2.8.0 release (newton)

We are gleeful to announce the release of:

oslo.context 2.8.0: Oslo Context library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.context

With package available at:

https://pypi.python.org/pypi/oslo.context

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.context

For more details, please see below.

Changes in oslo.context 2.7.0..2.8.0


765eaa6 Delete H803 in flake8 ignore list


Diffstat (except docs and test files)
-

tox.ini | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)




__
OpenStack Development Mailing 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] [new][oslo] debtcollector 1.8.0 release (newton)