Re: [openstack-dev] [neutron] [stadium] subprojects on independent release cycle

[Armando M.]

On 2 February 2017 at 16:09, Armando M.  wrote:

> Hi neutrinos,
>
> I have put a number of patches in the merge queue for a few sub-projects.
> We currently have a number of these that are on an independent release
> schedule. In particular:
>
>- networking-bagpipe
>- networking-bgpvpn
>- networking-midonet
>- networking-odl
>- networking-sfc
>
> Please make sure that between now and March 10th [1], you work to prepare
> at least one ocata release that works with neutron's [2] and cut a stable
> branch before than. That would incredibly help consumers who are interested
> in assembling these bits together and start testing ocata as soon as it's
> out.
>
> Your collaboration is much appreciated.
>
> Many thanks,
> Armando
>

Hi neutrinos,

I did not hear anything back from the liaisons of the above mentioned
project over the past few days. Can you clarify your plans for cutting an
Ocata release?

Thanks,
Armando


> [1] https://releases.openstack.org/ocata/schedule.html
> [2] https://review.openstack.org/#/c/428474/
>
__
OpenStack Development Mailing 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] [Horizon][Karbor][Magnum] Requesting FFE for xstatic packages

[Adrian Otto]

We are actively working to verify that magnum-ui works with the adjusted 
requirements.txt, and as soon as we have confirmed this change is 
non-disruptive, I will be ready to approve the FFE.

Adrian

> On Feb 7, 2017, at 4:54 PM, Richard Jones  wrote:
> 
> It looks like Magnum-UI only has one xstatic package in their
> requirements that isn't already in Horizon's requirements (and
> therefore is superfluous), and that's xstatic-magic-search, which has
> been replaced in Horizon by pulling magic search into the Horizon tree
> (we forked because maintaining our own extensions against the package
> was getting out of hand - we'd basically rewritten a large proportion
> of the code).
> 
> I would recommend that the Magnum-UI project remove all xstatic
> packages from requirements.txt
> 
> 
>Richard
> 
> On 7 February 2017 at 14:17, Tony Breeds  wrote:
>> On Tue, Feb 07, 2017 at 10:39:41AM +1100, Richard Jones wrote:
>>> Hi requirements team,
>>> 
>>> We've had a downstream packager come to us with issues packaging the
>>> Horizon RC as described in this bug report:
>>> 
>>> https://bugs.launchpad.net/horizon/+bug/1662180
>>> 
>>> The issues stems from the requirements file having several xstatic
>>> package minimum versions specified that are no longer compatible with
>>> Horizon, and the RDO build system honors those minimum version
>>> specifications, and boom!
>> 
>> This is a specific case of OpenStack provides poor tools for 
>> testing/validating
>> minimum requirements.  This is a thing we started trying to fix in Ocata but
>> the work is slow going :(   I'm a little confused how this wasn't caught 
>> sooner
>> by RDO (given they would appear to have been testing the minimums for 
>> xstatic-*)
>> 
>>> Rob Cresswell has proposed a patch to bump those minimum versions up
>>> to the versions specified in upper-constraints.txt:
>>> 
>>>  https://review.openstack.org/#/c/429753
>> 
>> That review seems to adjust all Xstatic packages where the minimu != the
>> constrained version which is probably more than is required but it doesn't
>> actually increase the knock-on effects so it seems like a good idea to me :)
>> 
>> Looking at the projects that are affected by Rob's review:
>> 
>> Package  : xstatic-angular [xstatic-angular>=1.3.7] (used by 3 projects)
>> Package  : xstatic-angular-bootstrap 
>> [xstatic-angular-bootstrap>=0.11.0.2] (used by 3 projects)
>> Package  : xstatic-angular-gettext [xstatic-angular-gettext>=2.1.0.2] 
>> (used by 3 projects)
>> Package  : xstatic-bootstrap-scss [xstatic-bootstrap-scss>=3.1.1.1] 
>> (used by 3 projects)
>> Package  : xstatic-d3 [xstatic-d3>=3.1.6.2] (used by 3 projects)
>> Package  : xstatic-font-awesome [xstatic-font-awesome>=4.3.0] (used by 3 
>> projects)
>> Package  : xstatic-jasmine [xstatic-jasmine>=2.1.2.0] (used by 3 
>> projects)
>> Package  : xstatic-jsencrypt [xstatic-jsencrypt>=2.0.0.2] (used by 3 
>> projects)
>> Package  : xstatic-rickshaw [xstatic-rickshaw>=1.5.0] (used by 3 
>> projects)
>> Package  : xstatic-smart-table [xstatic-smart-table!=1.4.13.0,>=1.4.5.3] 
>> (used by 3 projects)
>> Package  : xstatic-term-js [xstatic-term-js>=0.0.4.1] (used by 3 
>> projects)
>> openstack/horizon [tc:approved-release]
>> openstack/karbor-dashboard[]
>> openstack/magnum-ui   []
>> 
>> 
>> Package  : xstatic-bootswatch [xstatic-bootswatch>=3.3.5.3] (used by 1 
>> projects)
>> openstack/horizon [tc:approved-release]
>> 
>> And obviously RDO
>> 
>> This will mean that Horizon will need an RC2, and any packaging/distro 
>> testing
>> for horizon (and plugins/dashboards) will need to be restarted (iff said
>> testing was done with an xstatic package not listed in 
>> upper-constraaints.txt[1])
>> 
>> I tried to determine the impact on magnum-ui and karbor-dashboard and AFAICT
>> they're already using constraints.  The next thing to look at is the release
>> model which is:
>>magnum-ui:
>> type: horizon-plugin
>> model: cycle-with-intermediary
>>karbor-dashboard:
>> type:  unknown
>> model: unknown
>> 
>> I think this means it's safe grant this FFE as the affected plugins aren't
>> necessarily in a stabilisation phase.
>> 
>> So as far as I can see we have 2 options:
>>1. Do nothing: there will be other cases that minimums are not functional.
>>   RDO have tools and data to fix this in there own repos so we're not
>>   actually blocking them
>>2. Take the patch, and accept the knock on effects.
>> 
>> I'm okay with taking this FFE if Karbor and Magnum PTLs sign off here (or on 
>> the review)
>> 
>>> Additionally to the above I will be proposing a patch to Horizon's
>>> documented processes to ensure that when an xstatic upper-constraints
>>> version is bumped we also bump the minimum version in
>>> global-requirements to 

Re: [openstack-dev] [oslo] pbr and warnerrors status

[Jay Faulkner]

> On Feb 8, 2017, at 8:15 AM, Ben Nemec  wrote:
> 
> 
> 
> On 02/08/2017 09:41 AM, Doug Hellmann wrote:
>> Excerpts from Ben Nemec's message of 2017-02-08 09:20:31 -0600:
>>> 
>>> On 02/08/2017 01:53 AM, Andreas Jaeger wrote:
 On 2017-02-08 00:56, Ian Cordasco  wrote:
> 
> 
> On Feb 7, 2017 5:47 PM, "Joshua Harlow"  > wrote:
> 
>Likely just never pulled the trigger.
> 
>Seems like we should pull it though.
> 
> 
> 
> Will have to wait until Pike given the library release freeze
 
 I've pushed a patch to release pbr so that we won't forget about it:
 
 https://review.openstack.org/430618
 
 Andreas
 
>>> 
>>> Great, thanks everybody!
>>> 
>> 
>> It would be useful for someone to look at the pbr change and verify that
>> releasing it as-is won't break the builds for a bunch of projects by
>> turning the flag back on. If it will, we're going to want to provide a
>> way to stage the roll out. If we change the name of the flag, for
>> example, we could release pbr for support for checking warnings, and
>> then projects could enable that when they have time and with the fixes
>> to the docs needed to make it work properly.
> 
> I think the only way to do this would be to run a docs build in every project 
> with warnerrors turned on, using the unreleased pbr.  Given the amount of 
> time it's been broken, there's a good chance some issues have snuck in (they 
> had in diskimage-builder).  So maybe deprecating the old option name and 
> requiring another explicit opt-in from everyone is the safest way to go.
> 
> Thoughts on a new name?  fatalwarnings maybe?
> 

IMO, I’d suggest skipping this and just fixing the broken attribute. Projects 
that are impacted by the change simply need to merge a one-line change to set 
warnerrors=false. FWIW, you can actually run a local docs build, find and 
resolve warnings without the PBR change. It seems overkill to me to change the 
term since doing so will be super confusing to anyone who hasn’t read this 
mailing list thread.

If there’s a significant enough concern, a change could be pushed to set 
warnerrors=false on the projects that are concerned before this release is made.

-
Jay Faulkner
OSIC

> __
> OpenStack Development Mailing 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] [Horizon][Karbor][Magnum] Requesting FFE for xstatic packages

[Adrian Otto]

I voted to merge [1] and [2]:

[1] https://review.openstack.org/#/c/429753/
[2] https://review.openstack.org/#/c/430941/

FFE approved for Magnum, provided this does not cause problems for other 
projects.

Adrian

On Feb 8, 2017, at 7:25 AM, Adrian Otto 
> wrote:

We are actively working to verify that magnum-ui works with the adjusted 
requirements.txt, and as soon as we have confirmed this change is 
non-disruptive, I will be ready to approve the FFE.

Adrian

On Feb 7, 2017, at 4:54 PM, Richard Jones 
> wrote:

It looks like Magnum-UI only has one xstatic package in their
requirements that isn't already in Horizon's requirements (and
therefore is superfluous), and that's xstatic-magic-search, which has
been replaced in Horizon by pulling magic search into the Horizon tree
(we forked because maintaining our own extensions against the package
was getting out of hand - we'd basically rewritten a large proportion
of the code).

I would recommend that the Magnum-UI project remove all xstatic
packages from requirements.txt


  Richard

On 7 February 2017 at 14:17, Tony Breeds 
> wrote:
On Tue, Feb 07, 2017 at 10:39:41AM +1100, Richard Jones wrote:
Hi requirements team,

We've had a downstream packager come to us with issues packaging the
Horizon RC as described in this bug report:

https://bugs.launchpad.net/horizon/+bug/1662180

The issues stems from the requirements file having several xstatic
package minimum versions specified that are no longer compatible with
Horizon, and the RDO build system honors those minimum version
specifications, and boom!

This is a specific case of OpenStack provides poor tools for testing/validating
minimum requirements.  This is a thing we started trying to fix in Ocata but
the work is slow going :(   I'm a little confused how this wasn't caught sooner
by RDO (given they would appear to have been testing the minimums for xstatic-*)

Rob Cresswell has proposed a patch to bump those minimum versions up
to the versions specified in upper-constraints.txt:

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

That review seems to adjust all Xstatic packages where the minimu != the
constrained version which is probably more than is required but it doesn't
actually increase the knock-on effects so it seems like a good idea to me :)

Looking at the projects that are affected by Rob's review:

Package  : xstatic-angular [xstatic-angular>=1.3.7] (used by 3 projects)
Package  : xstatic-angular-bootstrap [xstatic-angular-bootstrap>=0.11.0.2] 
(used by 3 projects)
Package  : xstatic-angular-gettext [xstatic-angular-gettext>=2.1.0.2] (used 
by 3 projects)
Package  : xstatic-bootstrap-scss [xstatic-bootstrap-scss>=3.1.1.1] (used 
by 3 projects)
Package  : xstatic-d3 [xstatic-d3>=3.1.6.2] (used by 3 projects)
Package  : xstatic-font-awesome [xstatic-font-awesome>=4.3.0] (used by 3 
projects)
Package  : xstatic-jasmine [xstatic-jasmine>=2.1.2.0] (used by 3 projects)
Package  : xstatic-jsencrypt [xstatic-jsencrypt>=2.0.0.2] (used by 3 
projects)
Package  : xstatic-rickshaw [xstatic-rickshaw>=1.5.0] (used by 3 projects)
Package  : xstatic-smart-table [xstatic-smart-table!=1.4.13.0,>=1.4.5.3] 
(used by 3 projects)
Package  : xstatic-term-js [xstatic-term-js>=0.0.4.1] (used by 3 projects)
openstack/horizon [tc:approved-release]
openstack/karbor-dashboard[]
openstack/magnum-ui   []


Package  : xstatic-bootswatch [xstatic-bootswatch>=3.3.5.3] (used by 1 
projects)
openstack/horizon [tc:approved-release]

And obviously RDO

This will mean that Horizon will need an RC2, and any packaging/distro testing
for horizon (and plugins/dashboards) will need to be restarted (iff said
testing was done with an xstatic package not listed in 
upper-constraaints.txt[1])

I tried to determine the impact on magnum-ui and karbor-dashboard and AFAICT
they're already using constraints.  The next thing to look at is the release
model which is:
  magnum-ui:
   type: horizon-plugin
   model: cycle-with-intermediary
  karbor-dashboard:
   type:  unknown
   model: unknown

I think this means it's safe grant this FFE as the affected plugins aren't
necessarily in a stabilisation phase.

So as far as I can see we have 2 options:
  1. Do nothing: there will be other cases that minimums are not functional.
 RDO have tools and data to fix this in there own repos so we're not
 actually blocking them
  2. Take the patch, and accept the knock on effects.

I'm okay with taking this FFE if Karbor and Magnum PTLs sign off here (or on 
the review)

Additionally to the above I will be proposing a patch to Horizon's
documented processes to ensure that when an xstatic upper-constraints
version is bumped we also bump the minimum 

Re: [openstack-dev] [oslo] pbr and warnerrors status

[Ben Nemec]

On 02/08/2017 09:41 AM, Doug Hellmann wrote:

Excerpts from Ben Nemec's message of 2017-02-08 09:20:31 -0600:


On 02/08/2017 01:53 AM, Andreas Jaeger wrote:

On 2017-02-08 00:56, Ian Cordasco  wrote:



On Feb 7, 2017 5:47 PM, "Joshua Harlow" > wrote:

Likely just never pulled the trigger.

Seems like we should pull it though.



Will have to wait until Pike given the library release freeze


I've pushed a patch to release pbr so that we won't forget about it:

https://review.openstack.org/430618

Andreas



Great, thanks everybody!



It would be useful for someone to look at the pbr change and verify that
releasing it as-is won't break the builds for a bunch of projects by
turning the flag back on. If it will, we're going to want to provide a
way to stage the roll out. If we change the name of the flag, for
example, we could release pbr for support for checking warnings, and
then projects could enable that when they have time and with the fixes
to the docs needed to make it work properly.


I think the only way to do this would be to run a docs build in every 
project with warnerrors turned on, using the unreleased pbr.  Given the 
amount of time it's been broken, there's a good chance some issues have 
snuck in (they had in diskimage-builder).  So maybe deprecating the old 
option name and requiring another explicit opt-in from everyone is the 
safest way to go.


Thoughts on a new name?  fatalwarnings maybe?

__
OpenStack Development Mailing 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] [fuel][release] Opting out of Ocata?

[Vladimir Kuklin]

Dims

Thank you for keeping the hand on the pulse.

I am going to take over the PTL duties and we are going to produce releases
according to the wiki
. We are going to
have RC1 next week (around Feb 15). After that we are going to proceed as
planned for March 6th Ocata release.

On Wed, Feb 8, 2017 at 1:47 AM, Davanum Srinivas  wrote:

> Dear Fuel Team,
>
> There have been no releases for fuel-* projects in the Ocata time frame:
> https://git.openstack.org/cgit/openstack/releases/tree/deliverables/ocata
>
> Fuel projects under governance are supposed to be following the
> "cycle-trailing" schedule:
> https://releases.openstack.org/reference/release_models.
> html#cycle-trailing
>
> Please see Ocata schedule:
> https://releases.openstack.org/ocata/schedule.html#o-trailing
>
> Is anyone still around keeping the lights on?
>
> Thanks,
> Dims
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.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] [oslo] pbr and warnerrors status

[Doug Hellmann]

Excerpts from Ben Nemec's message of 2017-02-08 09:20:31 -0600:
> 
> On 02/08/2017 01:53 AM, Andreas Jaeger wrote:
> > On 2017-02-08 00:56, Ian Cordasco  wrote:
> >>
> >>
> >> On Feb 7, 2017 5:47 PM, "Joshua Harlow"  >> > wrote:
> >>
> >> Likely just never pulled the trigger.
> >>
> >> Seems like we should pull it though.
> >>
> >>
> >>
> >> Will have to wait until Pike given the library release freeze
> >
> > I've pushed a patch to release pbr so that we won't forget about it:
> >
> > https://review.openstack.org/430618
> >
> > Andreas
> >
> 
> Great, thanks everybody!
> 

It would be useful for someone to look at the pbr change and verify that
releasing it as-is won't break the builds for a bunch of projects by
turning the flag back on. If it will, we're going to want to provide a
way to stage the roll out. If we change the name of the flag, for
example, we could release pbr for support for checking warnings, and
then projects could enable that when they have time and with the fixes
to the docs needed to make it work properly.

Doug

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

Re: [openstack-dev] [all][tc][swift][designate] New language addition process has been approved

[Coles, Alistair]

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: 08 February 2017 13:49
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][tc][swift][designate] New language addition
> process has been approved
> 
> On 19/01/17 11:59 +0100, Flavio Percoco wrote:
> >Greetings,
> >
> >The Technical Committe recently approved a new reference document
> which
> >describes how new programming languages can be proposed for inclusion
> >as supported languages by OpenStack. The new reference document can be
> >found here[0].
> >
> >I'd like to take this chance not only to share this new process - which
> >in my opinion is a good step forward for the entire community - but to
> >invite other teams to take a stab at it and move forward the inclusion
> >of Go, which is the last language that was discussed for inclusion in the
> community.
> >
> >I hope folks will find this process useful and that it'll help
> >innovating OpenStack. I'm sure the process is not perfect and that
> >we'll have to refine it as we go so, let's get going.
> >
> >Thanks everyone,
> >Flavio
> >
> >[0]
> >https://governance.openstack.org/tc/reference/new-language-requirements
> >.html
> 
> 
> Hey folks,
> 
> Sorry for pressing so much on this but, would it be safe to assume that no
> one from the swift and/or designate team are intereted in proposing golang
> through this process?
> 
> That's what I'm assuming at least given the silence on this thread.
> 

I can only speak for myself, but I anticipate that this is something we would 
discuss at the PTG.

Alistair

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

Re: [openstack-dev] [oslo] pbr and warnerrors status

[Ben Nemec]

On 02/08/2017 01:53 AM, Andreas Jaeger wrote:

On 2017-02-08 00:56, Ian Cordasco  wrote:



On Feb 7, 2017 5:47 PM, "Joshua Harlow" > wrote:

Likely just never pulled the trigger.

Seems like we should pull it though.



Will have to wait until Pike given the library release freeze


I've pushed a patch to release pbr so that we won't forget about it:

https://review.openstack.org/430618

Andreas



Great, thanks everybody!

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

Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

[Ihar Hrachyshka]

Has the liberty-eol cleanup happened? Because I still see
stable/liberty branch in openstack/neutron repo, which gets in the way
of some logic around proactive backports:
https://review.openstack.org/#/c/427936/4/bugs-fixed-since.py@75, and
I see backports proposed for the branch that is no longer supported
and has broken gate setup.

Please advise,
Ihar

On Wed, Dec 14, 2016 at 4:54 AM, Joshua Hesketh
 wrote:
> The repos listed[0] have had stable/liberty branch removed and replaced with
> a liberty-eol tag. Any open reviews have been abandoned.
>
> Please let me know if there are any mistakes or latecomers to the list.
>
> Cheers,
> Josh
>
> [0]
> https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
>
> On Fri, Dec 9, 2016 at 3:55 PM, Joshua Hesketh 
> wrote:
>>
>> Hey Tony and all,
>>
>> I'm happy to take care of these retirements. However I probably can't get
>> to it until Tuesday next week. So assuming no other infra root beats me to
>> it I'll look at it then.
>>
>> Cheers,
>> Josh
>>
>> On Thu, Dec 8, 2016 at 3:58 PM, Tony Breeds 
>> wrote:
>>>
>>> On Tue, Nov 22, 2016 at 01:35:48PM +1100, Tony Breeds wrote:
>>>
>>> > I'll batch the removal of the stable/liberty branches between Nov 28th
>>> > and Dec
>>> > 3rd (UTC+1100).  Then during Decemeber I'll attempt to cleanup
>>> > zuul/layout.yaml
>>> > to remove liberty exclusions and jobs.
>>>
>>> This took longer as there are a few repos that are scheduled for EOL that
>>> were a
>>> little problematic during the kilo cycle.  I've updated the list at [1]
>>>
>>> Can the infra team please run eol_branch.sh [2] over the repos listed at
>>> that
>>> URL [1] and flagged with 'Please EOL'.  The others will need to be done
>>> later.
>>>
>>> eol_branch.sh needs just the repo names what can be generated with
>>> something like:
>>>
>>> URL=https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
>>> eol_branch.sh REPOS=$(curl -s $URL | awk '/Please EOL/ {print $1}')
>>>
>>> The data format is a balance between human and machine readable.
>>>
>>> Yours Tony.
>>>
>>> [1]
>>> https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4ac#file-liberty_eol_data-txt
>>> [2]
>>> http://git.openstack.org/cgit/openstack-infra/release-tools/tree/eol_branch.sh
>>>
>>> ___
>>> OpenStack-Infra mailing list
>>> openstack-in...@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [release][oslo] recreating the stable/ocata branch for mox3

[Joshua Harlow]

Doug Hellmann wrote:

Excerpts from ChangBo Guo's message of 2017-02-08 10:41:04 +0800:

Thanks Doug and amoralej,  we should avoid this :(．

One more thought about mox3: Is it used outside of OpenStack? If yes,
Maybe we can retire mox3 if all projects move mox to mock.


I thought our policy was that mox3 was already deprecated and all new
tests should use mock instead. Converting the existing tests can be
non-trivial because of the differences in how the two libraries work,
but it would help us move off of mox3.


Sounds like one of those community goals (like move off oslo-incubator) 
to me :)




Doug


2017-02-07 23:00 GMT+08:00 Doug Hellmann:


The stable/ocata branch for mox3 was created from 0.19.0 and then 0.20.0
was released from master. Because that repository sees a very low rate
of changes, and because the current stable/ocata branch only contained
the patch to update the .gitreview file, we decided to recreate the
branch to accurately reflect the intent of having 0.20.0 be part of the
ocata series of releases.

https://review.openstack.org/430283

Thanks go to amoralej for pointing out the issue today.

Doug

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



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


__
OpenStack Development Mailing 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] [stadium] subprojects on independent release cycle

[Armando M.]

On 8 February 2017 at 09:13, Thomas Morin  wrote:

> Hi Armando,
>
> As far as networking-bgpvpn and networking-bagpipe are concerned, the plan
> is to do like we've been doing for the past 2 releases, which is to cut a
> branch and make a release not too far after Openstack.
> The date of March 10th looks reasonable as a target, and we'll stick to
> that.
>
>
Excellent,

thanks for the update.

Cheers,
Armando

Best,
>
> -Thomas
>
>
>
> On 2 February 2017 at 16:09, Armando M.  wrote:
>
>> Hi neutrinos,
>>
>> I have put a number of patches in the merge queue for a few sub-projects.
>> We currently have a number of these that are on an independent release
>> schedule. In particular:
>>
>>- networking-bagpipe
>>- networking-bgpvpn
>>- networking-midonet
>>- networking-odl
>>- networking-sfc
>>
>> Please make sure that between now and March 10th [1], you work to prepare
>> at least one ocata release that works with neutron's [2] and cut a stable
>> branch before than. That would incredibly help consumers who are interested
>> in assembling these bits together and start testing ocata as soon as it's
>> out.
>>
>> Your collaboration is much appreciated.
>>
>> Many thanks,
>> Armando
>>
>
> Hi neutrinos,
>
> I did not hear anything back from the liaisons of the above mentioned
> project over the past few days. Can you clarify your plans for cutting an
> Ocata release?
>
> Thanks,
> Armando
>
>
>> [1] https://releases.openstack.org/ocata/schedule.html
>> [2] https://review.openstack.org/#/c/428474/
>>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [neutron] [stadium] subprojects on independent release cycle

[Thomas Morin]

Hi Armando,

As far as networking-bgpvpn and networking-bagpipe are concerned, the 
plan is to do like we've been doing for the past 2 releases, which is to 
cut a branch and make a release not too far after Openstack.
The date of March 10th looks reasonable as a target, and we'll stick to 
that.


Best,

-Thomas


On 2 February 2017 at 16:09, Armando M. > wrote:


   Hi neutrinos,

   I have put a number of patches in the merge queue for a few
   sub-projects. We currently have a number of these that are on an
   independent release schedule. In particular:

 * networking-bagpipe
 * networking-bgpvpn
 * networking-midonet
 * networking-odl
 * networking-sfc

   Please make sure that between now and March 10th [1], you work to
   prepare at least one ocata release that works with neutron's [2] and
   cut a stable branch before than. That would incredibly help
   consumers who are interested in assembling these bits together and
   start testing ocata as soon as it's out.

   Your collaboration is much appreciated.

   Many thanks,
   Armando


Hi neutrinos,

I did not hear anything back from the liaisons of the above mentioned 
project over the past few days. Can you clarify your plans for cutting 
an Ocata release?


Thanks,
Armando


   [1] https://releases.openstack.org/ocata/schedule.html
   
   [2] https://review.openstack.org/#/c/428474/
   





__
OpenStack Development Mailing 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] [neutron] [stadium] subprojects on independent release cycle

[Henry Fourie]

Armando,
   networking-sfc will cut a stable/ocata branch by March 10.

-Louis

From: Armando M. [mailto:arma...@gmail.com]
Sent: Wednesday, February 08, 2017 8:16 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [stadium] subprojects on independent 
release cycle



On 2 February 2017 at 16:09, Armando M. 
> wrote:
Hi neutrinos,

I have put a number of patches in the merge queue for a few sub-projects. We 
currently have a number of these that are on an independent release schedule. 
In particular:

  *   networking-bagpipe
  *   networking-bgpvpn
  *   networking-midonet
  *   networking-odl
  *   networking-sfc
Please make sure that between now and March 10th [1], you work to prepare at 
least one ocata release that works with neutron's [2] and cut a stable branch 
before than. That would incredibly help consumers who are interested in 
assembling these bits together and start testing ocata as soon as it's out.

Your collaboration is much appreciated.

Many thanks,
Armando

Hi neutrinos,

I did not hear anything back from the liaisons of the above mentioned project 
over the past few days. Can you clarify your plans for cutting an Ocata release?

Thanks,
Armando


[1] https://releases.openstack.org/ocata/schedule.html
[2] https://review.openstack.org/#/c/428474/

__
OpenStack Development Mailing 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] Moving mirror server images to tarballs.o.o (Was: [rdo-list] RDO-CI Scrum Weekly Scrum Recap)

[Paul Belanger]

On Wed, Feb 08, 2017 at 08:50:10AM -0500, John Trowbridge wrote:
> Moving this thread from rdo-list, but leaving in copy as it is relevant
> there too. However it is more of a TripleO topic.
> 
> On 02/07/2017 03:56 PM, Paul Belanger wrote:
> > On Tue, Feb 07, 2017 at 03:34:09PM -0500, Ronelle Landy wrote:
> >> Greetings All,
> >>
> >> Links to the RDO-CI team scrum[1] and recording[2] from this week's
> >> meeting are below.
> >>
> >> Highlights:
> >>
> >>  - TripleO CI images outage 
> >>   [3] details the images missing from the mirror, causing CI failures
> >>   We need a less 'reactive' approach to checking that the gates are working
> >>   Action Items:
> >> Attila added [4] to run check jobs and measure passing
> >> IRC Bot needed to ping #oooq with failures
> > It would be great if we can finally replace this private infrastructure in
> > tripleo-ci with our community openstack-infra servers. This avoids the need 
> > for
> > tripleo-ci project to maintain servers.  Also, we likely have more HDD space
> > available.
> > 
> > I recently helped kolla move there images to tarballs.o.o, we can do the 
> > same
> > for tripleo-ci.
> > 
> 
> That would be awesome. We want to cover stable release images as well,
> and the current tripleo-ci mirror server seems inadequate for that. Are
> there any docs on how to publish to tarballs.o.o? Right now, the image
> upload happens in two stages. First, all periodic jobs of a particular
> type (HA I think?) upload the images they built to the mirror server.
> Second, when all periodic jobs pass on a particular dlrn hash the
> symlink for the "known good" image is updated.
> 
We basically create a publisher in JJB to handle this, which looks in the
$WORKSPACE/images folder for things to scp to tarballs.o.o.  Take a look at the
kolla job for example.

What we can do, is create an experimental job first test the uploads to
tarballs.o.o, once working, we can then update the jobs you have listed.

> It seems like to start we could maybe update this symlink swapping logic
> to instead publish the image on tarballs.o.o, and use that location as
> the known good. That would still result in using the current mirror
> server as a store of images under test, but it would give the gates
> which consume the known good images (and users/devs who do that) much
> more stability.
> 
> Maybe it would be possible to use tarballs.o.o for the testing images as
> well, but then we would need some sort of cleanup and some way to mark
> which images there are actually good (which seems a bit more complicated).
> 
> >>  -  Upgrade CI status
> >>   There is a periodic job running on internal jenkins [5] testing upgrades
> >>   [6] adds the sanity checks so that upgrade jobs will be able to check 
> >> services without a full overcloud deployment
> >>  - Ocata Pipeline status
> >>   Phase 1 passed on Friday - but still some reviews outstanding (image 
> >> build, release configs)
> >>   Phase 2 - jobs have been set up internally
> >> All baremetal jobs are failing due to JJB mismatches (master vs 
> >> rdo_trunk for ocata)
> >>  - DCI team is interested in using quickstart-extras
> >>   RDO-CI team to support this usage 
> >>   
> >>
> >> [1] - https://review.rdoproject.org/etherpad/p/rdo-infra-scrum
> >> [2] - https://bluejeans.com/s/ugrW6/
> >> [3] - https://bugs.launchpad.net/tripleo/+bug/1661656
> >> [4] - https://review.openstack.org/430277
> >> [5] -  >> jenkins>/RDO/view/openstack_virtual_baremetal/job/tripleo-quickstart-newton-to-master-upgrade-ovb-qeos7-rhos-dev-ci-multi-nic/
> >> [6] - https://review.openstack.org/#/c/429716/
> >>
> >> /R
> >>
> >> Ronelle Landy
> >>
> >> ___
> >> rdo-list mailing list
> >> rdo-l...@redhat.com
> >> https://www.redhat.com/mailman/listinfo/rdo-list
> >>
> >> To unsubscribe: rdo-list-unsubscr...@redhat.com
> > 
> > ___
> > rdo-list mailing list
> > rdo-l...@redhat.com
> > https://www.redhat.com/mailman/listinfo/rdo-list
> > 
> > To unsubscribe: rdo-list-unsubscr...@redhat.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] [neutron][networking-l2gw] ocata release?

[Sukhdev Kapur]

Gary,

Thank you - you da man...

-Sukhdev


On Sun, Feb 5, 2017 at 11:27 PM, Gary Kotton  wrote:

> Done - https://review.openstack.org/gitweb?p=openstack/networking-
> l2gw.git;a=shortlog;h=refs/heads/stable/ocata
> A luta continua
>
> On 2/6/17, 8:51 AM, "Gary Kotton"  wrote:
>
> Hi,
> Yes, I will go and do this.
> Thanks
> Gary
>
> On 2/6/17, 4:05 AM, "Takashi Yamamoto"  wrote:
>
> hi,
>
> is anyone going to cut ocata release/branch for networking-l2gw?
>
> 
> __
> OpenStack Development Mailing 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] [nova] Cells meeting canceled

[Dan Smith]

Hi all,

Today's cells meeting is canceled. We're still working on getting ocata
out the door, a bunch of normal participants are out today, and not much
has transpired for pike just yet.

--Dan

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

[Kendall Nelson]

Hello All!

So I am sure we've all seen it: people writing terminal commands into our
project channels, misusing '/' commands, etc. But have any of you actually
done it?

If any of you cores, ptls or other upstanding members of our wonderful
community have had one of these embarrassing experiences please reply! I am
writing an article for the SuperUser trying to make us all seem a little
more human to people new to the community and new to using IRC. It can be
scary asking questions to such a large group of smart people and its even
more off putting when we make mistakes in front of them.

So please share your stories!

-Kendall Nelson (diablo_rojo)
__
OpenStack Development Mailing 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] [stadium] subprojects on independent release cycle

[Isaku Yamahata]

Regarding to networking-odl, we're going to cut stable/ocata branch
around Feb 11. After a while testing, the release will be done to avoid much 
delay
the official schedule.
The plan for Pike is to graduate from independent model.

thanks,

On Wed, Feb 08, 2017 at 08:16:13AM -0800,
"Armando M."  wrote:

> On 2 February 2017 at 16:09, Armando M.  wrote:
> 
> > Hi neutrinos,
> >
> > I have put a number of patches in the merge queue for a few sub-projects.
> > We currently have a number of these that are on an independent release
> > schedule. In particular:
> >
> >- networking-bagpipe
> >- networking-bgpvpn
> >- networking-midonet
> >- networking-odl
> >- networking-sfc
> >
> > Please make sure that between now and March 10th [1], you work to prepare
> > at least one ocata release that works with neutron's [2] and cut a stable
> > branch before than. That would incredibly help consumers who are interested
> > in assembling these bits together and start testing ocata as soon as it's
> > out.
> >
> > Your collaboration is much appreciated.
> >
> > Many thanks,
> > Armando
> >
> 
> Hi neutrinos,
> 
> I did not hear anything back from the liaisons of the above mentioned
> project over the past few days. Can you clarify your plans for cutting an
> Ocata release?
> 
> Thanks,
> Armando
> 
> 
> > [1] https://releases.openstack.org/ocata/schedule.html
> > [2] https://review.openstack.org/#/c/428474/
> >

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


-- 
Isaku Yamahata 

__
OpenStack Development Mailing 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] [stadium] subprojects on independent release cycle

[Gary Kotton]

Regarding vmware-nsx we are planning to cut a version in the coming days.
Thanks
Gary

On 2/8/17, 8:51 PM, "Isaku Yamahata"  wrote:


Regarding to networking-odl, we're going to cut stable/ocata branch
around Feb 11. After a while testing, the release will be done to avoid 
much delay
the official schedule.
The plan for Pike is to graduate from independent model.

thanks,

On Wed, Feb 08, 2017 at 08:16:13AM -0800,
"Armando M."  wrote:

> On 2 February 2017 at 16:09, Armando M.  wrote:
> 
> > Hi neutrinos,
> >
> > I have put a number of patches in the merge queue for a few 
sub-projects.
> > We currently have a number of these that are on an independent release
> > schedule. In particular:
> >
> >- networking-bagpipe
> >- networking-bgpvpn
> >- networking-midonet
> >- networking-odl
> >- networking-sfc
> >
> > Please make sure that between now and March 10th [1], you work to 
prepare
> > at least one ocata release that works with neutron's [2] and cut a 
stable
> > branch before than. That would incredibly help consumers who are 
interested
> > in assembling these bits together and start testing ocata as soon as 
it's
> > out.
> >
> > Your collaboration is much appreciated.
> >
> > Many thanks,
> > Armando
> >
> 
> Hi neutrinos,
> 
> I did not hear anything back from the liaisons of the above mentioned
> project over the past few days. Can you clarify your plans for cutting an
> Ocata release?
> 
> Thanks,
> Armando
> 
> 
> > [1] https://releases.openstack.org/ocata/schedule.html
> > [2] https://review.openstack.org/#/c/428474/
> >

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


-- 
Isaku Yamahata 

__
OpenStack Development Mailing 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] Moving mirror server images to tarballs.o.o (Was: [rdo-list] RDO-CI Scrum Weekly Scrum Recap)

[Jeremy Stanley]

On 2017-02-08 14:10:16 -0500 (-0500), Paul Belanger wrote:
[...]
> We basically create a publisher in JJB to handle this, which looks in the
> $WORKSPACE/images folder for things to scp to tarballs.o.o.  Take a look at 
> the
> kolla job for example.
> 
> What we can do, is create an experimental job first test the uploads to
> tarballs.o.o, once working, we can then update the jobs you have listed.
[...]

Friendly reminder to also keep an eye on
http://cacti.openstack.org/cacti/graph.php?action=view_graph_id=311_id=all
since its current flavor tops out at 800mbps and can cause some
nasty blowback in the CI if it gets pegged for extended periods of
time. Longer-term, we need a way to publish artifacts our jobs are
reusing into the AFS mirror network so that the traffic can be
localized to each provider and not, e.g., dragged across the
Atlantic Ocean when jobs are running on a node in France.
-- 
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] [release][oslo] recreating the stable/ocata branch for mox3

[Doug Hellmann]

Excerpts from Joshua Harlow's message of 2017-02-08 10:01:27 -0800:
> Doug Hellmann wrote:
> > Excerpts from ChangBo Guo's message of 2017-02-08 10:41:04 +0800:
> >> Thanks Doug and amoralej,  we should avoid this :(．
> >>
> >> One more thought about mox3: Is it used outside of OpenStack? If yes,
> >> Maybe we can retire mox3 if all projects move mox to mock.
> >
> > I thought our policy was that mox3 was already deprecated and all new
> > tests should use mock instead. Converting the existing tests can be
> > non-trivial because of the differences in how the two libraries work,
> > but it would help us move off of mox3.
> 
> Sounds like one of those community goals (like move off oslo-incubator) 
> to me :)

It could be, sure. We need a volunteer to organize it.

Doug

> 
> >
> > Doug
> >
> >> 2017-02-07 23:00 GMT+08:00 Doug Hellmann:
> >>
> >>> The stable/ocata branch for mox3 was created from 0.19.0 and then 0.20.0
> >>> was released from master. Because that repository sees a very low rate
> >>> of changes, and because the current stable/ocata branch only contained
> >>> the patch to update the .gitreview file, we decided to recreate the
> >>> branch to accurately reflect the intent of having 0.20.0 be part of the
> >>> ocata series of releases.
> >>>
> >>> https://review.openstack.org/430283
> >>>
> >>> Thanks go to amoralej for pointing out the issue today.
> >>>
> >>> Doug
> >>>
> >>> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

[openstack-dev] [keystone] ocata backport potential tag

[Lance Bragstad]

Hi all,

Now that Pike is open for development, I've create an official
ocata-backport-potential bug tag. In the event you see a bug that affects
Ocata, feel free to use the tag.

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

Re: [openstack-dev] [neutron] [stadium] subprojects on independent release cycle

[Takashi Yamamoto]

i plan to cut a release for networking-midonet once relevant projects get ready.
ie. neutron-vpnaas, tap-as-a-service

On Thu, Feb 9, 2017 at 1:16 AM, Armando M.  wrote:
>
>
> On 2 February 2017 at 16:09, Armando M.  wrote:
>>
>> Hi neutrinos,
>>
>> I have put a number of patches in the merge queue for a few sub-projects.
>> We currently have a number of these that are on an independent release
>> schedule. In particular:
>>
>> networking-bagpipe
>> networking-bgpvpn
>> networking-midonet
>> networking-odl
>> networking-sfc
>>
>> Please make sure that between now and March 10th [1], you work to prepare
>> at least one ocata release that works with neutron's [2] and cut a stable
>> branch before than. That would incredibly help consumers who are interested
>> in assembling these bits together and start testing ocata as soon as it's
>> out.
>>
>> Your collaboration is much appreciated.
>>
>> Many thanks,
>> Armando
>
>
> Hi neutrinos,
>
> I did not hear anything back from the liaisons of the above mentioned
> project over the past few days. Can you clarify your plans for cutting an
> Ocata release?
>
> Thanks,
> Armando
>
>>
>> [1] https://releases.openstack.org/ocata/schedule.html
>> [2] https://review.openstack.org/#/c/428474/
>
>
>
> __
> OpenStack Development Mailing 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] [Horizon][Karbor][Magnum] Requesting FFE for xstatic packages

[Tony Breeds]

On Wed, Feb 08, 2017 at 03:42:06PM +, Adrian Otto wrote:
> I voted to merge [1] and [2]:
> 
> [1] https://review.openstack.org/#/c/429753/
> [2] https://review.openstack.org/#/c/430941/
> 
> FFE approved for Magnum, provided this does not cause problems for other 
> projects.

Thanks everyone for the quick attention to the problem and understanding!

Tony.


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

Re: [openstack-dev] [All] IRC Mishaps

[Jay Pipes]

On 02/08/2017 03:36 PM, Kendall Nelson wrote:

Hello All!

So I am sure we've all seen it: people writing terminal commands into
our project channels, misusing '/' commands, etc. But have any of you
actually done it?

If any of you cores, ptls or other upstanding members of our wonderful
community have had one of these embarrassing experiences please reply! I
am writing an article for the SuperUser trying to make us all seem a
little more human to people new to the community and new to using IRC.
It can be scary asking questions to such a large group of smart people
and its even more off putting when we make mistakes in front of them.

So please share your stories!


Hi!

I can't tell you the number of times I've typed or pasted one of these:

:wq

or

1407gg

or

ggVG

or

:find nova/compute/resource_tracker.py

or

Vgq

or

tox -py27 -- --failing

Such is the life of a keyboard-driven contributor I guess! :)

-jay

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

Re: [openstack-dev] [All] IRC Mishaps

[Michael Still]

At a previous employer we had a policy that all passwords started with "/"
because of the sheer number of times someone typed the root password into a
public IRC channel.

Michael

On Thu, Feb 9, 2017 at 10:04 AM, Jay Pipes  wrote:

> On 02/08/2017 03:36 PM, Kendall Nelson wrote:
>
>> Hello All!
>>
>> So I am sure we've all seen it: people writing terminal commands into
>> our project channels, misusing '/' commands, etc. But have any of you
>> actually done it?
>>
>> If any of you cores, ptls or other upstanding members of our wonderful
>> community have had one of these embarrassing experiences please reply! I
>> am writing an article for the SuperUser trying to make us all seem a
>> little more human to people new to the community and new to using IRC.
>> It can be scary asking questions to such a large group of smart people
>> and its even more off putting when we make mistakes in front of them.
>>
>> So please share your stories!
>>
>
> Hi!
>
> I can't tell you the number of times I've typed or pasted one of these:
>
> :wq
>
> or
>
> 1407gg
>
> or
>
> ggVG
>
> or
>
> :find nova/compute/resource_tracker.py
>
> or
>
> Vgq
>
> or
>
> tox -py27 -- --failing
>
> Such is the life of a keyboard-driven contributor I guess! :)
>
> -jay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
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] [openstack-ansible] Propose Marc Gariepy as core reviewer

[Jimmy McCrory]

+1

On Mon, Feb 6, 2017 at 12:17 PM, Hugh Saunders  wrote:

> +1
>
> On Fri, 3 Feb 2017 at 19:50 Steve Lewis  wrote:
>
>> On Fri, Feb 3, 2017 at 5:33 AM, Jesse Pretorius <
>> jesse.pretor...@rackspace.co.uk> wrote:
>>
>> I’d like to propose Marc Gariepy [1] as a core reviewer for
>> OpenStack-Ansible.
>>
>>
>> +1.
>> --
>> SteveL
>> 
>> __
>> OpenStack Development Mailing 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] IRC Mishaps

[Travis McPeak]

How about the crowd favorite of accidentally submitting your password in
chat instead of where you were trying to?

At least people can help you evaluate your password strength :)

On Wed, Feb 8, 2017, 12:38 PM Kendall Nelson  wrote:

> Hello All!
>
> So I am sure we've all seen it: people writing terminal commands into our
> project channels, misusing '/' commands, etc. But have any of you actually
> done it?
>
> If any of you cores, ptls or other upstanding members of our wonderful
> community have had one of these embarrassing experiences please reply! I am
> writing an article for the SuperUser trying to make us all seem a little
> more human to people new to the community and new to using IRC. It can be
> scary asking questions to such a large group of smart people and its even
> more off putting when we make mistakes in front of them.
>
> So please share your stories!
>
> -Kendall Nelson (diablo_rojo)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][all] started branching tools and requirements

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2017-02-08 08:29:45 -0500:
> We have started the process of branching devstack, grenade, and the
> requirements repo. This may introduce some instability into the gate
> until we are finished. Please join #openstack-release if you would like
> to follow along.
> 
> Doug
> 

We hit a few speed bumps today, but things are moving again. We all
owe a big thanks to Sean Dague, Steve Martinelli, Dean Troyer, Matt
Riedeman, and Dan Smith for their help debugging and fixing issues
with Keystone, python-openstackclient, and grenade over the course
of the day.

The next step in the process is to wait for
https://review.openstack.org/429753 to land in openstack/requirements.
After that we can branch the requirements repository. Given the
current check and gate job delays, I expect that to happen over the
next several hours. It's the end of my day, so I'll be checking in
tomorrow morning before creating the branch.

Doug

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

Re: [openstack-dev] [All] IRC Mishaps

[Kendall Nelson]

Thanks Jay :) Pretty sure we've all been there!

On Wed, Feb 8, 2017, 3:08 PM Jay Pipes  wrote:

> On 02/08/2017 03:36 PM, Kendall Nelson wrote:
> > Hello All!
> >
> > So I am sure we've all seen it: people writing terminal commands into
> > our project channels, misusing '/' commands, etc. But have any of you
> > actually done it?
> >
> > If any of you cores, ptls or other upstanding members of our wonderful
> > community have had one of these embarrassing experiences please reply! I
> > am writing an article for the SuperUser trying to make us all seem a
> > little more human to people new to the community and new to using IRC.
> > It can be scary asking questions to such a large group of smart people
> > and its even more off putting when we make mistakes in front of them.
> >
> > So please share your stories!
>
> Hi!
>
> I can't tell you the number of times I've typed or pasted one of these:
>
> :wq
>
> or
>
> 1407gg
>
> or
>
> ggVG
>
> or
>
> :find nova/compute/resource_tracker.py
>
> or
>
> Vgq
>
> or
>
> tox -py27 -- --failing
>
> Such is the life of a keyboard-driven contributor I guess! :)
>
> -jay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] IRC Mishaps

[Kendall Nelson]

I've definitely done this before :) Thanks for sharing!

On Wed, Feb 8, 2017, 3:13 PM Travis McPeak  wrote:

> How about the crowd favorite of accidentally submitting your password in
> chat instead of where you were trying to?
>
> At least people can help you evaluate your password strength :)
>
> On Wed, Feb 8, 2017, 12:38 PM Kendall Nelson 
> wrote:
>
> Hello All!
>
> So I am sure we've all seen it: people writing terminal commands into our
> project channels, misusing '/' commands, etc. But have any of you actually
> done it?
>
> If any of you cores, ptls or other upstanding members of our wonderful
> community have had one of these embarrassing experiences please reply! I am
> writing an article for the SuperUser trying to make us all seem a little
> more human to people new to the community and new to using IRC. It can be
> scary asking questions to such a large group of smart people and its even
> more off putting when we make mistakes in front of them.
>
> So please share your stories!
>
> -Kendall Nelson (diablo_rojo)
>
> __
> OpenStack Development Mailing 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] Refstack - final mascot

[Arkady.Kanevsky]

+1

From: Rochelle Grober [mailto:rochelle.gro...@huawei.com]
Sent: Tuesday, February 07, 2017 8:36 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] Refstack - final mascot

Looks great to me.

--Rocky

From: Catherine Cuong Diep [mailto:cd...@us.ibm.com]
Sent: Monday, February 06, 2017 4:25 PM
To: OpenStack Dev Mailer 
>
Subject: [openstack-dev] Refstack - final mascot


Hello RefStack team,

Please see RefStack mascot in Heidi's note below.

Catherine Diep
- Forwarded by Catherine Cuong Diep/San Jose/IBM on 02/06/2017 04:18 PM 
-

From: Heidi Joy Tretheway 
>
To: Catherine Cuong Diep/San Jose/IBM@IBMUS
Date: 02/02/2017 11:42 AM
Subject: Refstack - final mascot





Hi Catherine,

I have a new revision from our illustration team for your team’s project 
mascot. We’re pushing hard to get all 60 of the mascots finalized by the PTG, 
so I’d love any feedback from your team as swiftly as possible. As a reminder, 
we can’t change the illustration style (since it’s consistent throughout the 
full mascot set) and so we’re just looking for problems with the creatures. 
Could you please let me know if your team has any final concerns?

Thank you!

[cid:image001.png@01D28240.35CFBBD0]




Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation
503 816 9769 | Skype: 
heidi.tretheway



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

[Lana Brindley]

On 09/02/17 06:36, Kendall Nelson wrote:
> Hello All!
> 
> So I am sure we've all seen it: people writing terminal commands into our 
> project channels, misusing '/' commands, etc. But have any of you actually 
> done it?
> 
> If any of you cores, ptls or other upstanding members of our wonderful 
> community have had one of these embarrassing experiences please reply! I am 
> writing an article for the SuperUser trying to make us all seem a little more 
> human to people new to the community and new to using IRC. It can be scary 
> asking questions to such a large group of smart people and its even more off 
> putting when we make mistakes in front of them.
> 
> So please share your stories!

What about the one where you're conducting a private conversation in one 
window, and watching a group chat in another one, and then drop some deeply 
personal (or embarrassing!) content in the group chat instead the PM ;)

L

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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

Re: [openstack-dev] [Blazar] bug list before next release

[Masahito MUROI]

Hi Hiroaki,

> I have a question about namespace migration.
> Do we completely remove climate namespace from blazar repo?
IMO, we should remain climate namespace at least one release cycle. 
Someone could have their own plugin for blazar with climate namespace. 
If it remains in next one cycle, they can convert their plugin to blazar 
namespace without a big pain.


best regards,
Masahito

On 2017/02/08 17:18, Hiroaki Kobayashi wrote:

Hi Masahito

Thank you for listing tasks for Blazar 0.2.0 release.

I have a question about namespace migration.
Do we completely remove climate namespace from blazar repo?

If so, I want to add one more task "Remove climate namespace from
blazar-nova repo" because namespace has been already migrated to blazar
but climate namespace still existed in blazar-nova repo.

Best regards,
Hiroaki

On 29/02/08 11:59, Masahito MUROI wrote:

Hello Blazar folks,

I listed all tasks needed to do by 0.2.0 release. Let's pick up bugs and
don't forget to add you as an Assignee.

https://launchpad.net/blazar/+milestone/0.2.0

best regards,
Masahito



__

OpenStack Development Mailing 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] [tricircle]schedule for Ocata release and Pike meetup/PTG

[joehuang]

Hello,team,

Thanks for your great contribution, the Ocata cycle is almost done. As what we 
discussed in weekly meeting, the schedule for Ocata release and Pike meetup/PTG 
as follows:

1.Ocata branch this Friday or early
2.  Regression test until Feb.15
3.  Ocata release Feb.16
4.  Pike meetup on Feb.17, 9:00 am~4:00 pm, G section, Huawei Industrial Base, 
Shenzhen, China for those who can't go to Atalanta.  
https://etherpad.openstack.org/p/tricircle-pike-design-topics
5. Core developer LuckyVega (Cai Zhiyuan) will be representative to attend the 
PTG at Atalanta.

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

[openstack-dev] [QA] Meeting Thursday Jan 9th at 9:00 UTC

[Ghanshyam Mann]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Jan 9th at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:


https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_February_9th_2017_.280900_UTC.29


Anyone is welcome to add an item to the agenda.

To help people figure out what time 9:00 UTC is in other timezones the next
meeting will be at:

04:00 EST

18:00 JST

18:30 ACST

11:00 CEST

04:00 CDT

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

[openstack-dev] [release][all] HELP NEEDED: test failures blocking requirements ocata branch and opening of pike

[Doug Hellmann]

The patch to update the XStatic package versions [1] is blocked by a
patch to remove nova-docker from the requirements project sync list [2],
which is in turn running into issues in the
gate-grenade-dsvm-neutron-multinode-ubuntu-xenial job [3].

We need some folks who understand these tests and the related
projects (nova, cinder, and neutron based on a cursory review of
the failed tests) to help with debugging and fixes.

Doug

[1] https://review.openstack.org/#/c/429753
[2] https://review.openstack.org/#/c/431221
[3] 
http://logs.openstack.org/21/431221/1/gate/gate-grenade-dsvm-neutron-multinode-ubuntu-xenial/67dd8a4/logs/grenade.sh.txt.gz

__
OpenStack Development Mailing 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] [Blazar] bug list before next release

[Hiroaki Kobayashi]

Hi Masahito

Thank you for listing tasks for Blazar 0.2.0 release.

I have a question about namespace migration.
Do we completely remove climate namespace from blazar repo?

If so, I want to add one more task "Remove climate namespace from
blazar-nova repo" because namespace has been already migrated to blazar
but climate namespace still existed in blazar-nova repo.

Best regards,
Hiroaki

On 29/02/08 11:59, Masahito MUROI wrote:

Hello Blazar folks,

I listed all tasks needed to do by 0.2.0 release. Let's pick up bugs and
don't forget to add you as an Assignee.

https://launchpad.net/blazar/+milestone/0.2.0

best regards,
Masahito



__
OpenStack Development Mailing 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] [nova] Next notification meeting on 02.14.

[Balazs Gibizer]

On Tue, Feb 7, 2017 at 3:56 PM, Matt Riedemann  
wrote:

On 2/7/2017 7:40 AM, Balazs Gibizer wrote:

Hi,

As we agreed last week's meeting there won't be meeting this week. 
The
next notification subteam meeting will be held on 2017.02.14 17:00 
UTC

[1] on #openstack-meeting-4.

Cheers,
gibi

[1]
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170214T17




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

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


I certainly hope you'll be passing out Valentines.


Sure. My only problem is that I don't know what the community prefers 
chocolates or flowers. :)


Cheers,
gibi




--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing 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] [tripleo] Populating Hiera data before NetworkDeployment

[Saravanan KR]

Hello,

We are facing an issue in enabling DPDK in openvswitch. Currently,
DPDK is enabled by configuring DPDK_OPTIONS at Step4 using
puppet-vswitch (vswitch::dpdk) module. This flow has limitations:
* if DPDK is used for Tenant Network, Ping Test (AllNodesValidation) will fail
* for DPDK bond, operator will NOT be able to choose the primary via
network config
* also when DPDK port is added in os-net-config without DPDK support,
openvswitch will throw errors, but a restart of openvswitch will fix
* in specific deployments, restarting openvswitch requires
network.service and neutron-openvswitch-agent services to be restarted
after a wait time

To overcome these issues, we are analyzing the option of initializing
DPDK in openvswtich before the NetworkDeployment[1] (os-net-config).
PreNetworkConfig[2] is the best place to embed this requirement.

But in order to keep the DPDK initialization as puppet manifests
(vswitch::dpdk) and invoke it from PreNetworkConfig, the hiera data
needs to be  populated (NovaComputeDeployment[3]) before the
NetworkDeployment. Of course, we can invoke the puppet class by
providing all the parameters directly, but if it is done via hiera
data, it provides flexibility to operators to override heira values
(role-specific or node-specific) and its priority. To experiment it, I
have created a review [4] with the change for moving
NovaComputeDeployment before NetworkDeployment. I have modified this
for all roles, so that all roles follow same approach in deployment.
The change in the resource dependency has been updated in the commit
message.

Please provided your feedback on this approach.

Regards,
Saravanan KR

[1] 
https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/compute-role.yaml#L364
[2] 
https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/compute-role.yaml#L348
[3] 
https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/compute-role.yaml#L440
[4] https://review.openstack.org/#/c/430215/

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

[openstack-dev] [Nova] How boot with bdm_v2={source_type=image, destination_type=local} should been used?

[Zhenyu Zheng]

Hi All,

As I was working on "Check destination_type when booting with bdm
provided": https://review.openstack.org/#/c/402372/ and addressing
reviewers comments, I find out that the current source_type=image,
destination_type=local seems unusable.

According to docs:
http://docs.openstack.org/developer/nova/block_device_mapping.html#block-device-mapping-v2,
it seems to me that "image --> local" means "boot from image", and as the
doc says, I should also provide image_ref param, but if I do so, Error
raised:

ERROR (BadRequest): Block Device Mapping is Invalid: Boot sequence for the
instance and image/block device mapping combination is not valid. (HTTP
400) (Request-ID: req-f848c6c1-0961-46c4-ac51-713fde042215)

If I just use bdm, it goes:
2017-02-08 11:04:24.929 24141 ERROR nova.compute.manager [instance:
6e44cafd-b330-4a10-8c77-eac60d58f20c] ImageNotFound: Image could not be
found.

turned out we use '' as image ID to fetch image from glance, and obviously
we cannot get it.

Detailed Log and explaination could be found in my bug report:
https://bugs.launchpad.net/nova/+bug/1662748

So, what do we expect for this API usage?

Thanks,
Kevin Zheng
__
OpenStack Development Mailing 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] How boot with bdm_v2={source_type=image, destination_type=local} should been used?

[Feodor Tersin]

HI Zhenyu


You're referring to API doc, but you're checking it with nova cli, which does 
not do exactly that what you want. In the case when you specify image and 
block-device parameters, nova cli sends image_ref and two (!) bdms. Both these 
bdms have the same boot_index and conflict with each other.


AFAIK nova cli adds the bdm for specified image_ref (not always, though).


In other words if you want to check API in this case, use pure curl instead of 
nova cli to avoid these implicit behavior. Or you may use write tests on Python 
using nova client.


From: Zhenyu Zheng 
Sent: Wednesday, February 8, 2017 12:47:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Nova] How boot with bdm_v2={source_type=image, 
destination_type=local} should been used?

Hi All,

As I was working on "Check destination_type when booting with bdm provided": 
https://review.openstack.org/#/c/402372/ and addressing reviewers comments, I 
find out that the current source_type=image, destination_type=local seems 
unusable.

According to docs: 
http://docs.openstack.org/developer/nova/block_device_mapping.html#block-device-mapping-v2,
 it seems to me that "image --> local" means "boot from image", and as the doc 
says, I should also provide image_ref param, but if I do so, Error raised:

ERROR (BadRequest): Block Device Mapping is Invalid: Boot sequence for the 
instance and image/block device mapping combination is not valid. (HTTP 400) 
(Request-ID: req-f848c6c1-0961-46c4-ac51-713fde042215)

If I just use bdm, it goes:
2017-02-08 11:04:24.929 24141 ERROR nova.compute.manager [instance: 
6e44cafd-b330-4a10-8c77-eac60d58f20c] ImageNotFound: Image could not be found.

turned out we use '' as image ID to fetch image from glance, and obviously we 
cannot get it.

Detailed Log and explaination could be found in my bug report:
https://bugs.launchpad.net/nova/+bug/1662748

So, what do we expect for this API usage?

Thanks,
Kevin Zheng
__
OpenStack Development Mailing 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] [karbor][stackalytics] Karbor Missing Commits in Stackalytics

[Yuval Brik]

Hey all,

By looking at 
http://stackalytics.com/?metric=commits=all_type=all=karbor
 I noticed that Karbor has only 195 commits in Stackalytics, while in fact, it 
has 721 commits (438 of them are not Jenkin's merges). It seems like this 
happens because of the past Smaug -> Karbor rename. The cause might be the fact 
that Stackalytics only counts diffs, and older commits are already counted for 
Smaug instead of Karbor, but I'm not sure, and have no way of verifying that.
The problem happens only in the Stackalytics commits and lines of code 
sections, and affects karbor-dashboard and python-karborclient as well. The 
reviews part in Stackalytics seem to be accurate ( 
http://stackalytics.com/?metric=marks=all_type=all=karbor
 )

Can anyone advise?

-
This email and any files transmitted and/or attachments with it are 
confidential and proprietary information of
Toga Networks Ltd., and intended solely for the use of the individual or entity 
to whom they are addressed.
If you have received this email in error please notify the system manager. This 
message contains confidential
information of Toga Networks Ltd., and is intended only for the individual 
named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail. Please 
notify the sender immediately
by e-mail if you have received this e-mail by mistake and delete this e-mail 
from your system. If you are not
the intended recipient you are notified that disclosing, copying, distributing 
or taking any action in reliance on
the contents of this information is strictly prohibited.


__
OpenStack Development Mailing 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] How boot with bdm_v2={source_type=image, destination_type=local} should been used?

[Feodor Tersin]

Zhenyu,


btw iianm if you specify image only (w/o bdm) in the command line, nova cli 
sends exactly that combination which you're interesting for: image_ref and 
bdmv2.


From: Feodor Tersin 
Sent: Wednesday, February 8, 2017 2:11:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] How boot with bdm_v2={source_type=image, 
destination_type=local} should been used?


HI Zhenyu


You're referring to API doc, but you're checking it with nova cli, which does 
not do exactly that what you want. In the case when you specify image and 
block-device parameters, nova cli sends image_ref and two (!) bdms. Both these 
bdms have the same boot_index and conflict with each other.


AFAIK nova cli adds the bdm for specified image_ref (not always, though).


In other words if you want to check API in this case, use pure curl instead of 
nova cli to avoid these implicit behavior. Or you may use write tests on Python 
using nova client.


From: Zhenyu Zheng 
Sent: Wednesday, February 8, 2017 12:47:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Nova] How boot with bdm_v2={source_type=image, 
destination_type=local} should been used?

Hi All,

As I was working on "Check destination_type when booting with bdm provided": 
https://review.openstack.org/#/c/402372/ and addressing reviewers comments, I 
find out that the current source_type=image, destination_type=local seems 
unusable.

According to docs: 
http://docs.openstack.org/developer/nova/block_device_mapping.html#block-device-mapping-v2,
 it seems to me that "image --> local" means "boot from image", and as the doc 
says, I should also provide image_ref param, but if I do so, Error raised:

ERROR (BadRequest): Block Device Mapping is Invalid: Boot sequence for the 
instance and image/block device mapping combination is not valid. (HTTP 400) 
(Request-ID: req-f848c6c1-0961-46c4-ac51-713fde042215)

If I just use bdm, it goes:
2017-02-08 11:04:24.929 24141 ERROR nova.compute.manager [instance: 
6e44cafd-b330-4a10-8c77-eac60d58f20c] ImageNotFound: Image could not be found.

turned out we use '' as image ID to fetch image from glance, and obviously we 
cannot get it.

Detailed Log and explaination could be found in my bug report:
https://bugs.launchpad.net/nova/+bug/1662748

So, what do we expect for this API usage?

Thanks,
Kevin Zheng
__
OpenStack Development Mailing 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] [karbor] Karbor Mascot draft

[Yuval Brik]

Hey,

Please send your vote for Karbor's mascot in mailing list or in Karbor's IRC 
channel (just type 'mascot option 1' or 'mascot option 2') until Thursday 
February 9th 08:00 UTC ( https://time.is/compare/0800_9_Feb_2017_in_UTC ).

--Yuval


From: Yuval Brik 
Sent: Monday, February 6, 2017 11:27
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [karbor] Karbor Mascot draft

Hello everybody,

We received the following draft for our Karbor mascot (which is a beaver, as 
you all surely recall).
Option 1:
[cid:1c17dc92-cacb-4723-8bec-cfe9b3e24b1c]

Option 2:
[cid:05b3a652-3127-478d-bc0d-43129125888f]

Please send your thoughts here, or on IRC the meeting tomorrow.

--Yuval

-
This email and any files transmitted and/or attachments with it are 
confidential and proprietary information of
Toga Networks Ltd., and intended solely for the use of the individual or entity 
to whom they are addressed.
If you have received this email in error please notify the system manager. This 
message contains confidential
information of Toga Networks Ltd., and is intended only for the individual 
named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail. Please 
notify the sender immediately
by e-mail if you have received this e-mail by mistake and delete this e-mail 
from your system. If you are not
the intended recipient you are notified that disclosing, copying, distributing 
or taking any action in reliance on
the contents of this information is strictly prohibited.


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

[openstack-dev] [openstack-docs] Bug smash

[Alexandra Settle]

Hey everyone,

We have 2 weeks until the Ocata release. Hooray! We have fixed 251 so far! But, 
we have some more work to do… 

I know everyone is busy with their respective guides and testing, but we have 
24 bugs (half are wishlist!) that were assigned for Newton and Ocata that we 
have not fixed.

It would be great if people could take the time over the next 2 weeks to assign 
themselves a bug: https://goo.gl/DnZU0q (this is a Launchpad link, just wanted 
to save you all from the 40 lines)

If you have any questions, please reach out ☺ 

Cheers,

Alex




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

Re: [openstack-dev] [OpenStack-docs] [openstack-docs] Bug smash

[Alexandra Settle]

Correction!

251 bugs* - good to see I can type an email without errors. 

On 2/8/17, 11:25 AM, "Alexandra Settle"  wrote:

Hey everyone,

We have 2 weeks until the Ocata release. Hooray! We have fixed 251 so far! 
But, we have some more work to do… 

I know everyone is busy with their respective guides and testing, but we 
have 24 bugs (half are wishlist!) that were assigned for Newton and Ocata that 
we have not fixed.

It would be great if people could take the time over the next 2 weeks to 
assign themselves a bug: https://goo.gl/DnZU0q (this is a Launchpad link, just 
wanted to save you all from the 40 lines)

If you have any questions, please reach out ☺ 

Cheers,

Alex




___
OpenStack-docs mailing list
openstack-d...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs


__
OpenStack Development Mailing 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] Moving mirror server images to tarballs.o.o (Was: [rdo-list] RDO-CI Scrum Weekly Scrum Recap)

[John Trowbridge]

Moving this thread from rdo-list, but leaving in copy as it is relevant
there too. However it is more of a TripleO topic.

On 02/07/2017 03:56 PM, Paul Belanger wrote:
> On Tue, Feb 07, 2017 at 03:34:09PM -0500, Ronelle Landy wrote:
>> Greetings All,
>>
>> Links to the RDO-CI team scrum[1] and recording[2] from this week's
>> meeting are below.
>>
>> Highlights:
>>
>>  - TripleO CI images outage 
>>   [3] details the images missing from the mirror, causing CI failures
>>   We need a less 'reactive' approach to checking that the gates are working
>>   Action Items:
>> Attila added [4] to run check jobs and measure passing
>> IRC Bot needed to ping #oooq with failures
> It would be great if we can finally replace this private infrastructure in
> tripleo-ci with our community openstack-infra servers. This avoids the need 
> for
> tripleo-ci project to maintain servers.  Also, we likely have more HDD space
> available.
> 
> I recently helped kolla move there images to tarballs.o.o, we can do the same
> for tripleo-ci.
> 

That would be awesome. We want to cover stable release images as well,
and the current tripleo-ci mirror server seems inadequate for that. Are
there any docs on how to publish to tarballs.o.o? Right now, the image
upload happens in two stages. First, all periodic jobs of a particular
type (HA I think?) upload the images they built to the mirror server.
Second, when all periodic jobs pass on a particular dlrn hash the
symlink for the "known good" image is updated.

It seems like to start we could maybe update this symlink swapping logic
to instead publish the image on tarballs.o.o, and use that location as
the known good. That would still result in using the current mirror
server as a store of images under test, but it would give the gates
which consume the known good images (and users/devs who do that) much
more stability.

Maybe it would be possible to use tarballs.o.o for the testing images as
well, but then we would need some sort of cleanup and some way to mark
which images there are actually good (which seems a bit more complicated).

>>  -  Upgrade CI status
>>   There is a periodic job running on internal jenkins [5] testing upgrades
>>   [6] adds the sanity checks so that upgrade jobs will be able to check 
>> services without a full overcloud deployment
>>  - Ocata Pipeline status
>>   Phase 1 passed on Friday - but still some reviews outstanding (image 
>> build, release configs)
>>   Phase 2 - jobs have been set up internally
>> All baremetal jobs are failing due to JJB mismatches (master vs 
>> rdo_trunk for ocata)
>>  - DCI team is interested in using quickstart-extras
>>   RDO-CI team to support this usage 
>>   
>>
>> [1] - https://review.rdoproject.org/etherpad/p/rdo-infra-scrum
>> [2] - https://bluejeans.com/s/ugrW6/
>> [3] - https://bugs.launchpad.net/tripleo/+bug/1661656
>> [4] - https://review.openstack.org/430277
>> [5] - > jenkins>/RDO/view/openstack_virtual_baremetal/job/tripleo-quickstart-newton-to-master-upgrade-ovb-qeos7-rhos-dev-ci-multi-nic/
>> [6] - https://review.openstack.org/#/c/429716/
>>
>> /R
>>
>> Ronelle Landy
>>
>> ___
>> rdo-list mailing list
>> rdo-l...@redhat.com
>> https://www.redhat.com/mailman/listinfo/rdo-list
>>
>> To unsubscribe: rdo-list-unsubscr...@redhat.com
> 
> ___
> rdo-list mailing list
> rdo-l...@redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 
> To unsubscribe: rdo-list-unsubscr...@redhat.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] [all][tc][swift][designate] New language addition process has been approved

[Flavio Percoco]

On 19/01/17 11:59 +0100, Flavio Percoco wrote:

Greetings,

The Technical Committe recently approved a new reference document which
describes how new programming languages can be proposed for inclusion as
supported languages by OpenStack. The new reference document can be found
here[0].

I'd like to take this chance not only to share this new process - which in my
opinion is a good step forward for the entire community - but to invite other
teams to take a stab at it and move forward the inclusion of Go, which is the
last language that was discussed for inclusion in the community.

I hope folks will find this process useful and that it'll help innovating
OpenStack. I'm sure the process is not perfect and that we'll have to refine it
as we go so, let's get going.

Thanks everyone,
Flavio

[0] https://governance.openstack.org/tc/reference/new-language-requirements.html



Hey folks,

Sorry for pressing so much on this but, would it be safe to assume that no one
from the swift and/or designate team are intereted in proposing golang through
this process?

That's what I'm assuming at least given the silence on this thread.

Thanks,
Flavio


--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [all][tc][swift][designate] New language addition process has been approved

[Hayes, Graham]

On 08/02/2017 14:56, Flavio Percoco wrote:
> On 19/01/17 11:59 +0100, Flavio Percoco wrote:
>> Greetings,
>>
>> The Technical Committe recently approved a new reference document which
>> describes how new programming languages can be proposed for inclusion as
>> supported languages by OpenStack. The new reference document can be found
>> here[0].
>>
>> I'd like to take this chance not only to share this new process - which in my
>> opinion is a good step forward for the entire community - but to invite other
>> teams to take a stab at it and move forward the inclusion of Go, which is the
>> last language that was discussed for inclusion in the community.
>>
>> I hope folks will find this process useful and that it'll help innovating
>> OpenStack. I'm sure the process is not perfect and that we'll have to refine 
>> it
>> as we go so, let's get going.
>>
>> Thanks everyone,
>> Flavio
>>
>> [0] 
>> https://governance.openstack.org/tc/reference/new-language-requirements.html
>
>
> Hey folks,
>
> Sorry for pressing so much on this but, would it be safe to assume that no one
> from the swift and/or designate team are intereted in proposing golang through
> this process?
>
> That's what I'm assuming at least given the silence on this thread.
>
> Thanks,
> Flavio
>
>

Well, from the designate side, most of the TC was pretty clear
about thinking we did not have a technical reason to use golang.

As I said throughout the drafting of the regulation, it is a lot of
work required up front, and combined with the recent shift of (read
'lack of' ) resources assigned to Designate, we do not have enough
people to cut through the red tape.

I personally still think it is the right direction for us, but it will
not be an ongoing priority for me to get implemented - I will leave the
project priority to the new PTL, but I suspect Tim will be of the same
opinion.

- Graham

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

[openstack-dev] [release][all] started branching tools and requirements

[Doug Hellmann]

We have started the process of branching devstack, grenade, and the
requirements repo. This may introduce some instability into the gate
until we are finished. Please join #openstack-release if you would like
to follow along.

Doug

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

Re: [openstack-dev] [release][oslo] recreating the stable/ocata branch for mox3

[Doug Hellmann]

Excerpts from ChangBo Guo's message of 2017-02-08 10:41:04 +0800:
> Thanks Doug and amoralej,  we should avoid this :(．
> 
> One more thought about mox3: Is it used outside of OpenStack? If yes,
> Maybe we can retire mox3 if all projects move mox to mock.

I thought our policy was that mox3 was already deprecated and all new
tests should use mock instead. Converting the existing tests can be
non-trivial because of the differences in how the two libraries work,
but it would help us move off of mox3.

Doug

> 
> 2017-02-07 23:00 GMT+08:00 Doug Hellmann :
> 
> > The stable/ocata branch for mox3 was created from 0.19.0 and then 0.20.0
> > was released from master. Because that repository sees a very low rate
> > of changes, and because the current stable/ocata branch only contained
> > the patch to update the .gitreview file, we decided to recreate the
> > branch to accurately reflect the intent of having 0.20.0 be part of the
> > ocata series of releases.
> >
> > https://review.openstack.org/430283
> >
> > Thanks go to amoralej for pointing out the issue today.
> >
> > Doug
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 

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

[openstack-dev] [dib] diskimage-builder v2 RC1 release; request for test

[Ian Wienand]

Hi

diskimage-builder has been working on a feature/v2 branch
incorporating some largely internal changes to the way it finds and
calls elements, enhancements to partitioning and removal of some
long-deprecated elements.  We have just tagged 2.0.0rc1 and are
requesting testing by interested parties.

You can view the branch at

 https://git.openstack.org/cgit/openstack/diskimage-builder/log/?h=feature/v2

For any issues it is probably best to file a bug.  Developers are
standing by in #openstack-dib.

=== User facing changes

If you use dib exclusively via the command-line disk-image-create
installed from a package or via pypi you are unlikely to notice any
difference (if you run it directly from a git-tree checkout, you're in
development territory so read on).

v2 includes a new framework for partitioning contributed by Andreas
Florath.  This should allow for creating multiple partitions, images
with encryption, LVM support and flexibility for multiple-devices, all
of which are currently not supported.  Please check the v2
documentation, specs and reach out if these features interest you
(some parts still in review).

Element override is now supported.  If you have an element of the same
name earlier in the ELEMENTS_PATH, it will override later instances
(previously, the behaviour was undefined).

A number of long-deprecated elements have been removed in v2, which
are to the best of our knowledge unused.

 - partitioning-sfdisk
 - deploy-ironic-element
 - ironc-discovered-ramdisk
 - serial-console-element
 - map-services

=== Developer changes

Developers, or those that are doing more "interesting" things in
deployment or CI, might like to read below to follow the history of
the branch and hopefully do some testing with the feature/v2 branch
ASAP so we can address any concerns.

dib started out mostly as a shell script collection that used setup.py
to install itself.  Over time it has made more and more use of Python.
The current instructions say to checkout the source tree and run
"./bin/disk-image-create"; this causes a number of issues for the
internal Python components.  We carry hacks to try and figure out of
we're being called uninstalled from a source tree, or installed in pip
develop mode, or installed on the system.

For purposes of both users and development we want dib to be as
"pythonic" as possible and behave like all other projects.  Two major
visible changes are:

 - command-line scripts are entry points (i.e. need to be installed)
 - elements have moved under diskimage_create module

The result of the first is that "./bin/disk-image-create" from the
source tree is no longer there.  Like all other projects, you should
install dib into a virtualenv (if you're developing, use pip -e) and
"disk-image-create" will "just work".  FYI, on the back-end, this
entry-point essentially exec()s the old shell-script driver; but we
reserve the right to move more of the logic into python over time.
Also, instead of having to os.system(/path/disk-image-create), we can
allow direct calls like a real library.

A side-effect of this is that we have removed and deprecated the
dib-utils package.  This was intended to be a more generic repository
of tools that might be useful outside dib, but that did not eventuate
and it has been folded back into dib for simplicity.

The second change, moving the inbuilt elements under the
diskimage_create module, is a simplification so we always have a
canonical path to our elements.  Currently the elements are installed
via "data_files" in setup.cfg, which means setup.py puts the elements
in /usr/share... when installing, or leaves them in the tree when
installed via pip -e.  Again we have path guessing hacks trying to
guess what situation we're in.  Elements have moved from elements/ to
diskimage_builder/elements in the source tree (we did try to minimise
this with symlinks, but setuptools doesn't like it, it complicates
things when git merging across the branches and is legacy cruft to go
wrong in the future.  It was better to make a clean break).

Since we always know where elements are relative to the imported
diskimage_builder module we can drop all the path guessing complexity.
This has other good flow-on effects such as testr being able to find
unit-tests for elements in the normal fashion and having imports work
as usual.

We are aware there are a number of tools that like to take dib
elements and do things with them.  This is fine, I guess, although of
course if we don't know about how you use elements we're liable to
break them.  Thus your use may be confused that the elements have
moved.

Reading some of the dib source you may find there is a canonical way
to find out the included dib elements path -- ask dib itself,
something like:

 DIB_ELEMENTS=$(python -c '
 import diskimage_builder.paths;
 diskimage_builder.paths.show_path("elements")')

Note you probably do not want this.  As mentioned, another feature of
v2 is override elements -- an element that appears 

[openstack-dev] [monasca] Monasca Ocata midcycle

[Hochmuth, Roland M]

Hi Everyone, We will be holding a Monasca Midcycle on Wednesday February 22nd, 
and Thursday February 23rd, 2017, via Lync/Skype video conferencing. The 
etherpad for the midcycle is located at, 
https://etherpad.openstack.org/p/monasca_ocata_midcycle. The etherpad has the 
Lync/Skype connection details and time.

There is also a tentative agenda that is posted in the etherpad, but the 
details need to be organized further. There are a large number of topics 
already, but please feel free to add more to the agenda.

Sorry that we didn't have enough members from the Monasca team that were able 
to attend the PTG. However, if there are others that are attending the PTG 
would like to connect with the Monasca Team, this would be a good time to do 
that, as we will all be available online. Please let us know if you are 
interested in a discussion. And if the PTG isn't a good time either, then we 
can schedule a discussion for another time.

Regards --Roland
__
OpenStack Development Mailing 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] [kuryr] Resource management videoconf meeting

[Antoni Segura Puimedon]

On Tue, Feb 7, 2017 at 5:30 PM, Antoni Segura Puimedon 
wrote:

> Hi all,
>
> In the last weekly IRC meeting it was agreed to hold a videoconf meeting
> about resource management. For those unaware, the topic revolves around the
> reutilization of Neutron resources like ports and subports as well and
> virtual devices like veths. This allows for things like batching neutron
> calls and achieveng much shorter times when creating pods.
>
> The meeting time will be 13:30UTC Thurdsay February 9th on bluejeans:
>

The meeting has been moved to 12 UTC

>
> In order to join by phone:
>
> You can find a local number to call at:
>
> https://www.intercallonline.com/listNumbersByCode.action?
> confCode=5508709975
>
> Meeting id: 844311720
>
> In order to join with the computer:
>
> https://bluejeans.com/844311720
>
> The meeting recording link will be made available.
>
> Regards,
>
> Toni
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][oslo] recreating the stable/ocata branch for mox3

[ChangBo Guo]

I just added it in https://etherpad.openstack.org/p/community-goals
yesterday. submit a community goal for this ?

2017-02-09 3:20 GMT+08:00 Doug Hellmann :

> Excerpts from Joshua Harlow's message of 2017-02-08 10:01:27 -0800:
> > Doug Hellmann wrote:
> > > Excerpts from ChangBo Guo's message of 2017-02-08 10:41:04 +0800:
> > >> Thanks Doug and amoralej,  we should avoid this :(．
> > >>
> > >> One more thought about mox3: Is it used outside of OpenStack? If yes,
> > >> Maybe we can retire mox3 if all projects move mox to mock.
> > >
> > > I thought our policy was that mox3 was already deprecated and all new
> > > tests should use mock instead. Converting the existing tests can be
> > > non-trivial because of the differences in how the two libraries work,
> > > but it would help us move off of mox3.
> >
> > Sounds like one of those community goals (like move off oslo-incubator)
> > to me :)
>
> It could be, sure. We need a volunteer to organize it.
>
> Doug
>
> >
> > >
> > > Doug
> > >
> > >> 2017-02-07 23:00 GMT+08:00 Doug Hellmann:
> > >>
> > >>> The stable/ocata branch for mox3 was created from 0.19.0 and then
> 0.20.0
> > >>> was released from master. Because that repository sees a very low
> rate
> > >>> of changes, and because the current stable/ocata branch only
> contained
> > >>> the patch to update the .gitreview file, we decided to recreate the
> > >>> branch to accurately reflect the intent of having 0.20.0 be part of
> the
> > >>> ocata series of releases.
> > >>>
> > >>> https://review.openstack.org/430283
> > >>>
> > >>> Thanks go to amoralej for pointing out the issue today.
> > >>>
> > >>> Doug
> > >>>
> > >>> 
> __
> > >>> OpenStack Development Mailing List (not for usage questions)
> > >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >>>
> > >
> > > 
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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