Re: [openstack-dev] [release][mistral] mistral Newton RC1 available

[Renat Akhmerov]

Yes, we came up with a solution for this issue. Should be solved shortly.

Renat Akhmerov
@Nokia

> On 20 Sep 2016, at 00:28, Lingxian Kong  wrote:
> 
> Thanks Dougal for reporting that, we are working on the issue.
> 
> Cheers,
> Lingxian Kong (Larry)
> 
> 
> On Fri, Sep 16, 2016 at 11:27 PM, Dougal Matthews  wrote:
>> 
>> 
>> On 16 September 2016 at 00:06, Doug Hellmann  wrote:
>>> 
>>> Hello everyone,
>>> 
>>> The release candidate for mistral for the end of the Newton cycle
>>> is available!  You can find the RC1 source code tarballs at:
>>> 
>>> https://tarballs.openstack.org/mistral/mistral-3.0.0.0rc1.tar.gz
>>> 
>>> https://tarballs.openstack.org/mistral-dashboard/mistral-dashboard-3.0.0.0rc1.tar.gz
>>> 
>>> Unless release-critical issues are found that warrant a release
>>> candidate respin, this RC1 will be formally released as the final
>>> Newton release on 6 October. You are therefore strongly
>>> encouraged to test and validate this tarball!
>> 
>> 
>> I believe we (TripleO) are hitting a release critical issue here:
>> https://bugs.launchpad.net/mistral/+bug/1624284
>> 
>> I have tagged the issue.
>> 
>> 
>>> Alternatively, you can directly test the stable/newton release
>>> branch at:
>>> 
>>> http://git.openstack.org/cgit/openstack/mistral/log/?h=stable/newton
>>> 
>>> If you find an issue that could be considered release-critical,
>>> please file it at:
>>> 
>>> https://bugs.launchpad.net/mistral/+filebug
>>> 
>>> and tag it *newton-rc-potential* to bring it to the mistral release
>>> crew's attention.
>>> 
>>> Note that the "master" branch of mistral is now open for Ocata
>>> development, and feature freeze restrictions no longer apply there!
>>> 
>>> Thanks,
>>> 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 Development Mailing 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] [vote][kolla] deprecation for fedora distro support

[Steven Dake (stdake)]

Fwiw Swapnil, I think having a solid fedora implementation would be fantastic 
to help manage the transition to centos8 whenever that happens.  At this point 
nobody has stepped up to do the work.  We can always revisit any policy or vote 
in the future if the environment changes (i.e. you are freed up to work on 
making fedora work well).  However, no majority has been reached yet, so its 
premature to call this vote closed.

Regards
-steve


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

Date: Monday, September 19, 2016 at 10:57 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [vote][kolla] deprecation for fedora distro support


On Sep 19, 2016 11:11 PM, "Jeffrey Zhang" 
mailto:zhang.lei@gmail.com>> wrote:
>
> Kolla core reviewer team,
>
> Kolla supports multiple Linux distros now, including
>
> * Ubuntu
> * CentOS
> * RHEL
> * Fedora
> * Debian
> * OracleLinux
>
> But only Ubuntu, CentOS, and OracleLinux are widely used and we have
> robust gate to ensure the quality.
>
> For fedora, Kolla hasn't any test for it and nobody reports any bug
> about it( i.e. nobody use fedora as base distro image). We (kolla
> team) also do not have enough resources to support so many Linux
> distros. I prefer to deprecate fedora support now.  This is talked in
> past but inconclusive[0].
>
> Please vote:
>
> 1. Kolla needs support fedora( if so, we need some guys to set up the
> gate and fix all the issues ASAP in O cycle)
> 2. Kolla should deprecate fedora support
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-June/098526.html
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Unless we have specific objections apart from issues in #1, I wish to work on 
Fedora support in kolla and request to revisit the depreciation vote post 
ocata-2 milestone.

Best Regards,
Swapnil (coolsvap)
__
OpenStack Development Mailing 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] [tricircle]freeze date and tricircle splitting

[Vega Cai]

Since the patches for layer 3 networking automation has been merged, I
think we'd better include the patches for resource cleaning in the tagged
branch. Here is the list:

Floating ip deletion: https://review.openstack.org/354604
Subnet cleaning: https://review.openstack.org/355847
Router cleaning: https://review.openstack.org/360848

Shinobu Kinjo 于2016年9月20日周二 下午12:04写道：

> This announcement should have been first to avoid any unnecessary work -;
>
> On Tue, Sep 20, 2016 at 12:51 PM, joehuang  wrote:
> > Hello, as the Trio2o repository has been established, it's time for us to
> > discuss the freeze date and tagging(newton branch) for the last release
> of
> > Tricircle with gateway function.
> >
> > The freeze date is the gate for patches to be merged before
> tagging(newton
> > branch). If a patch can't finish review process before the freeze date,
> and
> > not able to be merged in Tricircle, then it's suggested to be handled
> like
> > this:
> >
> > 1. If it's networking automation related patch, continue the review
> process
> > in Tricircle after tagging(newton branch), will be merged in Tricircle
> trunk
> > in the future .
> >
> > 2. If it's gateway related patch, abandon the patch, re-submit the patch
> in
> > Trio2o.
> >
> > 3. If it's patch about pod management, for it's common feature, so
> continue
> > the review process in tricircle  after tagging(newton branch) , and
> submit a
> > new patch for this feature in Trio2o separately.
> >
> > Exception request after freeze date, before tagging(newton branch): If
> there
> > is some patch must be merged before the tagging(newton branch), then
> need to
> > send the exception request in the mail-list for the patch, and approved
> by
> > PTL.
> >
> > That means we need to define a deadline for patches to be merged in
> > Tricircle before tagging(newton branch), and define the scope of patches
> > wish to be merged in Trcircle before splitting.
> >
> > Your thoughts, proposal for the freeze date and patches to be merged?
> >
> > (As the old thread containing both Trio2o and Tricircle in the subject,
> not
> > good to follow, so a new thread is started)
> >
> > Best Regards
> > Chaoyi Huang (joehuang)
> >
> > 
> > From: joehuang
> > Sent: 18 September 2016 16:34
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: RE: [openstack-dev] [tricircle][trio2o] trio2o git repo ready
> and
> > tricircle splitting
> >
> > Thank you for your comment, Zhiyuan.
> >
> > For pod management, because these two projects need to run
> independently, I
> > think submit patches separately as needed may be a better choice.
> >
> > Best Regards
> > Chaoyi Huang(joehuang)
> > 
> > From: Vega Cai [luckyveg...@gmail.com]
> > Sent: 18 September 2016 16:27
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [tricircle][trio2o] trio2o git repo ready
> and
> > tricircle splitting
> >
> > +1 for the proposal. What about the codes for Pod operation? It seems
> that
> > both Tricircle and Trio2o need these codes. We submit patches to these
> two
> > projects separately?
> >
> > Zhiyuan
> >
> > joehuang 于2016年9月18日周日 下午4:17写道：
> >>
> >> hello, team,
> >>
> >> Trio2o git repository is ready now: https://github.com/openstack/trio2o
> >>
> >> The repository inherited all files and commit messages from Tricircle.
> >>
> >> It's now the time start to do the tricircle splitting: a blue print is
> >> registere for Tricircle cleaning:
> >>
> https://blueprints.launchpad.net/tricircle/+spec/make-tricircle-dedicated-for-networking-automation-across-neutron.There
> >> are lots of documentation work to do. Please review these doc in the BP,
> >> thanks.
> >>
> >> There are some proposal for patches during the splitting:
> >>
> >> 1. For patch which is already in review status, let's review it in
> >> Tricircle (no matter it's for Trio2o or Tricircle), after it's get
> merged,
> >> then port it to Trio2o. After all patches get merged, let's have a last
> tag
> >> for Tricircle to cover both gateway and networking automation function.
> Then
> >> the cleaning will be done in Tricircle to make Tricircle as a project
> for
> >> networking automation only
> >> 2. For new patch which is only applicable to Trio2o, I propose that we
> >> submit such patches in Trio2o only, no need to submit in Tricircle.
> >>
> >> Would like to know your thoughts on the splitting.
> >>
> >> 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 Development Mailing Li

[openstack-dev] [nova][bugs] Nova Bugs Team Meeting this Tuesday at 1800 UTC

[Augustina Ragwitz]

The next Nova Bugs Team meeting will be Tuesday, September 20 at 1800
UTC in #openstack-meeting-4

http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160920T18

Feel free to add to the meeting agenda: 
https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam

-- 
Augustina Ragwitz
Señora Software Engineer
---
Ask me about contributing to OpenStack Nova!
https://wiki.openstack.org/wiki/Nova/Mentoring
---
email: aragwitz+n...@pobox.com
irc: auggy

__
OpenStack Development Mailing 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] [vote][kolla] deprecation for fedora distro support

[Swapnil Kulkarni]

On Sep 19, 2016 11:11 PM, "Jeffrey Zhang"  wrote:
>
> Kolla core reviewer team,
>
> Kolla supports multiple Linux distros now, including
>
> * Ubuntu
> * CentOS
> * RHEL
> * Fedora
> * Debian
> * OracleLinux
>
> But only Ubuntu, CentOS, and OracleLinux are widely used and we have
> robust gate to ensure the quality.
>
> For fedora, Kolla hasn't any test for it and nobody reports any bug
> about it( i.e. nobody use fedora as base distro image). We (kolla
> team) also do not have enough resources to support so many Linux
> distros. I prefer to deprecate fedora support now.  This is talked in
> past but inconclusive[0].
>
> Please vote:
>
> 1. Kolla needs support fedora( if so, we need some guys to set up the
> gate and fix all the issues ASAP in O cycle)
> 2. Kolla should deprecate fedora support
>
> [0]
http://lists.openstack.org/pipermail/openstack-dev/2016-June/098526.html
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Unless we have specific objections apart from issues in #1, I wish to work
on Fedora support in kolla and request to revisit the depreciation vote
post ocata-2 milestone.

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

Re: [openstack-dev] [cinder] moving driver to open source

[Alon Marx]

Thank you ALL for clearing up this issue. 

To sum up the discussion (not going into too many details):
>From legal stand point, if one uses python libraries they should be part 
of the community or confirming with the relevant licenses (
http://governance.openstack.org/reference/licensing.html). If one is not 
using python libraries (e.g. rest, command line, etc.) the non-python 
executable is considered legitimate wherever it is running.
>From deployment stand point the desire is to have any piece of code that 
is required on an openstack installation would be easily downloadable.
 
We understand the requirements now and are working on a plan taking both 
considerations into account. 

Thanks,
Alon



__
OpenStack Development Mailing 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] [vote][kolla] deprecation for fedora distro support

[Eduardo Gonzalez]

+1 to option 2.

Regards

On Mon, Sep 19, 2016, 10:34 PM Vikram Hosakote (vhosakot) <
vhosa...@cisco.com> wrote:

> I vote for option 2.
>
> Regards,
> Vikram Hosakote
> IRC:  vhosakot
>
> From: Ryan Hallisey 
>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Monday, September 19, 2016 at 2:58 PM
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [vote][kolla] deprecation for fedora distro
> support
>
> option 2
>
> Thanks
> -Ryan
>
> - Original Message -
> From: "Mauricio Lima" 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Sent: Monday, September 19, 2016 2:21:51 PM
> Subject: Re: [openstack-dev] [vote][kolla] deprecation for fedora distro
> support
>
> Option 2
>
> 2016-09-19 14:56 GMT-03:00 Christian Berendt <
> bere...@betacloud-solutions.de > :
>
>
> Thanks for moving this forward.
>
> On 19 Sep 2016, at 19:40, Jeffrey Zhang < zhang.lei@gmail.com >
> wrote:
> 1. Kolla needs support fedora( if so, we need some guys to set up the
> gate and fix all the issues ASAP in O cycle)
> 2. Kolla should deprecate fedora support
>
>
> +1 on option 2.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][sahara] LVM vs BDD drivers performance tests results

[John Griffith]

On Mon, Sep 19, 2016 at 2:54 PM, Duncan Thomas 
wrote:

> I think there's some mileage in some further work on adding local LVM,
> since things like striping/mirroring for performace can be done. We can
> prototype it and get the numbers before even thinking about merging though
> - as additions to an already fully featured driver. these seem more
> worthwhile a way forward than limping on with the bdd driver.
>
​I think that's a different discussion, a good one, but a different one.
I'd also like to point out that there's been a mirroring option in the
existing LVM driver for years (Vish added it a long time ago) but there
have been very few people that have showed any interest in it.

Again, rather than change the entire architecture of things, I'd rather see
us do some things around multi-pathing and exploitation of the mirroring
that we already have.  IMHO we either flush out and refine the
features/options we have or start removing them; but I hate to continue
piling little corner case configs into the mix that aren't tested and
typically don't implement the entire API.

​


>
> Moving to change our default target to LIO seems worthwhile - I'd suggest
> being cautious with deprecation rather than aggressive though - aiming to
> change the default in 'O' then planning the rest based on how that goes.
>
> On 19 September 2016 at 21:54, John Griffith 
> wrote:
>
>>
>>
>> On Mon, Sep 19, 2016 at 12:01 PM, Ivan Kolodyazhny 
>> wrote:
>>
>>> + [sahara] because they are primary consumer of the BDD.
>>>
>>> John,
>>> Thanks for the answer. My comments are inline.
>>>
>>> Regards,
>>> Ivan Kolodyazhny,
>>> http://blog.e0ne.info/
>>>
>>> On Mon, Sep 19, 2016 at 4:41 PM, John Griffith >> > wrote:
>>>


 On Mon, Sep 19, 2016 at 4:43 AM, Ivan Kolodyazhny 
 wrote:

> Hi team,
>
> We did some performance tests [1] for LVM and BDD drivers. All tests
> were executed on real hardware with OpenStack Mitaka release.
> Unfortunately, we didn't have enough time to execute all tests and compare
> results. We used Sahara/Hadoop cluster with TestDFSIO and others
> tests.
>
> All tests were executed on the same hardware and OpenStack release.
> Only difference were in cinder.conf to enable needed backend and/or target
> driver.
>
> Tests were executed on following configurations:
>
>- LVM +TGT target
>- LVM+LocalTarget: PoC based on [2] spec
>- LVM+LIO
>- Block Device Driver.
>
>
> Feel free to ask question if any about our testing infrastructure,
> environment, etc.
>
>
> [1] https://docs.google.com/spreadsheets/d/1qS_ClylqdbtbrVSvwbbD
> pdWNf2lZPR_ndtW6n54GJX0/edit?usp=sharing
> [2] https://review.openstack.org/#/c/247880/
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.op
> enstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ​Thanks Ivan, so I'd like to propose we (the Cinder team) discuss a
 few things (again):

 1. Deprecate the BDD driver
  Based on the data here LVM+LIO the delta in performance ​(with the
 exception of the Terravalidate run against 3TB) doesn't seem significant
 enough to warrant maintaining an additional driver that has only a subset
 of features implemented.  It would be good to understand why that
 particular test has such a significant peformance gap.

>>> What about Local Target? Does it make sense to implement it instead BDD?
>>>
>> ​Maybe I'm missing something, what would the advantage be?  LVM+LIO and
>> LVM+LOCAL-TARGET seem pretty close.  In the interest of simplicity and
>> maintenance just thinking maybe it would be worth considering just using
>> LVM+LIO across the board.
>> ​
>>
>>
>>>
 2. Consider getting buy off to move the default implementation to use
 the LIO driver and consider deprecating the TGT driver

>>> +1. Let's bring this topic for the next weekly meeting.
>>>
>>>
>>>

 I realize this probably isn't a sufficient enough data set to make
 those two decisions but I think it's at least enough to have a more
 informed discussion this time.

 Thanks,
 John​


 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.op
 enstack.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...@l

Re: [openstack-dev] [tricircle]freeze date and tricircle splitting

[Shinobu Kinjo]

This announcement should have been first to avoid any unnecessary work -;

On Tue, Sep 20, 2016 at 12:51 PM, joehuang  wrote:
> Hello, as the Trio2o repository has been established, it's time for us to
> discuss the freeze date and tagging(newton branch) for the last release of
> Tricircle with gateway function.
>
> The freeze date is the gate for patches to be merged before tagging(newton
> branch). If a patch can't finish review process before the freeze date, and
> not able to be merged in Tricircle, then it's suggested to be handled like
> this:
>
> 1. If it's networking automation related patch, continue the review process
> in Tricircle after tagging(newton branch), will be merged in Tricircle trunk
> in the future .
>
> 2. If it's gateway related patch, abandon the patch, re-submit the patch in
> Trio2o.
>
> 3. If it's patch about pod management, for it's common feature, so continue
> the review process in tricircle  after tagging(newton branch) , and submit a
> new patch for this feature in Trio2o separately.
>
> Exception request after freeze date, before tagging(newton branch): If there
> is some patch must be merged before the tagging(newton branch), then need to
> send the exception request in the mail-list for the patch, and approved by
> PTL.
>
> That means we need to define a deadline for patches to be merged in
> Tricircle before tagging(newton branch), and define the scope of patches
> wish to be merged in Trcircle before splitting.
>
> Your thoughts, proposal for the freeze date and patches to be merged?
>
> (As the old thread containing both Trio2o and Tricircle in the subject, not
> good to follow, so a new thread is started)
>
> Best Regards
> Chaoyi Huang (joehuang)
>
> 
> From: joehuang
> Sent: 18 September 2016 16:34
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: RE: [openstack-dev] [tricircle][trio2o] trio2o git repo ready and
> tricircle splitting
>
> Thank you for your comment, Zhiyuan.
>
> For pod management, because these two projects need to run independently, I
> think submit patches separately as needed may be a better choice.
>
> Best Regards
> Chaoyi Huang(joehuang)
> 
> From: Vega Cai [luckyveg...@gmail.com]
> Sent: 18 September 2016 16:27
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tricircle][trio2o] trio2o git repo ready and
> tricircle splitting
>
> +1 for the proposal. What about the codes for Pod operation? It seems that
> both Tricircle and Trio2o need these codes. We submit patches to these two
> projects separately?
>
> Zhiyuan
>
> joehuang 于2016年9月18日周日 下午4:17写道：
>>
>> hello, team,
>>
>> Trio2o git repository is ready now: https://github.com/openstack/trio2o
>>
>> The repository inherited all files and commit messages from Tricircle.
>>
>> It's now the time start to do the tricircle splitting: a blue print is
>> registere for Tricircle cleaning:
>> https://blueprints.launchpad.net/tricircle/+spec/make-tricircle-dedicated-for-networking-automation-across-neutron.There
>> are lots of documentation work to do. Please review these doc in the BP,
>> thanks.
>>
>> There are some proposal for patches during the splitting:
>>
>> 1. For patch which is already in review status, let's review it in
>> Tricircle (no matter it's for Trio2o or Tricircle), after it's get merged,
>> then port it to Trio2o. After all patches get merged, let's have a last tag
>> for Tricircle to cover both gateway and networking automation function. Then
>> the cleaning will be done in Tricircle to make Tricircle as a project for
>> networking automation only
>> 2. For new patch which is only applicable to Trio2o, I propose that we
>> submit such patches in Trio2o only, no need to submit in Tricircle.
>>
>> Would like to know your thoughts on the splitting.
>>
>> 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 Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Email:
shin...@linux.com
shin...@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

[openstack-dev] [tricircle]freeze date and tricircle splitting

[joehuang]

Hello, as the Trio2o repository has been established, it's time for us to 
discuss the freeze date and tagging(newton branch) for the last release of 
Tricircle with gateway function.

The freeze date is the gate for patches to be merged before tagging(newton 
branch). If a patch can't finish review process before the freeze date, and not 
able to be merged in Tricircle, then it's suggested to be handled like this:

1. If it's networking automation related patch, continue the review process in 
Tricircle after tagging(newton branch), will be merged in Tricircle trunk in 
the future .

2. If it's gateway related patch, abandon the patch, re-submit the patch in 
Trio2o.

3. If it's patch about pod management, for it's common feature, so continue the 
review process in tricircle  after tagging(newton branch) , and submit a new 
patch for this feature in Trio2o separately.

Exception request after freeze date, before tagging(newton branch): If there is 
some patch must be merged before the tagging(newton branch), then need to send 
the exception request in the mail-list for the patch, and approved by PTL.

That means we need to define a deadline for patches to be merged in Tricircle 
before tagging(newton branch), and define the scope of patches wish to be 
merged in Trcircle before splitting.

Your thoughts, proposal for the freeze date and patches to be merged?

(As the old thread containing both Trio2o and Tricircle in the subject, not 
good to follow, so a new thread is started)

Best Regards
Chaoyi Huang (joehuang)


From: joehuang
Sent: 18 September 2016 16:34
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [tricircle][trio2o] trio2o git repo ready and 
tricircle splitting

Thank you for your comment, Zhiyuan.

For pod management, because these two projects need to run independently, I 
think submit patches separately as needed may be a better choice.

Best Regards
Chaoyi Huang(joehuang)

From: Vega Cai [luckyveg...@gmail.com]
Sent: 18 September 2016 16:27
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle][trio2o] trio2o git repo ready and 
tricircle splitting

+1 for the proposal. What about the codes for Pod operation? It seems that both 
Tricircle and Trio2o need these codes. We submit patches to these two projects 
separately?

Zhiyuan

joehuang mailto:joehu...@huawei.com>>于2016年9月18日周日 
下午4:17写道：
hello, team,

Trio2o git repository is ready now: https://github.com/openstack/trio2o

The repository inherited all files and commit messages from Tricircle.

It's now the time start to do the tricircle splitting: a blue print is 
registere for Tricircle cleaning: 
https://blueprints.launchpad.net/tricircle/+spec/make-tricircle-dedicated-for-networking-automation-across-neutron.There
 are lots of documentation work to do. Please review these doc in the BP, 
thanks.

There are some proposal for patches during the splitting:

1. For patch which is already in review status, let's review it in Tricircle 
(no matter it's for Trio2o or Tricircle), after it's get merged, then port it 
to Trio2o. After all patches get merged, let's have a last tag for Tricircle to 
cover both gateway and networking automation function. Then the cleaning will 
be done in Tricircle to make Tricircle as a project for networking automation 
only
2. For new patch which is only applicable to Trio2o, I propose that we submit 
such patches in Trio2o only, no need to submit in Tricircle.

Would like to know your thoughts on the splitting.

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 Development Mailing 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] Too many mails on announce list again :)

[Steve Martinelli]

I think bundling the puppet, ansible and oslo releases together would cut
down on a considerable amount of traffic. Bundling or grouping new releases
may not be the most accurate, but if it encourages the right folks to read
the content instead of brushing it off, I think thats worth while.

On Mon, Sep 19, 2016 at 10:04 PM, Tom Fifield  wrote:

> Hi all,
>
> Last November, we discussed the OpenStack-announce list, defined its
> purpose more finely and moved some internal library announcements to
> -dev[1].
>
> For reference, we describe the list as:
>
> """
> Subscribe to this list to receive important announcements from the
> OpenStack Release Team and OpenStack Security Team.
>
> This is a low-traffic, read-only list.
> """
>
> Unfortunately, the traffic on this list again regularly exceeds 100
> messages a month - worse than last time we talked about it.
>
> The feedback continues to come in from users that they find it more 'spam'
> than 'source of important announcements', which is not good news!
>
> Quite a lot of the email rush tends to come from when a particular project
> releases multiple 'components' at once. A fine effort of release
> management, but in the current system each component's release triggers its
> own email.
>
> For example, today the puppet team has been doing some great work with a
> 9.3.0 release. Many modules were updated. That's an "important
> announcement" for many of our users.
>
> However, to get the "low-traffic" bit, we need to make that 1 email,
> instead of 30 :)
>
>
> At least, that's my thinking. What's yours?
>
>
> Regards,
>
>
> Tom
>
>
>
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2015-Dece
> mber/082182.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Too many mails on announce list again :)

[Tom Fifield]

Hi all,

Last November, we discussed the OpenStack-announce list, defined its 
purpose more finely and moved some internal library announcements to 
-dev[1].


For reference, we describe the list as:

"""
Subscribe to this list to receive important announcements from the
OpenStack Release Team and OpenStack Security Team.

This is a low-traffic, read-only list.
"""

Unfortunately, the traffic on this list again regularly exceeds 100 
messages a month - worse than last time we talked about it.


The feedback continues to come in from users that they find it more 
'spam' than 'source of important announcements', which is not good news!


Quite a lot of the email rush tends to come from when a particular 
project releases multiple 'components' at once. A fine effort of release 
management, but in the current system each component's release triggers 
its own email.


For example, today the puppet team has been doing some great work with a 
9.3.0 release. Many modules were updated. That's an "important 
announcement" for many of our users.


However, to get the "low-traffic" bit, we need to make that 1 email, 
instead of 30 :)



At least, that's my thinking. What's yours?


Regards,


Tom




[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-December/082182.html


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

[openstack-dev] [horizon] Browser Support

[Jason Rist]

This page hasn't been updated for a while - does anyone know the latest?

https://wiki.openstack.org/wiki/Horizon/BrowserSupport

Thanks,
Jason
-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

__
OpenStack Development Mailing 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][FFE][kuryr] kuryr-lib

[Tony Breeds]

On Mon, Sep 19, 2016 at 10:43:41PM +0200, Antoni Segura Puimedon wrote:
> Hi,
> 
> We recently made the first release (0.1.0) of kuryr-lib on which no
> project depends except openstack/kuryr-libnetwork. Now, kuryr-lib by
> itself is not more than a base library and its release is only to
> serve kuryr-libnetwork and kuryr-kubernetes.
> 
> Now we are in the process of releasing kuryr-libnetwork and we'd need
> to include kuryr-lib to global requirements[1] (since kuryr-libnetwork
> requirements are managed by the openstack proposal's bot. Thus, I
> request an exception to set the minimal kuryr-lib version.

This can easily be added after newton is branched and the dust has settled and
then backported to the kuryr* stab;e/newton branches.

Yours Tony.


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

Re: [openstack-dev] [requirements] Bump swiftclient to 3.1.0

[Tony Breeds]

On Mon, Sep 19, 2016 at 08:09:49PM +0200, Julien Danjou wrote:
> On Mon, Sep 19 2016, Doug Hellmann wrote:
> 
> > We do not generally bump minimum versions for dependencies for bug
> > fixes, especially for only one project. Does this validation bug affect
> > other projects? Is python-swiftclient 2.2.0 (the current minimum)
> > fundamentally broken for all projects?
> 
> It affects any project that uses retries=0 in swiftclient.
> 
> There's no need to bump the minimum requirement for all OpenStack, but
> at least moving the uppercap.

This has been approved.

Yours Tony.


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

Re: [openstack-dev] Announcing firehose.openstack.org

[Tony Breeds]

On Mon, Sep 19, 2016 at 10:50:31AM -0400, Matthew Treinish wrote:
> Hi Everyone,
> 
> I wanted to announce the addition of a new infra service we started running
> recently, the firehose. Running at firehose.openstack.org the firehose is an
> MQTT based unified message bus for infra services. The concept behind is it 
> that
> there are a lot of infra services many of which emit events, however there
> wasn't a single place to go to for anything. If you have a script or tool 
> which
> is listening for events from an infra service, or has a poll loop (like 
> anything
> using gerritlib) there is now a single place to go for consuming those 
> messages.
> We also have 2 interfaces to subscribe to topics on the firehose, either via 
> the
> MQTT protocol on the default port or via a websockets over port 80. The 
> websocket
> interface should enable easier consumption for people on networks with 
> stricter
> firewalls.

Awesome!  I have a fun little project I'm going to use this for.  Thanks
everyone involved.

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] [tc]a chance to meet all TCs for Tricircle big-tent application in Barcelona summit?

[joehuang]

Hi, Shinobu,

Maybe you missed the thread for discussion on the patches,  how do you think 
about the proposal? You can reply in the old thread. And it should be a topic 
in the weekly meeting agenda.

Best Regards
Chaoyi Huang(joehuang)

From: Vega Cai [luckyveg...@gmail.com]
Sent: 18 September 2016 16:27
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle][trio2o] trio2o git repo ready and 
tricircle splitting

+1 for the proposal. What about the codes for Pod operation? It seems that both 
Tricircle and Trio2o need these codes. We submit patches to these two projects 
separately?

Zhiyuan

joehuang 于2016年9月18日周日 下午4:17写道：
hello, team,

Trio2o git repository is ready now: https://github.com/openstack/trio2o

The repository inherited all files and commit messages from Tricircle.

It's now the time start to do the tricircle splitting: a blue print is 
registere for Tricircle cleaning: 
https://blueprints.launchpad.net/tricircle/+spec/make-tricircle-dedicated-for-networking-automation-across-neutron.There
 are lots of documentation work to do. Please review these doc in the BP, 
thanks.

There are some proposal for patches during the splitting:

1. For patch which is already in review status, let's review it in Tricircle 
(no matter it's for Trio2o or Tricircle), after it's get merged, then port it 
to Trio2o. After all patches get merged, let's have a last tag for Tricircle to 
cover both gateway and networking automation function. Then the cleaning will 
be done in Tricircle to make Tricircle as a project for networking automation 
only 
2. For new patch which is only applicable to Trio2o, I propose that we submit 
such patches in Trio2o only, no need to submit in Tricircle.

Would like to know your thoughts on the splitting.

Best Regards
Chaoyi Huang(joehuang)




From: Shinobu Kinjo [shinobu...@gmail.com]
Sent: 20 September 2016 0:23
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc]a chance to meet all TCs for Tricircle 
big-tent application in Barcelona summit?

On Mon, Sep 19, 2016 at 6:22 PM, joehuang  wrote:
> Hello, all TCs,
>
> Understand that you will be quite busy in Barcelona summit, all TCs will be
> shown in the Barcelona summit, and meet together(usually, I assumed). So is
> it possible to have a chance to meet all TCs there for Tricircle big-tent
> application https://review.openstack.org/#/c/338796/ ? F2f talk to answer
> the concerns may help the understanding and decision.
>
> The splitting and cleaning of Tricircle hopefully could be finished before
> Barcelona summit.
>
> Although Tricircle splitting and cleaning is WIP, some draft materials were
> prepared for the understanding on Tricircle and  open comments, contribution
> etc:
>
> 1. Tricircle focuses on networking automation across
> Neutron:https://docs.google.com/presentation/d/1Zkoi4vMOGN713Vv_YO0GP6YLyjLpQ7fRbHlirpq6ZK4/
>
> 2. Tricircle design blueprint
> update:https://docs.google.com/document/d/1zcxwl8xMEpxVCqLTce2-dUOtB-ObmzJTbV1uSQ6qTsY/
>
> 3. Tricircle wiki update: https://wiki.openstack.org/wiki/Tricircle
>
> (Caution: the git repo. of Tricircle will be purified, nova_apigw and
> cinder_apigw will be removed from the repo. soon
> https://github.com/openstack/tricircle/ , the description will also be
> updated)

Just removing 2 functionality from repo probably would be fine.

But what you should clarify more is:

  - How we should take care of existing commitments for those 2 functionality.
   Some people still have been making patches for them.

And what I'm really confused with is that, even you're telling that we
will have removed those two from repo, you're still talking about
those two in different thread with no clarification.

That should be stopped now, if we will really go with what you
proposed above. Probably it's better not to say Tricircle any more to
avoid any confusion.

You should make a progress more *carefully* because project is being
changed with contributors who have been submitting patches eve now.

Regards,
Shinobu

>
> 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
>



--
Email:
shin...@linux.com
shin...@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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subjec

Re: [openstack-dev] [Congress] Default devstack deployment config

[Eric K]

Thanks, Anusha!

I agree with keeping both options, just using single proc as default.

Added a bug on it: https://bugs.launchpad.net/congress/+bug/1624172

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

Date:  Monday, September 19, 2016 at 2:05 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  Re: [openstack-dev] [Congress] Default devstack deployment config

> Hi All,
> 
> I too agree from the development point of view, its easier if we have a single
> process.
> But I was wondering, tempest jobs we run on gate, isn't it better they run
> with 3 processes deployed, to make sure it works across processes too?
> 
> Just a thought, how about we keep both the options, so that developers can
> deploy as single process and on gate we can test it with different processes?
> 
> Best Regards,
> Anusha
> 
> On 13 September 2016 at 18:10, Aimee Ukasick 
> wrote:
>> I completely agree with a single process deployment for DevStack. I
>> ran into issues last week with the multiple process configuration
>> while I trying to pinpoint an error.  I was using the pdb command line
>> debugger to step through Congress and Oslo Messaging, making a call
>> from the CLI. More than once the Congress API couldn't find the
>> Process Engine, which I'm sure was caused by uploading code and
>> stopping/starting services in the wrong order.  Deploying single
>> process Congress to DevStack would have saved me a lot of time.
>> 
>> aimee
>> 
>> On Tue, Sep 13, 2016 at 1:42 AM, Masahito MUROI
>>  wrote:
>>> > Hi Congress folks,
>>> >
>>> > I'm in favor of single process for devstack default. It's easy to check
>>> > logs and tests its feature.
>>> >
>>> > best regards,
>>> > Masahito
>>> >
>>> > On 2016/09/13 11:00, Tim Hinrichs wrote:
 >>
 >> I'd agree with a single process version of Congress for devstack.  I'd
 >> say we should even do that for Newton.
 >>
 >> Tim
 >>
 >> On Mon, Sep 12, 2016 at 6:34 PM Eric K >>> >> > wrote:
 >>
 >> Hi all,
 >>
 >> I want to get people’s thoughts regarding what we should set as
 >> default devstack deployment config for Ocata.
 >> At the moment, it is set to deploy three processes: API, policy, and
 >> datasource-drivers.
 >>
 >> I see some potential arguments against that:
 >>
 >>  1. For most users installing via devstack, running Congress in
 >> three processes bring little benefit, but rather a more complex
 >> and less stable user experience. (Even if our code is perfect,
 >> rabbitMQ will timeout every now and then)
 >>  2. It’s not clear that we want to officially support separating the
 >> API from the policy engine at this point. The supported
 >> deployment options for HAHT do not need it.
 >>
 >> The main argument I see for deploying three processes by default is
 >> that we may get more bug reports regarding the multi-process
 >> deployment that way.
 >>
 >> Our main options for devstack default are:
 >> 1. Single-process Congress (with in-mem transport).
 >> 2. Two-process Congress API+Policy, datasource-drivers. (other
 >> breakdowns between two processes are also possible)
 >> 3. Three-process Congress.
 >>
 >> In the end, I think it’s a trade-off: potentially getting more bug
 >> reports from users, at the expense of a more complex and less
 >> polished user experience that could make a poor first impression.
 >> What does everyone think?
 >>
 >> Personally, I slightly favor defaulting to single process Congress
 >> because from a typical devstack user’s perspective, there is little
 >> reason to run separate processes. In addition, because it is the
 >> first time we’re releasing our complete architecture overhaul to the
 >> wild, and it may be a good to default to the least complex
 >> deployment for the first cycle of the new architecture.
 >>
 >> 
 __
 >> OpenStack Development Mailing 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
 

Re: [openstack-dev] [release][ptl] stable/newton branches

[Doug Hellmann]

Excerpts from Lingxian Kong's message of 2016-09-20 09:20:42 +1200:
> Hi, Doug, Mistral didn't have a stable/newton branch, did we miss something?

There was an issue creating that branch that I thought I resolved by
hand, but apparently not all of the fix was pushed. I've taken care of
it so the branch should be there now. I'm sorry about the delay.

Doug

> 
> I already sent msg in release team irc channel, ask here again in case
> you didn't see that :-)
> 
> Cheers,
> Lingxian Kong (Larry)
> 
> On Tue, Sep 20, 2016 at 7:06 AM, Doug Hellmann  wrote:
> > All of the cycle-with-milestone projects have tagged a first release
> > candidate and had their stable/newton branches created.
> >
> > Most of the intermediary projects also have had their stable/newton
> > branches created.
> >
> > If you have a project that has not yet had a branch created, and
> > you are ready to have one, reply to this email thread with the
> > deliverable names.
> >
> > Remember, we always create stable branches from tagged versions so
> > we will use the most recently tagged version as the branch point.
> > If you want the branch to include something that has been committed
> > to master after that tag, we will need to tag again before branching.
> >
> > 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

Re: [openstack-dev] [requirements][FFE][kuryr] kuryr-lib

[Matthew Thode]

On 09/19/2016 03:43 PM, Antoni Segura Puimedon wrote:
> Hi,
> 
> We recently made the first release (0.1.0) of kuryr-lib on which no
> project depends except openstack/kuryr-libnetwork. Now, kuryr-lib by
> itself is not more than a base library and its release is only to
> serve kuryr-libnetwork and kuryr-kubernetes.
> 
> Now we are in the process of releasing kuryr-libnetwork and we'd need
> to include kuryr-lib to global requirements[1] (since kuryr-libnetwork
> requirements are managed by the openstack proposal's bot. Thus, I
> request an exception to set the minimal kuryr-lib version.
> 
> Regards,
> 
> Toni
> 
> [1] https://review.openstack.org/#/c/369755/
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

This is extremely late in the process (we asked for an FFE back on the
13th).  I don't see an issue other than the details noted in the review,
but I'll wait for tony's feedback.

http://codesearch.openstack.org/?q=kuryr&i=nope&files=requirements.txt&repos=

-- 
-- Matthew Thode (prometheanfire)



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

Re: [openstack-dev] [release][mistral] mistral Newton RC1 available

[Lingxian Kong]

Thanks Dougal for reporting that, we are working on the issue.

Cheers,
Lingxian Kong (Larry)


On Fri, Sep 16, 2016 at 11:27 PM, Dougal Matthews  wrote:
>
>
> On 16 September 2016 at 00:06, Doug Hellmann  wrote:
>>
>> Hello everyone,
>>
>> The release candidate for mistral for the end of the Newton cycle
>> is available!  You can find the RC1 source code tarballs at:
>>
>> https://tarballs.openstack.org/mistral/mistral-3.0.0.0rc1.tar.gz
>>
>> https://tarballs.openstack.org/mistral-dashboard/mistral-dashboard-3.0.0.0rc1.tar.gz
>>
>> Unless release-critical issues are found that warrant a release
>> candidate respin, this RC1 will be formally released as the final
>> Newton release on 6 October. You are therefore strongly
>> encouraged to test and validate this tarball!
>
>
> I believe we (TripleO) are hitting a release critical issue here:
> https://bugs.launchpad.net/mistral/+bug/1624284
>
> I have tagged the issue.
>
>
>> Alternatively, you can directly test the stable/newton release
>> branch at:
>>
>> http://git.openstack.org/cgit/openstack/mistral/log/?h=stable/newton
>>
>> If you find an issue that could be considered release-critical,
>> please file it at:
>>
>> https://bugs.launchpad.net/mistral/+filebug
>>
>> and tag it *newton-rc-potential* to bring it to the mistral release
>> crew's attention.
>>
>> Note that the "master" branch of mistral is now open for Ocata
>> development, and feature freeze restrictions no longer apply there!
>>
>> Thanks,
>> 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] [release][ptl] stable/newton branches

[Lingxian Kong]

Hi, Doug, Mistral didn't have a stable/newton branch, did we miss something?

I already sent msg in release team irc channel, ask here again in case
you didn't see that :-)

Cheers,
Lingxian Kong (Larry)


On Tue, Sep 20, 2016 at 7:06 AM, Doug Hellmann  wrote:
> All of the cycle-with-milestone projects have tagged a first release
> candidate and had their stable/newton branches created.
>
> Most of the intermediary projects also have had their stable/newton
> branches created.
>
> If you have a project that has not yet had a branch created, and
> you are ready to have one, reply to this email thread with the
> deliverable names.
>
> Remember, we always create stable branches from tagged versions so
> we will use the most recently tagged version as the branch point.
> If you want the branch to include something that has been committed
> to master after that tag, we will need to tag again before branching.
>
> 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] [ironic] weekly subteam report

[Loo, Ruby]

Hi,

Here is this week's subteam report for Ironic. As usual, this is pulled 
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff between 12 Sep 2016 and 16 Sep 2016)
  - Ironic: 186 bugs (-69) + 215 wishlist items (+2). 1 new (-40), 145 in 
progress (-36), 0 critical, 32 high (-3) and 15 incomplete (-1)
  - Inspector: 11 bugs + 18 wishlist items (-2). 1 new, 12 in progress, 0 
critical, 2 high and 1 incomplete
  - Nova bugs with Ironic tag: 8 (-1). 0 new, 0 critical, 0 high
- the bug smash was a fantastic success, let's have it from time to time
- dtantsur on PTO Sep 19-20, so the stats are from Friday

Gate improvements (jlvillal, lucasagomes, dtantsur)
===
* trello: 
https://trello.com/c/HWVHhxOj/1-multi-tenant-networking-network-isolation
- we've reduced the number of unused jobs we generate in project-config
- one missing job was spotted and added: pxe_ssh + whole disk image (and it 
seems to pass!)
- TODO: make it voting after some time
- vsaienk0 is working on experimental job using Xenial
- Patches proposed to get ironic-multinode job workiing.

Notifications (mariojv)
===
* trello: https://trello.com/c/MD8HNcwJ/17-notifications
- power state notifications: https://review.openstack.org/#/c/321865/ needs 
more work and reviews

Enhanced root device hints (lucasagomes)

* trello: https://trello.com/c/f9DTEvDB/21-enhanced-root-device-hints
- It's been postponed to Ocata, but the base patches for ironic-lib is already 
merged
- A -2 patch waiting for Ocata to open is already proposed: 
https://review.openstack.org/#/c/366742/

Install guide migration (JayF and mat128)
=
- https://review.openstack.org/#/q/topic:bug/1612278

Inspector (dtansur)
===
- we've worked around a problem with grenade, so we're landing the last patches 
for Newton
- we've moved all our jobs except for discovery one to grenade (incl. nv jobs 
on ironic and IPA)
- we plan on moving the discovery job too before stable/newton

Drivers:

DRAC (mgould/lucas)
---
- ifarkas has left RH, our new contact for the driver is mgould

.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard

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

Re: [openstack-dev] [puppet] weekly meeting #91

[Iury Gregory]

Hi Puppeteers,

If you have any topic to add for this week, please use the etherpad:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160920

See you tomorrow =)

2016-09-12 13:23 GMT-03:00 Emilien Macchi :

> Hi,
>
> Tomorrow we'll have our weekly meeting:
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160913
> Feel free to add topics as usual,
>
> Thanks!
>
> On Thu, Sep 8, 2016 at 9:57 AM, Iury Gregory 
> wrote:
> > No topic/discussion in our agenda, we cancelled the meeting, see you next
> > week!
> >
> > 2016-09-05 15:39 GMT-03:00 Iury Gregory :
> >>
> >> Hi Puppeteers,
> >>
> >> If you have any topic to add for this week, please use the etherpad:
> >> https://etherpad.openstack.org/p/puppet-openstack-weekly-
> meeting-20160906
> >>
> >> See you tomorrow =)
> >>
> >> 2016-08-30 12:02 GMT-03:00 Emilien Macchi :
> >>>
> >>> No topic this week, meeting cancelled!
> >>>
> >>> See you next week :)
> >>>
> >>> On Mon, Aug 29, 2016 at 1:45 PM, Emilien Macchi 
> >>> wrote:
> >>> > Hi,
> >>> >
> >>> > If you have any topic to add for this week, please use the etherpad:
> >>> >
> >>> > https://etherpad.openstack.org/p/puppet-openstack-weekly-
> meeting-20160830
> >>> >
> >>> > See you tomorrow,
> >>> >
> >>> > On Tue, Aug 23, 2016 at 1:08 PM, Iury Gregory  >
> >>> > wrote:
> >>> >> No topic/discussion in our agenda, we cancelled the meeting, see you
> >>> >> next
> >>> >> week!
> >>> >>
> >>> >>
> >>> >>
> >>> >> 2016-08-22 16:19 GMT-03:00 Iury Gregory :
> >>> >>>
> >>> >>> Hi Puppeteers!
> >>> >>>
> >>> >>> We'll have our weekly meeting tomorrow at 3pm UTC on
> >>> >>> #openstack-meeting-4
> >>> >>>
> >>> >>> Here's a first agenda:
> >>> >>>
> >>> >>> https://etherpad.openstack.org/p/puppet-openstack-weekly-
> meeting-20160823
> >>> >>>
> >>> >>> Feel free to add topics, and any outstanding bug and patch.
> >>> >>>
> >>> >>> See you tomorrow!
> >>> >>> Thanks,
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >>
> >>> >> ~
> >>> >> Att[]'s
> >>> >> Iury Gregory Melo Ferreira
> >>> >> Master student in Computer Science at UFCG
> >>> >> E-mail:  iurygreg...@gmail.com
> >>> >> ~
> >>> >>
> >>> >>
> >>> >> 
> __
> >>> >> OpenStack Development Mailing List (not for usage questions)
> >>> >> Unsubscribe:
> >>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Emilien Macchi
> >>>
> >>>
> >>>
> >>> --
> >>> Emilien Macchi
> >>>
> >>>
> >>> 
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >>
> >> --
> >>
> >> ~
> >> Att[]'s
> >> Iury Gregory Melo Ferreira
> >> Master student in Computer Science at UFCG
> >> E-mail:  iurygreg...@gmail.com
> >> ~
> >
> >
> >
> >
> > --
> >
> > ~
> > Att[]'s
> > Iury Gregory Melo Ferreira
> > Master student in Computer Science at UFCG
> > E-mail:  iurygreg...@gmail.com
> > ~
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

~


*Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science at
UFCG*
*E-mail:  iurygreg...@gmail.com *
~
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][sahara] LVM vs BDD drivers performance tests results

[Duncan Thomas]

I think there's some mileage in some further work on adding local LVM,
since things like striping/mirroring for performace can be done. We can
prototype it and get the numbers before even thinking about merging though
- as additions to an already fully featured driver. these seem more
worthwhile a way forward than limping on with the bdd driver.

Moving to change our default target to LIO seems worthwhile - I'd suggest
being cautious with deprecation rather than aggressive though - aiming to
change the default in 'O' then planning the rest based on how that goes.

On 19 September 2016 at 21:54, John Griffith 
wrote:

>
>
> On Mon, Sep 19, 2016 at 12:01 PM, Ivan Kolodyazhny  wrote:
>
>> + [sahara] because they are primary consumer of the BDD.
>>
>> John,
>> Thanks for the answer. My comments are inline.
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>> On Mon, Sep 19, 2016 at 4:41 PM, John Griffith 
>> wrote:
>>
>>>
>>>
>>> On Mon, Sep 19, 2016 at 4:43 AM, Ivan Kolodyazhny 
>>> wrote:
>>>
 Hi team,

 We did some performance tests [1] for LVM and BDD drivers. All tests
 were executed on real hardware with OpenStack Mitaka release.
 Unfortunately, we didn't have enough time to execute all tests and compare
 results. We used Sahara/Hadoop cluster with TestDFSIO and others
 tests.

 All tests were executed on the same hardware and OpenStack release.
 Only difference were in cinder.conf to enable needed backend and/or target
 driver.

 Tests were executed on following configurations:

- LVM +TGT target
- LVM+LocalTarget: PoC based on [2] spec
- LVM+LIO
- Block Device Driver.


 Feel free to ask question if any about our testing infrastructure,
 environment, etc.


 [1] https://docs.google.com/spreadsheets/d/1qS_ClylqdbtbrVSvwbbD
 pdWNf2lZPR_ndtW6n54GJX0/edit?usp=sharing
 [2] https://review.openstack.org/#/c/247880/

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

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

 ​Thanks Ivan, so I'd like to propose we (the Cinder team) discuss a few
>>> things (again):
>>>
>>> 1. Deprecate the BDD driver
>>>  Based on the data here LVM+LIO the delta in performance ​(with the
>>> exception of the Terravalidate run against 3TB) doesn't seem significant
>>> enough to warrant maintaining an additional driver that has only a subset
>>> of features implemented.  It would be good to understand why that
>>> particular test has such a significant peformance gap.
>>>
>> What about Local Target? Does it make sense to implement it instead BDD?
>>
> ​Maybe I'm missing something, what would the advantage be?  LVM+LIO and
> LVM+LOCAL-TARGET seem pretty close.  In the interest of simplicity and
> maintenance just thinking maybe it would be worth considering just using
> LVM+LIO across the board.
> ​
>
>
>>
>>> 2. Consider getting buy off to move the default implementation to use
>>> the LIO driver and consider deprecating the TGT driver
>>>
>> +1. Let's bring this topic for the next weekly meeting.
>>
>>
>>
>>>
>>> I realize this probably isn't a sufficient enough data set to make those
>>> two decisions but I think it's at least enough to have a more informed
>>> discussion this time.
>>>
>>> Thanks,
>>> John​
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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:unsubscrib
>> e
>> 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
>
>


-- 
-- 
Duncan Thomas
__
OpenStack Development Mailing 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] [puppet] Preparing TripleO agenda for Barcelona - action needed

[Emilien Macchi]

(adding puppet tag for cross project session).

Let's continue to prepare TripleO sessions.

https://etherpad.openstack.org/p/ocata-tripleo

For reminder, we have 2 fishbowls and 4 working rooms.
I looked at the topic proposals and I started to organize some sessions.

Some actions from you are required:
- review the session proposal
- if you want to drive a session, please put your name in "Chair".
- for each session we need to choose if we want it to be a work room
or a fishbowl session.
- 4 topics are still there, please propose a session (concatenate them
if possible)
- if you missed this etherpad until now, feel free to propose a
session with your topic (ex: TripleO UI - roadmap, etc).

At least but not least, I would propose a cross project session with
Puppet OpenStack group (using a slot from their schedule) so we might
have a 7th session.

Your feedback is very important, please take some time when you can to
look at the schedule, so we can have productive sessions in Barcelona.

Thanks,
-- 
Emilien Macchi

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

[openstack-dev] [requirements][FFE][kuryr] kuryr-lib

[Antoni Segura Puimedon]

Hi,

We recently made the first release (0.1.0) of kuryr-lib on which no
project depends except openstack/kuryr-libnetwork. Now, kuryr-lib by
itself is not more than a base library and its release is only to
serve kuryr-libnetwork and kuryr-kubernetes.

Now we are in the process of releasing kuryr-libnetwork and we'd need
to include kuryr-lib to global requirements[1] (since kuryr-libnetwork
requirements are managed by the openstack proposal's bot. Thus, I
request an exception to set the minimal kuryr-lib version.

Regards,

Toni

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

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

Re: [openstack-dev] [TripleO] Network Template Generator

[Ben Nemec]

On 09/09/2016 10:28 AM, Liz Blanchard wrote:



On Wed, Aug 10, 2016 at 7:10 PM, Ben Nemec mailto:openst...@nemebean.com>> wrote:

On 08/10/2016 11:05 AM, Liz Blanchard wrote:
>
>
> On Wed, Aug 10, 2016 at 11:52 AM, Ben Nemec mailto:openst...@nemebean.com>
> >> wrote:
>
> On 08/08/2016 09:22 PM, Dan Prince wrote:
> > On Mon, 2016-08-08 at 15:42 -0500, Ben Nemec wrote:
> >> This is something that has existed for a while, but I had been
> >> hesitant
> >> to evangelize it until it was a little more proven.  At this point
> >> I've
> >> used it to generate templates for a number of different 
environments,
> >> and it has worked well.  I decided it was time to record another 
demo
> >> and throw it out there for the broader community to look at.  See
> >> details on my blog:
> >>
http://blog.nemebean.com/content/tripleo-network-isolation-template-g 

>
> >> enerator
> >>
> >> Most of what you need to know is either there or in the video 
itself.
> >> Let me know what you think.
> >
> > Very cool. For those that don't like "hand cutting" their own 
network
> > configuration templates this is a good CLI based generator.
> >
> > Like you mention it would be nice to eventually converge this tool
> > somehow into both the UI and CLI but given that it works with older
> > releases as well it makes sense that it is CLI only for now.
>
> Yeah, my assumption is that at some point the UI will have similar
> functionality.  Ideally the UI would replace this entirely, but I
> suspect that's a ways off and we'll have to see how it plays out for
> people doing CLI installs.
>
>
> Speaking of which...I'd love to work closely with you, Ben, to put
> together a wireframe design for the TripleO UI to support something like
> what you've done here. It looks awesome and I'd love to understand the
> use cases a bit more and how it might work into the current UI flow.
>
> I do have a first draft of a design that allows for some network
> configuration that I'd love to get folks thoughts on:
> https://invis.io/UM87J4NBQ
>
> Of course, as you mention, this would be something that is looking into
> the future for the UI but it would be awesome to start now with
> wireframes :)

Sure, I'm happy to provide whatever input I can.  We'll probably want to
include Dan Sneddon in those discussions as well.  He had a lot of good
feedback on the early versions of this tool.

In general, I'm pretty happy with how the tool's UI works.  The one big
thing missing is an overview diagram of what's been configured.  The
multi-pane layout keeps the view simple since you can only drill down
one path at a time, but it does make it hard to see the big picture
sometimes.  I think I actually saw a mockup of a network visualization
you had done a while back that would potentially have filled this gap
nicely.

I'm not really a web UI developer (and I'm pointedly not looking at
http://ucw-bnemec.rhcloud.com/ ;-) so I don't know how everything in my
tool will map to that, but I could probably write up some user stories
that I was trying to address.  I can also tell you what I specifically
did not intend to support, because I lost some time designing for stuff
that Dan ultimately told me we didn't need to worry about.

I'm out on PTO next week, so it may be after that before I have a chance
to follow-up, but I'll add it to the TODO list. :-)


Ben,

I hope you had a good PTO. Sorry it's taken me a little while to follow
up, but I wanted to share some ideas I've put together around
translating the tool you've built into some UI components within the
TripleO UI. If you have some time check out the workflow I've started
around Network Configuration:
https://openstack.invisionapp.com/share/UM87J4NBQ


Specifically pages 8-11 show how a user could view and edit Network
Isolation configuration options as you've allowed in the tool you wrote.

This is still an early draft so please feel free to make any comments or
suggestions on how to change and improve this for users :)


I've been a little swamped since I got back myself, so I'm just getting 
back to this.


I left a few comments on the screens, but mostly it looks reasonable to 
me.  I also wrote up something about the standalone tool here: 
https://etherpad.openstack.org/p/tripleo-net-iso-user-stories (it didn't 
end up 

Re: [openstack-dev] [vote][kolla] deprecation for fedora distro support

[Vikram Hosakote (vhosakot)]

I vote for option 2.

Regards,
Vikram Hosakote
IRC:  vhosakot

From: Ryan Hallisey mailto:rhall...@redhat.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, September 19, 2016 at 2:58 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [vote][kolla] deprecation for fedora distro support

option 2

Thanks
-Ryan

- Original Message -
From: "Mauricio Lima" mailto:mauricioli...@gmail.com>>
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Sent: Monday, September 19, 2016 2:21:51 PM
Subject: Re: [openstack-dev] [vote][kolla] deprecation for fedora distro support

Option 2

2016-09-19 14:56 GMT-03:00 Christian Berendt < 
bere...@betacloud-solutions.de > :


Thanks for moving this forward.

On 19 Sep 2016, at 19:40, Jeffrey Zhang < 
zhang.lei@gmail.com > wrote:
1. Kolla needs support fedora( if so, we need some guys to set up the
gate and fix all the issues ASAP in O cycle)
2. Kolla should deprecate fedora support

+1 on option 2.

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



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

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

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

Re: [openstack-dev] [nova][neutron] summit cross-project session

[Armando M.]

On 18 September 2016 at 11:46, Matt Riedemann 
wrote:

> I want to confirm whether or not we're going to have a nova/neutron
> cross-project fishbowl session in Barcelona, I think we are. Since Thierry
> has the draft slots out I wanted to start looking at what time is going to
> work.
>
Looking at:
>
> https://docs.google.com/spreadsheets/d/1TQ-RSlbiBBEclkonIbfU
> P7R1ExZSJylF1uiEKV2G_Cw/pubhtml?gid=1107826458&single=true
>
> Anytime on Thursday afternoon would work - agreed? I'd like to pencil
> something in.
>

I asked an extra session on the Neutron side to dedicate to nova/neutron,
and I was hoping to have them back to back, but it doesn't look possible
under the current arrangement. Do you think it's worth trying and tweak
things? If not I guess we can have one on Wed the other on Thu.


>
> As far as topics, I think we'll pull from the neutron midcycle report:
>
> http://lists.openstack.org/pipermail/openstack-dev/2016-August/102366.html
>
> So mainly live migration and API interaction improvements.


>
> --
>
> 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

Re: [openstack-dev] [vote][kolla] deprecation for fedora distro support

[Steven Dake (stdake)]

I disagree.  Oracle Linux is well implemented and very well maintained by Paul 
Bourke and many other fine folks from Oracle. CentOS is derived from RHEL 
(changing trademarks and marketing fluff, not code).

Regards
-steve

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

Date: Monday, September 19, 2016 at 10:53 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [vote][kolla] deprecation for fedora distro support



On 19 September 2016 at 18:40, Jeffrey Zhang 
mailto:zhang.lei@gmail.com>> wrote:
Kolla core reviewer team,

Kolla supports multiple Linux distros now, including

* Ubuntu
* CentOS
* RHEL
* Fedora
* Debian
* OracleLinux

But only Ubuntu, CentOS, and OracleLinux are widely used and we have
robust gate to ensure the quality.

For fedora, Kolla hasn't any test for it and nobody reports any bug
about it( i.e. nobody use fedora as base distro image). We (kolla
team) also do not have enough resources to support so many Linux
distros. I prefer to deprecate fedora support now.  This is talked in
past but inconclusive[0].

Please vote:

1. Kolla needs support fedora( if so, we need some guys to set up the
gate and fix all the issues ASAP in O cycle)
2. Kolla should deprecate fedora support

[0] http://lists.openstack.org/pipermail/openstack-dev/2016-June/098526.html


+1

Honestly, only CentOS and Ubuntu are seriously implemented.. I'd go further and 
rip out the rest unless there is a strong effort from people committed to 
getting parity.

--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing 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] [vote][kolla] deprecation for debian distro support

[Steven Dake (stdake)]

+1 for option #2 with same commentary as prior relating to fedora.

Regards
-steve


On 9/19/16, 10:44 AM, "Jeffrey Zhang"  wrote:

Kolla core reviewer team,

Kolla supports multiple Linux distros now, including

* Ubuntu
* CentOS
* RHEL
* Fedora
* Debian
* OracleLinux

But only Ubuntu, CentOS, and OracleLinux are widely used and we have
robust gate to ensure the quality.

For Debian, Kolla hasn't any test for it and nobody reports any bug
about it( i.e. nobody use Debian as base distro image). We (kolla
team) also do not have enough resources to support so many Linux
distros. I prefer to deprecate Debian support now.

Please vote:

1. Kolla needs support Debian( if so, we need some guys to set up the
gate and fix all the issues ASAP in O cycle)
2. Kolla should deprecate Debian support

Voting is open for 7 days until September 27st, 2016.

-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

__
OpenStack Development Mailing 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] [vote][kolla] deprecation for fedora distro support

[Steven Dake (stdake)]

+1 for option 2, unless some good Fedora folk appear in Kolla to maintain it in 
the future.  In that case, we can always undo a deprecation within a cycle.

Note the deprecation policy states that we do not remove functionality for 1 
cycle after having released it for stable deliverables.  Even though fedora is 
broken, it would be a violation of the deprecation policies to do so.  Notng it 
is planned for deprecation in Newton and then doing the work of deprecating it 
can be done in Ocata.

Regards
-steve



On 9/19/16, 10:42 AM, "Jeffrey Zhang"  wrote:

Voting is open for 7 days until September 27st, 2016.

On Tue, Sep 20, 2016 at 1:40 AM, Jeffrey Zhang  
wrote:
> Kolla core reviewer team,
>
> Kolla supports multiple Linux distros now, including
>
> * Ubuntu
> * CentOS
> * RHEL
> * Fedora
> * Debian
> * OracleLinux
>
> But only Ubuntu, CentOS, and OracleLinux are widely used and we have
> robust gate to ensure the quality.
>
> For fedora, Kolla hasn't any test for it and nobody reports any bug
> about it( i.e. nobody use fedora as base distro image). We (kolla
> team) also do not have enough resources to support so many Linux
> distros. I prefer to deprecate fedora support now.  This is talked in
> past but inconclusive[0].
>
> Please vote:
>
> 1. Kolla needs support fedora( if so, we need some guys to set up the
> gate and fix all the issues ASAP in O cycle)
> 2. Kolla should deprecate fedora support
>
> [0] 
http://lists.openstack.org/pipermail/openstack-dev/2016-June/098526.html
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

__
OpenStack Development Mailing 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] [release][ptl] stable/newton branches

[Doug Hellmann]

All of the cycle-with-milestone projects have tagged a first release
candidate and had their stable/newton branches created.

Most of the intermediary projects also have had their stable/newton
branches created.

If you have a project that has not yet had a branch created, and
you are ready to have one, reply to this email thread with the
deliverable names.

Remember, we always create stable branches from tagged versions so
we will use the most recently tagged version as the branch point.
If you want the branch to include something that has been committed
to master after that tag, we will need to tag again before branching.

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] [vote][kolla] deprecation for fedora distro support

[Michał Jastrzębski]

yup, +1 on deprecation

On 19 September 2016 at 13:58, Ryan Hallisey  wrote:
> option 2
>
> Thanks
> -Ryan
>
> - Original Message -
> From: "Mauricio Lima" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Monday, September 19, 2016 2:21:51 PM
> Subject: Re: [openstack-dev] [vote][kolla] deprecation for fedora distro  
>   support
>
> Option 2
>
> 2016-09-19 14:56 GMT-03:00 Christian Berendt < bere...@betacloud-solutions.de 
> > :
>
>
> Thanks for moving this forward.
>
>> On 19 Sep 2016, at 19:40, Jeffrey Zhang < zhang.lei@gmail.com > wrote:
>>
>> 1. Kolla needs support fedora( if so, we need some guys to set up the
>> gate and fix all the issues ASAP in O cycle)
>> 2. Kolla should deprecate fedora support
>
> +1 on option 2.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [vote][kolla] deprecation for fedora distro support

[Ryan Hallisey]

option 2

Thanks
-Ryan

- Original Message -
From: "Mauricio Lima" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, September 19, 2016 2:21:51 PM
Subject: Re: [openstack-dev] [vote][kolla] deprecation for fedora distro
support

Option 2 

2016-09-19 14:56 GMT-03:00 Christian Berendt < bere...@betacloud-solutions.de > 
: 


Thanks for moving this forward. 

> On 19 Sep 2016, at 19:40, Jeffrey Zhang < zhang.lei@gmail.com > wrote: 
> 
> 1. Kolla needs support fedora( if so, we need some guys to set up the 
> gate and fix all the issues ASAP in O cycle) 
> 2. Kolla should deprecate fedora support 

+1 on option 2. 

__ 
OpenStack Development Mailing 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] [band] OpenStack Summit - Barcelona - musicians please raise your hands

[Amrith Kumar]

Thanks Neil, sounds like we’ll have a couple of others (who’ve replied 
privately and not to the ML) bringing instruments as well. I have heard so far 
from:

Three guitars
One flute/sax

Thanks,

-amrith

From: Neil Jerram [mailto:n...@tigera.io]
Sent: Monday, September 19, 2016 2:36 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [band] OpenStack Summit - Barcelona - musicians 
please raise your hands

I will be happy to bring my clarinet.
 Neil

On Sat, Sep 17, 2016 at 7:37 PM Colette Alexander 
mailto:colettealexan...@gmail.com>> wrote:
On Sat, Sep 17, 2016 at 1:35 PM, Amrith Kumar 
mailto:amr...@tesora.com>> wrote:
> So, would y'all musicians who plan to bring your gear to Barcelona please 
> start a little thread here on the ML and let's get a band going?

I would totally bring my gear if my cello didn't need its own plane seat!

If someone in Spain has a cello though, I will totally play.

-colette/gothicmindfood

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

Re: [openstack-dev] [cinder][sahara] LVM vs BDD drivers performance tests results

[John Griffith]

On Mon, Sep 19, 2016 at 12:01 PM, Ivan Kolodyazhny  wrote:

> + [sahara] because they are primary consumer of the BDD.
>
> John,
> Thanks for the answer. My comments are inline.
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Mon, Sep 19, 2016 at 4:41 PM, John Griffith 
> wrote:
>
>>
>>
>> On Mon, Sep 19, 2016 at 4:43 AM, Ivan Kolodyazhny  wrote:
>>
>>> Hi team,
>>>
>>> We did some performance tests [1] for LVM and BDD drivers. All tests
>>> were executed on real hardware with OpenStack Mitaka release.
>>> Unfortunately, we didn't have enough time to execute all tests and compare
>>> results. We used Sahara/Hadoop cluster with TestDFSIO and others tests.
>>>
>>> All tests were executed on the same hardware and OpenStack release. Only
>>> difference were in cinder.conf to enable needed backend and/or target
>>> driver.
>>>
>>> Tests were executed on following configurations:
>>>
>>>- LVM +TGT target
>>>- LVM+LocalTarget: PoC based on [2] spec
>>>- LVM+LIO
>>>- Block Device Driver.
>>>
>>>
>>> Feel free to ask question if any about our testing infrastructure,
>>> environment, etc.
>>>
>>>
>>> [1] https://docs.google.com/spreadsheets/d/1qS_ClylqdbtbrVSvwbbD
>>> pdWNf2lZPR_ndtW6n54GJX0/edit?usp=sharing
>>> [2] https://review.openstack.org/#/c/247880/
>>>
>>> Regards,
>>> Ivan Kolodyazhny,
>>> http://blog.e0ne.info/
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> ​Thanks Ivan, so I'd like to propose we (the Cinder team) discuss a few
>> things (again):
>>
>> 1. Deprecate the BDD driver
>>  Based on the data here LVM+LIO the delta in performance ​(with the
>> exception of the Terravalidate run against 3TB) doesn't seem significant
>> enough to warrant maintaining an additional driver that has only a subset
>> of features implemented.  It would be good to understand why that
>> particular test has such a significant peformance gap.
>>
> What about Local Target? Does it make sense to implement it instead BDD?
>
​Maybe I'm missing something, what would the advantage be?  LVM+LIO and
LVM+LOCAL-TARGET seem pretty close.  In the interest of simplicity and
maintenance just thinking maybe it would be worth considering just using
LVM+LIO across the board.
​


>
>> 2. Consider getting buy off to move the default implementation to use the
>> LIO driver and consider deprecating the TGT driver
>>
> +1. Let's bring this topic for the next weekly meeting.
>
>
>
>>
>> I realize this probably isn't a sufficient enough data set to make those
>> two decisions but I think it's at least enough to have a more informed
>> discussion this time.
>>
>> Thanks,
>> John​
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] [release][searchlight] searchlight Newton RC1 available

[Doug Hellmann]

Hello everyone,

The release candidate for searchlight for the end of the Newton cycle
is available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/searchlight/searchlight-1.0.0.0rc1.tar.gz
https://tarballs.openstack.org/searchlight-ui/searchlight-ui-1.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final
Newton release on 6 October. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/searchlight/log/?h=stable/newton

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/searchlight/+filebug

and tag it *newton-rc-potential* to bring it to the searchlight release
crew's attention.

Note that the "master" branch of searchlight is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,
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] [band] OpenStack Summit - Barcelona - musicians please raise your hands

[Neil Jerram]

I will be happy to bring my clarinet.
 Neil


On Sat, Sep 17, 2016 at 7:37 PM Colette Alexander <
colettealexan...@gmail.com> wrote:

> On Sat, Sep 17, 2016 at 1:35 PM, Amrith Kumar  wrote:
> > So, would y'all musicians who plan to bring your gear to Barcelona
> please start a little thread here on the ML and let's get a band going?
>
> I would totally bring my gear if my cello didn't need its own plane seat!
>
> If someone in Spain has a cello though, I will totally play.
>
> -colette/gothicmindfood
>
> __
> OpenStack Development Mailing 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] Singing in Barcelona

[Neil Jerram]

Being reminded by the band thread, I thought I should remind about this
too...


On Mon, Jul 11, 2016 at 6:56 PM Neil Jerram  wrote:

> I know it's crazy, but I've talked with a few people in Vancouver, Tokyo
> and Austin about the idea of getting a singing group together during a
> summit, and they've all encouraged me to go for it - so I'll start to look
> silly if I don't even try this... :-)
>
> So this is a call for anyone who wants to do some singing in Barcelona. I
> don't yet know who, what, or how we'll perform, but I've created an
> etherpad:
>
> https://etherpad.openstack.org/p/barcelona-singing
>
> Please do contribute there if interested! As with everything in OpenStack,
> it's important for this to be inclusive, so please don't exclude yourself
> by assuming anything about style of music or required abilities - feel free
> to add whatever your ideas and interests might be.
>
>  Neil
>
>
__
OpenStack Development Mailing 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] [searchlight] Matt Borland Searchlight UI Core Nomination

[Aulino, Rick]

+1 for Matt being a core. Great job Matt!

+1 for creating a new searchlight-ui core team that is more than the union of 
the Searchlight/Horizon core teams.

--
Rick Aulino

-Original Message-
From: Tripp, Travis S 
Sent: Monday, September 19, 2016 10:13 AM
To: OpenStack List 
Subject: [openstack-dev] [searchlight] Matt Borland Searchlight UI Core 
Nomination

Hello!
 
I am nominating Matt Borland for Searchlight UI core. Matt has been working on 
searchlight UI since we started it and he is the primary author of the angular 
registration framework in Horizon which Searchlight depends upon. Matt has the 
second most searchlight UI commits in Newton [0], but more impressively, Matt 
has more commits on Horizon than ANY other person in Newton [1]. In addition, 
Matt is a top 5 reviewer on Searchlight UI [2] and a 12 reviewer on horizon [3] 
He has provided thoughtful feedback and valuable insights throughout his time 
on Searchlight.

Searchlight UI core team is currently the combination of Searchlight cores and 
Horizon Cores.  With this change we would make a searchlight UI core group that 
can has core privileges in addition to those two groups.
 
[0] http://stackalytics.com/?metric=commits&module=searchlight-ui
[1] http://stackalytics.com/?module=horizon&metric=commits
[2] http://stackalytics.com/report/contribution/horizon/180
[3] http://stackalytics.com/report/contribution/searchlight-ui/180

Thanks,
Travis


__
OpenStack Development Mailing 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] [vote][kolla] deprecation for debian distro support

[Mauricio Lima]

Option 2

2016-09-19 14:55 GMT-03:00 Christian Berendt :

> Thanks for moving this forward.
>
> > On 19 Sep 2016, at 19:44, Jeffrey Zhang  wrote:
> >
> > Please vote:
> >
> > 1. Kolla needs support Debian( if so, we need some guys to set up the
> > gate and fix all the issues ASAP in O cycle)
> > 2. Kolla should deprecate Debian support
>
> +1 on option 2.
>
> __
> OpenStack Development Mailing 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] [vote][kolla] deprecation for fedora distro support

[Mauricio Lima]

Option 2

2016-09-19 14:56 GMT-03:00 Christian Berendt :

> Thanks for moving this forward.
>
> > On 19 Sep 2016, at 19:40, Jeffrey Zhang  wrote:
> >
> > 1. Kolla needs support fedora( if so, we need some guys to set up the
> > gate and fix all the issues ASAP in O cycle)
> > 2. Kolla should deprecate fedora support
>
> +1 on option 2.
>
> __
> OpenStack Development Mailing 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] [release][tripleo] tripleo Newton RC1 available

[Doug Hellmann]

Hello everyone,

The release candidate for tripleo for the end of the Newton cycle
is available!  You can find the RC1 source code tarballs at:

https://tarballs.openstack.org/instack-undercloud/instack-undercloud-5.0.0.0rc1.tar.gz
https://tarballs.openstack.org/puppet-tripleo/puppet-tripleo-5.1.0.tar.gz
https://tarballs.openstack.org/python-tripleoclient/python-tripleoclient-5.1.0.tar.gz
https://tarballs.openstack.org/tripleo-common/tripleo-common-5.1.0.tar.gz
https://tarballs.openstack.org/tripleo-heat-templates/tripleo-heat-templates-5.0.0.0rc1.tar.gz
https://tarballs.openstack.org/tripleo-image-elements/tripleo-image-elements-5.0.0.0rc1.tar.gz
https://tarballs.openstack.org/tripleo-puppet-elements/tripleo-puppet-elements-5.0.0.0rc1.tar.gz
https://tarballs.openstack.org/tripleo-ui/tripleo-ui-1.0.2.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final
Newton release on 6 October. You are therefore strongly
encouraged to test and validate this tarball!

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/tripleo/+filebug

and tag it *newton-rc-potential* to bring it to the tripleo release
crew's attention.

The stable/newton branches for these repositories will be created based
on later tags, so the "master" branch is not yet open for Ocata
development.

Thanks,
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] [requirements] Bump swiftclient to 3.1.0

[Julien Danjou]

On Mon, Sep 19 2016, Doug Hellmann wrote:

> We do not generally bump minimum versions for dependencies for bug
> fixes, especially for only one project. Does this validation bug affect
> other projects? Is python-swiftclient 2.2.0 (the current minimum)
> fundamentally broken for all projects?

It affects any project that uses retries=0 in swiftclient.

There's no need to bump the minimum requirement for all OpenStack, but
at least moving the uppercap.

-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


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] [Neutron] Adding ihrachys to the neutron-drivers team

[Brian Haley]

Congrats Ihar!

-Brian

On 09/17/2016 12:40 PM, Armando M. wrote:

Hi folks,

I would like to propose Ihar to become a member of the Neutron drivers team [1].

Ihar wide knowledge of the Neutron codebase, and his longstanding duties as
stable core, downstream package whisperer, release and oslo liaison (I am sure I
am forgetting some other capacity he is in) is going to put him at great comfort
in the newly appointed role, and help him grow and become wise even further.

Even though we have not been meeting regularly lately we will resume our
Thursday meetings soon [2], and having Ihar onboard by then will be highly
beneficial.

Please, join me in welcome Ihar to the team.

Cheers,
Armando

[1] 
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team

[2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers



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




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

Re: [openstack-dev] [cinder][sahara] LVM vs BDD drivers performance tests results

[Ivan Kolodyazhny]

+ [sahara] because they are primary consumer of the BDD.

John,
Thanks for the answer. My comments are inline.

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

On Mon, Sep 19, 2016 at 4:41 PM, John Griffith 
wrote:

>
>
> On Mon, Sep 19, 2016 at 4:43 AM, Ivan Kolodyazhny  wrote:
>
>> Hi team,
>>
>> We did some performance tests [1] for LVM and BDD drivers. All tests were
>> executed on real hardware with OpenStack Mitaka release. Unfortunately, we
>> didn't have enough time to execute all tests and compare results. We used
>> Sahara/Hadoop cluster with TestDFSIO and others tests.
>>
>> All tests were executed on the same hardware and OpenStack release. Only
>> difference were in cinder.conf to enable needed backend and/or target
>> driver.
>>
>> Tests were executed on following configurations:
>>
>>- LVM +TGT target
>>- LVM+LocalTarget: PoC based on [2] spec
>>- LVM+LIO
>>- Block Device Driver.
>>
>>
>> Feel free to ask question if any about our testing infrastructure,
>> environment, etc.
>>
>>
>> [1] https://docs.google.com/spreadsheets/d/1qS_ClylqdbtbrVSvwbbD
>> pdWNf2lZPR_ndtW6n54GJX0/edit?usp=sharing
>> [2] https://review.openstack.org/#/c/247880/
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> ​Thanks Ivan, so I'd like to propose we (the Cinder team) discuss a few
> things (again):
>
> 1. Deprecate the BDD driver
>  Based on the data here LVM+LIO the delta in performance ​(with the
> exception of the Terravalidate run against 3TB) doesn't seem significant
> enough to warrant maintaining an additional driver that has only a subset
> of features implemented.  It would be good to understand why that
> particular test has such a significant peformance gap.
>
What about Local Target? Does it make sense to implement it instead BDD?

>
> 2. Consider getting buy off to move the default implementation to use the
> LIO driver and consider deprecating the TGT driver
>
+1. Let's bring this topic for the next weekly meeting.



>
> I realize this probably isn't a sufficient enough data set to make those
> two decisions but I think it's at least enough to have a more informed
> discussion this time.
>
> Thanks,
> John​
>
>
> __
> OpenStack Development Mailing 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] [release][designate] designate Newton RC1 available

[Doug Hellmann]

Hello everyone,

The release candidate for designate for the end of the Newton cycle
is available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/designate/designate-3.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final
Newton release on 6 October. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/designate/log/?h=stable/newton

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/designate/+filebug

and tag it *newton-rc-potential* to bring it to the designate release
crew's attention.

Note that the "master" branch of designate is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,
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] [vote][kolla] deprecation for debian distro support

[Christian Berendt]

Thanks for moving this forward.

> On 19 Sep 2016, at 19:44, Jeffrey Zhang  wrote:
> 
> Please vote:
> 
> 1. Kolla needs support Debian( if so, we need some guys to set up the
> gate and fix all the issues ASAP in O cycle)
> 2. Kolla should deprecate Debian support

+1 on option 2.


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing 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] [searchlight] Matt Borland Searchlight UI Core Nomination

[McLellan, Steven]

+1 - I'm fine with an additional group for ui cores.

On 9/19/16, 12:13 PM, "Tripp, Travis S"  wrote:

>Hello!
> 
>I am nominating Matt Borland for Searchlight UI core. Matt has been
>working on searchlight UI since we started it and he is the primary
>author of the angular registration framework in Horizon which Searchlight
>depends upon. Matt has the second most searchlight UI commits in Newton
>[0], but more impressively, Matt has more commits on Horizon than ANY
>other person in Newton [1]. In addition, Matt is a top 5 reviewer on
>Searchlight UI [2] and a 12 reviewer on horizon [3] He has provided
>thoughtful feedback and valuable insights throughout his time on
>Searchlight.
>
>Searchlight UI core team is currently the combination of Searchlight
>cores and Horizon Cores.  With this change we would make a searchlight UI
>core group that can has core privileges in addition to those two groups.
> 
>[0] http://stackalytics.com/?metric=commits&module=searchlight-ui
>[1] http://stackalytics.com/?module=horizon&metric=commits
>[2] http://stackalytics.com/report/contribution/horizon/180
>[3] http://stackalytics.com/report/contribution/searchlight-ui/180
>
>Thanks,
>Travis
>
>
>__
>OpenStack Development Mailing 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] [vote][kolla] deprecation for fedora distro support

[Christian Berendt]

Thanks for moving this forward.

> On 19 Sep 2016, at 19:40, Jeffrey Zhang  wrote:
> 
> 1. Kolla needs support fedora( if so, we need some guys to set up the
> gate and fix all the issues ASAP in O cycle)
> 2. Kolla should deprecate fedora support

+1 on option 2.


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing 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][LBaaS v2]Quota Update for LBaaS v2 Members

[Michael Johnson]

Hi Reedip,

As you noted with the linked bug, we have noticed some inconsistencies
in the neutron-lbaas quota implementation as we are working on
implementing quotas native in the Octavia API.

The neutron-lbaas code does support a quota for members, but as you
have observed I don't see it in the API.

Can you submit a bug for this?

Michael


On Fri, Sep 16, 2016 at 2:35 AM, reedip banerjee  wrote:
> Hi All,
>
> Currently OpenstackClient and NeutronClient supports updating the quota for
> LBaaS v2 members.
> However, the quota API does not seem to support it.[1]
>
> I would just like to get this information cleared whether we actually allow
> updating the quotas for LBaaSv2 Members??
>
> [1]: https://bugs.launchpad.net/python-openstackclient/+bug/1624097
>
> --
> Thanks and Regards,
> Reedip Banerjee
> IRC: reedip
>
>
>
>
>
> __
> OpenStack Development Mailing 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] [vote][kolla] deprecation for fedora distro support

[Dave Walker]

On 19 September 2016 at 18:40, Jeffrey Zhang 
wrote:

> Kolla core reviewer team,
>
> Kolla supports multiple Linux distros now, including
>
> * Ubuntu
> * CentOS
> * RHEL
> * Fedora
> * Debian
> * OracleLinux
>
> But only Ubuntu, CentOS, and OracleLinux are widely used and we have
> robust gate to ensure the quality.
>
> For fedora, Kolla hasn't any test for it and nobody reports any bug
> about it( i.e. nobody use fedora as base distro image). We (kolla
> team) also do not have enough resources to support so many Linux
> distros. I prefer to deprecate fedora support now.  This is talked in
> past but inconclusive[0].
>
> Please vote:
>
> 1. Kolla needs support fedora( if so, we need some guys to set up the
> gate and fix all the issues ASAP in O cycle)
> 2. Kolla should deprecate fedora support
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-
> June/098526.html
>
>
>
+1

Honestly, only CentOS and Ubuntu are seriously implemented.. I'd go further
and rip out the rest unless there is a strong effort from people committed
to getting parity.

--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing 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] [vote][kolla] deprecation for debian distro support

[Jeffrey Zhang]

Kolla core reviewer team,

Kolla supports multiple Linux distros now, including

* Ubuntu
* CentOS
* RHEL
* Fedora
* Debian
* OracleLinux

But only Ubuntu, CentOS, and OracleLinux are widely used and we have
robust gate to ensure the quality.

For Debian, Kolla hasn't any test for it and nobody reports any bug
about it( i.e. nobody use Debian as base distro image). We (kolla
team) also do not have enough resources to support so many Linux
distros. I prefer to deprecate Debian support now.

Please vote:

1. Kolla needs support Debian( if so, we need some guys to set up the
gate and fix all the issues ASAP in O cycle)
2. Kolla should deprecate Debian support

Voting is open for 7 days until September 27st, 2016.

-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

__
OpenStack Development Mailing 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] [vote][kolla] deprecation for fedora distro support

[Jeffrey Zhang]

Voting is open for 7 days until September 27st, 2016.

On Tue, Sep 20, 2016 at 1:40 AM, Jeffrey Zhang  wrote:
> Kolla core reviewer team,
>
> Kolla supports multiple Linux distros now, including
>
> * Ubuntu
> * CentOS
> * RHEL
> * Fedora
> * Debian
> * OracleLinux
>
> But only Ubuntu, CentOS, and OracleLinux are widely used and we have
> robust gate to ensure the quality.
>
> For fedora, Kolla hasn't any test for it and nobody reports any bug
> about it( i.e. nobody use fedora as base distro image). We (kolla
> team) also do not have enough resources to support so many Linux
> distros. I prefer to deprecate fedora support now.  This is talked in
> past but inconclusive[0].
>
> Please vote:
>
> 1. Kolla needs support fedora( if so, we need some guys to set up the
> gate and fix all the issues ASAP in O cycle)
> 2. Kolla should deprecate fedora support
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-June/098526.html
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

__
OpenStack Development Mailing 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] [vote][kolla] deprecation for fedora distro support

[Jeffrey Zhang]

Kolla core reviewer team,

Kolla supports multiple Linux distros now, including

* Ubuntu
* CentOS
* RHEL
* Fedora
* Debian
* OracleLinux

But only Ubuntu, CentOS, and OracleLinux are widely used and we have
robust gate to ensure the quality.

For fedora, Kolla hasn't any test for it and nobody reports any bug
about it( i.e. nobody use fedora as base distro image). We (kolla
team) also do not have enough resources to support so many Linux
distros. I prefer to deprecate fedora support now.  This is talked in
past but inconclusive[0].

Please vote:

1. Kolla needs support fedora( if so, we need some guys to set up the
gate and fix all the issues ASAP in O cycle)
2. Kolla should deprecate fedora support

[0] http://lists.openstack.org/pipermail/openstack-dev/2016-June/098526.html


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

__
OpenStack Development Mailing 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] let's talk (development) environment deployment tooling and workflows

[Steven Hardy]

Hi Alex,

Firstly, thanks for this detailed feedback - it's very helpful to have
someone with a fresh perspective look at the day-1 experience for TripleO,
and while some of what follows are "know issues", it's great to get some
perspective on them, as well as ideas re how we might improve things.

On Thu, Sep 15, 2016 at 09:09:24AM -0600, Alex Schultz wrote:
> Hi all,
> 
> I've recently started looking at the various methods for deploying and
> developing tripleo.  What I would like to bring up is the current
> combination of the tooling for managing the VM instances and the
> actual deployment method to launch the undercloud/overcloud
> installation.  While running through the various methods and reading
> up on the documentation, I'm concerned that they are not currently
> flexible enough for a developer (or operator for that matter) to be
> able to setup the various environment configurations for testing
> deployments and doing development.  Additionally I ran into issues
> just trying get them working at all so this probably doesn't help when
> trying to attract new contributors as well.  The focus of this email
> and of my experience seems to relate with workflow-simplification
> spec[0].  I would like to share my experiences with the various
> tooling available and raise some ideas.
> 
> Example Situation:
> 
> For example, I have a laptop with 16G of RAM and an SSD and I'd like
> to get started with tripleo.  How can I deploy tripleo?

So, this is probably problem #1, because while I have managed to deploy a
minimal TripleO environment on a laptop with 16G of RAM, I think it's
pretty widely known that it's not really enough (certainly with our default
configuration, which has unfortunately grown over time as more and more
things got integrated).

I see two options here:

1. Document the reality (which is really you need a physical machine with
at least 32G RAM unless you're prepared to deal with swapping).

2. Look at providing a "TripleO lite" install option, which disables some
services (both on the undercloud and default overcloud install).

Either of these are defintely possible, but (2) seems like the best
long-term solution (although it probably means another CI job).

> Tools:
> 
> instack:
> 
> I started with the tripleo docs[1] that reference using the instack
> tools for virtual environment creation while deploying tripleo.   The
> docs say you need at least 12G of RAM[2].  The docs lie (step 7[3]).
> So after basically shutting everything down and letting it deploy with
> all my RAM, the deployment fails because the undercloud runs out of
> RAM and OOM killer kills off heat.  This was not because I had reduced
> the amount of ram for the undercloud node or anything.  It was because
> by default, 6GB of RAM with no swap is configured for the undercloud
> (not sure if this is a bug?).  So I added a swap file to the
> undercloud and continued. My next adventure was having the overcloud
> deployment fail because lack of memory as puppet fails trying to spawn
> a process and gets denied.  The instack method does not configure swap
> for the VMs that are deployed and the deployment did not work with 5GB
> RAM for each node.  So for a full 16GB I was unable to follow the
> documentation and use instack to successfully deploy.  At this point I
> switched over to trying to use tripleo-quickstart.  Eventually I was
> able to figure out a configuration with instack to get it to deploy
> when I figured out how to enable swap for the overcloud deployment.

Yeah, so this definitely exposes that we need to update the docs, and also
provide an easy install-time option to enable swap on all-the-things for
memory contrained environments.

> tripleo-quickstart:
> 
> The next thing I attempted to use was the tripleo-quickstart[4].
> Following the directions I attempted to deploy against my localhost.
> I turns out that doesn't work as expected since ansible likes to do
> magic when dealing with localhost[5].  Ultimately I was unable to get
> it working against my laptop locally because I ran into some libvirt
> issues.  But I was able to get it to work when I pointed it at a
> separate machine.  It should be noted that tripleo-quickstart creates
> an undercloud with swap which was nice because then it actually works,
> but is an inconsistent experience depending on which tool you used for
> your deployment.

Yeah, so while a lot of folks have good luck with tripleo-quickstart, it
has the disadvantage of not currently being the tool used in upstream
TripleO CI (which folks have looked at fixing, but it's not yet happened).

The original plan was for tripleo-quickstart to completely replace the
instack-virt-setup workflow:

https://blueprints.launchpad.net/tripleo/+spec/tripleo-quickstart

But for a variety of reasons, we never quite got to that - we may need a
summit discussion on the path forward here.

For me (as an upstream developer) it really boils down to the CI usage
issue - at all times I want to use

Re: [openstack-dev] [horizon] ListField in Horizon

[Timur Sufiev]

Hi, Janki

What do you mean by ListField? A list of arbitrary tags? List of numbers?
List of predefined values that you can choose from? Options may vary widely
depending on your particular needs.

On Sun, Sep 18, 2016 at 6:32 PM Janki Chhatbar  wrote:

> Hi
>
> I am working on a dashboard's panel that needs an input as a "list". I
> couldnot find any "ListField" (like CharFiled) in Horizon forms.
>
> Is there any other field type that takes input as a list or this needs to
> be developed?
>
> Any pointer would be appreciated.
>
> --
> Thanking you
>
> Janki Chhatbar
> OpenStack | Docker | SDN
> simplyexplainedblog.wordpress.com
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [searchlight] Matt Borland Searchlight UI Core Nomination

[Tripp, Travis S]

Hello!
 
I am nominating Matt Borland for Searchlight UI core. Matt has been working on 
searchlight UI since we started it and he is the primary author of the angular 
registration framework in Horizon which Searchlight depends upon. Matt has the 
second most searchlight UI commits in Newton [0], but more impressively, Matt 
has more commits on Horizon than ANY other person in Newton [1]. In addition, 
Matt is a top 5 reviewer on Searchlight UI [2] and a 12 reviewer on horizon [3] 
He has provided thoughtful feedback and valuable insights throughout his time 
on Searchlight.

Searchlight UI core team is currently the combination of Searchlight cores and 
Horizon Cores.  With this change we would make a searchlight UI core group that 
can has core privileges in addition to those two groups.
 
[0] http://stackalytics.com/?metric=commits&module=searchlight-ui
[1] http://stackalytics.com/?module=horizon&metric=commits
[2] http://stackalytics.com/report/contribution/horizon/180
[3] http://stackalytics.com/report/contribution/searchlight-ui/180

Thanks,
Travis


__
OpenStack Development Mailing 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] [horizon] ListField in Horizon

[Janki Chhatbar]

Hi Timur

Thanks for your response.

I need to input data like this:

mapping = ['K1': 'v1', 'k2': 'v2']
If mapping:
Check if v1 and v2 stored in server.
Change to dictionary

This is then passed on to the server as a dictionary.

I have few questions:
1. I found about MultipleChoiceField. This seems to do the job. Though not
sure.
2. Can a Dropdown list be created to select v1 and v2?

Looking forward for your opinion.

Thanks
Janki

On 19-Sep-2016 10:30 pm, "Timur Sufiev"  wrote:

> Hi, Janki
>
> What do you mean by ListField? A list of arbitrary tags? List of numbers?
> List of predefined values that you can choose from? Options may vary widely
> depending on your particular needs.
>
> On Sun, Sep 18, 2016 at 6:32 PM Janki Chhatbar 
> wrote:
>
>> Hi
>>
>> I am working on a dashboard's panel that needs an input as a "list". I
>> couldnot find any "ListField" (like CharFiled) in Horizon forms.
>>
>> Is there any other field type that takes input as a list or this needs to
>> be developed?
>>
>> Any pointer would be appreciated.
>>
>> --
>> Thanking you
>>
>> Janki Chhatbar
>> OpenStack | Docker | SDN
>> simplyexplainedblog.wordpress.com
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] Newton release, neutron-lib and decomposed projects

[Doug Hellmann]

Excerpts from Gary Kotton's message of 2016-09-18 05:16:54 +:
> Hi,
> At the moment I am a little confused and need some help please:
> 
> 1.   Will we be creating release candidates for Networking-l2gw, 
> Networking-sfc and Tap-as-a-service. These projects have tons of deprecation 
> warnings (dealt with by: https://review.openstack.org/368392, 
> https://review.openstack.org/368398, https://review.openstack.org/368400, 
> https://review.openstack.org/368403, https://review.openstack.org/369091, 
> https://review.openstack.org/369087 etc.)

Those projects are all following the release:independent model, so the
release management team has not been tracking them as part of the Newton
release.

> 
> 2.   Will we be cutting an official neutron-lib for the newton release 
> (or at least know that version X is the one that is being released). The 
> reason I ask this is that in Mitaka there was a period when we had a number 
> of versions in flight. Plugins or libraries that used constants from 
> neutron-lib 0.2.0 broke stable mitaka. More specifically stable/mitaka was 
> released with 0.1.0.

neutron-lib 0.4.0 was the last release before the library freeze date
and we created the stable/newton branch from it[1].

The best way to know which version of any dependency is being treated as
"current" is to look at the openstack/requirements/upper-constraints.txt
file to see what version is listed.

Doug

[1] https://releases.openstack.org/newton/index.html#neutron-lib

__
OpenStack Development Mailing 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] [user-committee][scientific-wg][api][UX] Results Presentation: Managing OpenStack Quotas within Production Environments

[Danielle Mundle]

(Apologies for cross-posting)

The OpenStack UX team will be giving a presentation this Wednesday, 9/21
that summarizes results from a series of interviews intended to understand
how operators manage quotas at scale as well as the pain points associated
with that process.

The study was conducted by Danielle Mundle (IRC: uxdanielle) and included
operators from CERN, Pacific Northwest National Laboratory, Workday, Intel
and Universidade Federal de Campina Grande and others.

The presentation details can be found at the top of the OpenStack UX wiki:

https://wiki.openstack.org/wiki/UX
__
OpenStack Development Mailing 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] Useful tool for easier viewing of IRC logs online

[Asselin, Ramy]

Very nice, thanks!
Only change I'll suggest is to allow it to be enabled by default :)
Ramy

From: Bashmakov, Alexander [mailto:alexander.bashma...@intel.com]
Sent: Friday, September 16, 2016 2:26 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [all] Useful tool for easier viewing of IRC logs online

Hello Stackers,

If you ever find yourself needing to peruse OpenStack IRC logs online 
(http://eavesdrop.openstack.org/irclogs/) and if you use the Chrome browser to 
do it, then the following tool may come in handy:

https://chrome.google.com/webstore/detail/openstack-eavesdrop-irc-f/lcmadadicbflcamibnpplpgdcdahkade

It's a simple extension to filter messages of the type: " has quit" and 
" has joined", which makes the log much more compact and readable.

Source code is here: https://github.com/abashmak/chrome-irc-filter

Comments, suggestions are welcome.
__
OpenStack Development Mailing 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] Bump swiftclient to 3.1.0

[Matthew Thode]

On 09/19/2016 11:31 AM, Julien Danjou wrote:
> Hi,
> 
> I've sent a request to bump swiftclient to 3.1.0 for Newton, and IIRC
> this repository might be frozen so I'm sending this mail to bring
> attention.
> 
>   https://review.openstack.org/#/c/372618/

Is this an FFE for that?
This would basically require a re-release (RC2) for all the projects at
this point.

http://codesearch.openstack.org/?q=swiftclient&i=nope&files=requirements.txt&repos=

-- 
-- Matthew Thode (prometheanfire)



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

Re: [openstack-dev] [Product] Project Navigator - Maturity Metrics

[Jimmy McArthur]

Shamail 
September 19, 2016 at 11:32 AM

On Sep 19, 2016, at 12:22 PM, Jimmy McArthur  wrote:

Gordon,

Thanks for brining this to our attention. We pull data from many different sources for the 
Navigator. Most of the attributions for that data can be found under "Tag Details" or 
various "?" modal links on the page. For PTLs, we grab that data from the following: 
https://raw.githubusercontent.com/openstack/governance/master/reference/projects.yaml. All data is 
pulled using a nightly cronjob.

However, it appears there is an error in the yaml that's preventing the data 
from being pulled. We're working to resolve the problem now. I'd like to 
suggest the following to prevent this moving forward:

* Add an email alert to the cronjob that pulls data. In the event of an error, 
send an alert to myself, Thierry Carez and Tom Fifeld to let us know if the 
ingest process fails

+1 (feel free to add me as well)

* Change "PTL for Latest Release" to "Current PTL", to avoid confusion

+1, great idea (also removes the reference to releases which could be different 
things to independent release projects)

* Add IRC-Channel of project and IRC handle of PTL to help users get to the 
right spot

Where will you pull this information from or will we manually add it? If we add 
IRC information then we should also add the info as a web client link.
IRC info is available in the same file 
(https://raw.githubusercontent.com/openstack/governance/master/reference/projects.yaml). 


Thanks!
Jimmy McArthur

is this updated with a script or manually? i just took a quick look at
this and some of the projects have a different information between the
high-level "all projects" view and the detailed individual project view.
this was something that was brought up a months ago so i assume it
hasn't been looked at in a while.

for example, i'm not a PTL but it says i am one.



__
OpenStack Development Mailing 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
Jimmy McArthur 
September 19, 2016 at 11:22 AM
Gordon,

Thanks for brining this to our attention. We pull data from many 
different sources for the Navigator. Most of the attributions for that 
data can be found under "Tag Details" or various "?" modal links on 
the page. For PTLs, we grab that data from the following: 
https://raw.githubusercontent.com/openstack/governance/master/reference/projects.yaml. 
All data is pulled using a nightly cronjob.


However, it appears there is an error in the yaml that's preventing 
the data from being pulled. We're working to resolve the problem now. 
I'd like to suggest the following to prevent this moving forward:


* Add an email alert to the cronjob that pulls data. In the event of 
an error, send an alert to myself, Thierry Carez and Tom Fifeld to let 
us know if the ingest process fails

* Change "PTL for Latest Release" to "Current PTL", to avoid confusion
* Add IRC-Channel of project and IRC handle of PTL to help users get 
to the right spot


Thanks!
Jimmy McArthur

is this updated with a script or manually? i just took a quick look at
this and some of the projects have a different information between the
high-level "all projects" view and the detailed individual project view.
this was something that was brought up a months ago so i assume it
hasn't been looked at in a while.

for example, i'm not a PTL but it says i am one.




__
OpenStack Development Mailing 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] Bump swiftclient to 3.1.0

[Doug Hellmann]

Excerpts from Julien Danjou's message of 2016-09-19 18:31:51 +0200:
> Hi,
> 
> I've sent a request to bump swiftclient to 3.1.0 for Newton, and IIRC
> this repository might be frozen so I'm sending this mail to bring
> attention.
> 
>   https://review.openstack.org/#/c/372618/
> 
> Cheers,

We do not generally bump minimum versions for dependencies for bug
fixes, especially for only one project. Does this validation bug affect
other projects? Is python-swiftclient 2.2.0 (the current minimum)
fundamentally broken for all projects?

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][congress][searchlight] projects in danger of being left out of newton

[Doug Hellmann]

Excerpts from Tim Hinrichs's message of 2016-09-19 15:46:47 +:
> Congress tagged RC1 on Friday.

Yep, we missed a manual step of the process and didn't record that.
Sorry for the confusion.

Doug

> 
> Tim
> 
> On Mon, Sep 19, 2016 at 7:52 AM Nikhil Komawar 
> wrote:
> 
> > I think searchlight went right ahead into 1.0.0 so, I doubt if we will
> > have rc1. (this is just initial info, I will defer the details to the
> > project lead).
> >
> >
> >
> > On 9/19/16 9:55 AM, Doug Hellmann wrote:
> > > We have not had RC1 tags for congress or searchlight, and the project
> > > leads aren't responding on IRC. These projects are at risk of being
> > > left out of the newton release. Someone from the core teams for
> > > these projects should get in touch with the release team as soon
> > > as possible to let us know your plans.
> > >
> > > 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
> >
> > --
> >
> > Thanks,
> > Nikhil
> >
> >
> > __
> > OpenStack Development Mailing 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] [Product] Project Navigator - Maturity Metrics

[Shamail]

> On Sep 19, 2016, at 12:22 PM, Jimmy McArthur  wrote:
> 
> Gordon,
> 
> Thanks for brining this to our attention. We pull data from many different 
> sources for the Navigator. Most of the attributions for that data can be 
> found under "Tag Details" or various "?" modal links on the page. For PTLs, 
> we grab that data from the following: 
> https://raw.githubusercontent.com/openstack/governance/master/reference/projects.yaml.
>  All data is pulled using a nightly cronjob.
> 
> However, it appears there is an error in the yaml that's preventing the data 
> from being pulled. We're working to resolve the problem now. I'd like to 
> suggest the following to prevent this moving forward:
> 
> * Add an email alert to the cronjob that pulls data. In the event of an 
> error, send an alert to myself, Thierry Carez and Tom Fifeld to let us know 
> if the ingest process fails
+1 (feel free to add me as well)
> * Change "PTL for Latest Release" to "Current PTL", to avoid confusion
+1, great idea (also removes the reference to releases which could be different 
things to independent release projects)
> * Add IRC-Channel of project and IRC handle of PTL to help users get to the 
> right spot
Where will you pull this information from or will we manually add it? If we add 
IRC information then we should also add the info as a web client link.
> 
> Thanks!
> Jimmy McArthur
> 
> is this updated with a script or manually? i just took a quick look at
> this and some of the projects have a different information between the
> high-level "all projects" view and the detailed individual project view.
> this was something that was brought up a months ago so i assume it
> hasn't been looked at in a while.
> 
> for example, i'm not a PTL but it says i am one.
> 
> 
> 
> __
> OpenStack Development Mailing 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] [requirements] Bump swiftclient to 3.1.0

[Julien Danjou]

Hi,

I've sent a request to bump swiftclient to 3.1.0 for Newton, and IIRC
this repository might be frozen so I'm sending this mail to bring
attention.

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

Cheers,
-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


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] [tc]a chance to meet all TCs for Tricircle big-tent application in Barcelona summit?

[Shinobu Kinjo]

On Mon, Sep 19, 2016 at 6:22 PM, joehuang  wrote:
> Hello, all TCs,
>
> Understand that you will be quite busy in Barcelona summit, all TCs will be
> shown in the Barcelona summit, and meet together(usually, I assumed). So is
> it possible to have a chance to meet all TCs there for Tricircle big-tent
> application https://review.openstack.org/#/c/338796/ ? F2f talk to answer
> the concerns may help the understanding and decision.
>
> The splitting and cleaning of Tricircle hopefully could be finished before
> Barcelona summit.
>
> Although Tricircle splitting and cleaning is WIP, some draft materials were
> prepared for the understanding on Tricircle and  open comments, contribution
> etc:
>
> 1. Tricircle focuses on networking automation across
> Neutron:https://docs.google.com/presentation/d/1Zkoi4vMOGN713Vv_YO0GP6YLyjLpQ7fRbHlirpq6ZK4/
>
> 2. Tricircle design blueprint
> update:https://docs.google.com/document/d/1zcxwl8xMEpxVCqLTce2-dUOtB-ObmzJTbV1uSQ6qTsY/
>
> 3. Tricircle wiki update: https://wiki.openstack.org/wiki/Tricircle
>
> (Caution: the git repo. of Tricircle will be purified, nova_apigw and
> cinder_apigw will be removed from the repo. soon
> https://github.com/openstack/tricircle/ , the description will also be
> updated)

Just removing 2 functionality from repo probably would be fine.

But what you should clarify more is:

  - How we should take care of existing commitments for those 2 functionality.
   Some people still have been making patches for them.

And what I'm really confused with is that, even you're telling that we
will have removed those two from repo, you're still talking about
those two in different thread with no clarification.

That should be stopped now, if we will really go with what you
proposed above. Probably it's better not to say Tricircle any more to
avoid any confusion.

You should make a progress more *carefully* because project is being
changed with contributors who have been submitting patches eve now.

Regards,
Shinobu

>
> 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
>



-- 
Email:
shin...@linux.com
shin...@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

[openstack-dev] [Product] Project Navigator - Maturity Metrics

[Jimmy McArthur]

Gordon,

Thanks for brining this to our attention. We pull data from many 
different sources for the Navigator. Most of the attributions for that 
data can be found under "Tag Details" or various "?" modal links on the 
page. For PTLs, we grab that data from the following: 
https://raw.githubusercontent.com/openstack/governance/master/reference/projects.yaml. 
All data is pulled using a nightly cronjob.


However, it appears there is an error in the yaml that's preventing the 
data from being pulled. We're working to resolve the problem now. I'd 
like to suggest the following to prevent this moving forward:


* Add an email alert to the cronjob that pulls data. In the event of an 
error, send an alert to myself, Thierry Carez and Tom Fifeld to let us 
know if the ingest process fails

* Change "PTL for Latest Release" to "Current PTL", to avoid confusion
* Add IRC-Channel of project and IRC handle of PTL to help users get to 
the right spot


Thanks!
Jimmy McArthur

is this updated with a script or manually? i just took a quick look at
this and some of the projects have a different information between the
high-level "all projects" view and the detailed individual project view.
this was something that was brought up a months ago so i assume it
hasn't been looked at in a while.

for example, i'm not a PTL but it says i am one.



__
OpenStack Development Mailing 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] Adding ihrachys to the neutron-drivers team

[Vasudevan, Swaminathan (PNB Roseville)]

Congrats! Ihar.

From: Armando M. [mailto:arma...@gmail.com]
Sent: Saturday, September 17, 2016 9:41 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers team

Hi folks,

I would like to propose Ihar to become a member of the Neutron drivers team [1].

Ihar wide knowledge of the Neutron codebase, and his longstanding duties as 
stable core, downstream package whisperer, release and oslo liaison (I am sure 
I am forgetting some other capacity he is in) is going to put him at great 
comfort in the newly appointed role, and help him grow and become wise even 
further.

Even though we have not been meeting regularly lately we will resume our 
Thursday meetings soon [2], and having Ihar onboard by then will be highly 
beneficial.

Please, join me in welcome Ihar to the team.

Cheers,
Armando

[1] 
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
[2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
__
OpenStack Development Mailing 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] Adding ihrachys to theneutron-drivers team

[Nate Johnston]

I made the same assumption!  Congrats Ihar!

--N.

On Mon, Sep 19, 2016 at 12:33:06PM +, John Davidge wrote:
> Honestly, I had assumed Ihar was on the Drivers team already :)
> 
> A great addition to the team, and much deserved!
> 
> From: Paul Michali mailto:p...@michali.net>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> mailto:openstack-dev@lists.openstack.org>>
> Date: Monday, September 19, 2016 at 11:20 AM
> To: "OpenStack Development Mailing List (not for usage questions)" 
> mailto:openstack-dev@lists.openstack.org>>
> Subject: Re: [openstack-dev] [Neutron] Adding ihrachys to theneutron-drivers 
> team
> 
> Congratulations Ihar! Great addition to the Drivers team.
> 
> On Mon, Sep 19, 2016 at 4:52 AM Vikram Choudhary 
> mailto:vikram.choudh...@huawei.com>> wrote:
> Congrats Ihar!
> 
> From: reedip banerjee [mailto:reedi...@gmail.com]
> Sent: 19 September 2016 14:08
> 
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron] Adding ihrachys to theneutron-drivers 
> team
> 
> Congratulations Ihar :)
> 
> On Mon, Sep 19, 2016 at 2:00 PM, Martin Hickey 
> mailto:martin.hic...@ie.ibm.com>> wrote:
> 
> I totally agree. Congrats Ihar.
> 
> Regards,
> Martin
> -
> Martin Hickey | Software Development | Open Technologies | Tel: + 353 21 
> 7306040
> 
> [Inactive hide details for Assaf Muller ---17/09/2016 23:12:03---Well 
> deserved is an understatement! Ihar is consistently integr]Assaf Muller 
> ---17/09/2016 23:12:03---Well deserved is an understatement! Ihar is 
> consistently integral to the Neutron project. Ihar has w
> 
> From: Assaf Muller mailto:as...@redhat.com>>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> mailto:openstack-dev@lists.openstack.org>>
> Date: 17/09/2016 23:12
> Subject: Re: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers 
> team
> 
> 
> 
> 
> 
> Well deserved is an understatement! Ihar is consistently integral to
> the Neutron project. Ihar has wide knowledge not only of Neutron but
> of OpenStack workings and is a key factor to Neutron playing nice with
> other projects. Ihar has shown consistent good judgement of priorities
> and will in no doubt strengthen the drivers team.
> 
> On Sat, Sep 17, 2016 at 1:19 PM, Dariusz Śmigiel
> mailto:smigiel.dari...@gmail.com>> wrote:
> > Congrats Ihar. You deserve this!
> >
> > 2016-09-17 18:40 GMT+02:00 Armando M. 
> > mailto:arma...@gmail.com>>:
> >> Hi folks,
> >>
> >> I would like to propose Ihar to become a member of the Neutron drivers team
> >> [1].
> >>
> >> Ihar wide knowledge of the Neutron codebase, and his longstanding duties as
> >> stable core, downstream package whisperer, release and oslo liaison (I am
> >> sure I am forgetting some other capacity he is in) is going to put him at
> >> great comfort in the newly appointed role, and help him grow and become 
> >> wise
> >> even further.
> >>
> >> Even though we have not been meeting regularly lately we will resume our
> >> Thursday meetings soon [2], and having Ihar onboard by then will be highly
> >> beneficial.
> >>
> >> Please, join me in welcome Ihar to the team.
> >>
> >> Cheers,
> >> Armando
> >>
> >> [1]
> >> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
> >> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
> >>
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: 
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> > --
> > Darek "dasm" Śmigiel
> >
> > 
> > Q: Why is this email five sentences or less?
> > A: http://five.sentenc.es
> >
> > __
> > OpenStack Development Mailing 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

[openstack-dev] [cinder][nova] API interactions meeting

[Ildiko Vancsa]

Hi All,

This is a friendly reminder that the next meeting of our series is in less than 
50 minutes, at 1700UTC on #openstack-meeting-cp.

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

Re: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers team

[Das, Anindita]

Congratulations Ihar !!

From: "Armando M." 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Saturday, September 17, 2016 at 11:40 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers team

Hi folks,

I would like to propose Ihar to become a member of the Neutron drivers team [1].

Ihar wide knowledge of the Neutron codebase, and his longstanding duties as 
stable core, downstream package whisperer, release and oslo liaison (I am sure 
I am forgetting some other capacity he is in) is going to put him at great 
comfort in the newly appointed role, and help him grow and become wise even 
further.

Even though we have not been meeting regularly lately we will resume our 
Thursday meetings soon [2], and having Ihar onboard by then will be highly 
beneficial.

Please, join me in welcome Ihar to the team.

Cheers,
Armando

[1] 
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
[2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
__
OpenStack Development Mailing 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][congress][searchlight] projects in danger of being left out of newton

[Tim Hinrichs]

Congress tagged RC1 on Friday.

Tim

On Mon, Sep 19, 2016 at 7:52 AM Nikhil Komawar 
wrote:

> I think searchlight went right ahead into 1.0.0 so, I doubt if we will
> have rc1. (this is just initial info, I will defer the details to the
> project lead).
>
>
>
> On 9/19/16 9:55 AM, Doug Hellmann wrote:
> > We have not had RC1 tags for congress or searchlight, and the project
> > leads aren't responding on IRC. These projects are at risk of being
> > left out of the newton release. Someone from the core teams for
> > these projects should get in touch with the release team as soon
> > as possible to let us know your plans.
> >
> > 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
>
> --
>
> Thanks,
> Nikhil
>
>
> __
> OpenStack Development Mailing 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] Announcing firehose.openstack.org

[Thierry Carrez]

Matthew Treinish wrote:
> I wanted to announce the addition of a new infra service we started running
> recently, the firehose. Running at firehose.openstack.org the firehose is an
> MQTT based unified message bus for infra services. [...]

Awesome work!
Now I just need to find a good excuse to play with that one.

-- 
Thierry Carrez (ttx)



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

[openstack-dev] [release][watcher] watcher Newton RC1 available

[Antoine Cabot]

Hello everyone,

The release candidate for Watcher for the end of the Newton cycle
is available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/watcher/python-watcher-0.30.0.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final
Newton release on 6 October. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/watcher/log/?h=stable/newton

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/watcher/+filebug

and tag it *newton-rc-potential* to bring it to the watcher release
crew's attention.

Note that the "master" branch of watcher is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,

Antoine

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

[openstack-dev] [api] API Usability study at Barcelona Summit

[Kruithof Jr, Pieter]

Hi Folks,

I was planning to run a usability study on behalf of the API working group at 
the Barcelona summit. The plan is to have operators complete a set of 
common tasks, such as adjusting quotas, using the projects APIs.

Chris,

Were you still able to act as my contact?  I’ve created an etherpad to begin 
planning the study:

https://etherpad.openstack.org/p/osux-api-oct2016

Thanks,

Piet





--
Piet Kruithof
Sr User Experience Architect, Intel OTC
PTL, OpenStack UX Project

Mobile: 512 576-2844
IRC: piet
__
OpenStack Development Mailing 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] Barcelona Design Summit track layout

[Thierry Carrez]

Vitaly Gridnev wrote:
> As we discussed during the last meeting, we agreed that 6wr + cm is
> absolutely enough for sahara. So, we can release one working room for
> other projects (for example Wed, 3:05 to 3:45) 

OK done! Thanks.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all] Barcelona Design Summit track layout

[Thierry Carrez]

Emilien Macchi wrote:
> On Mon, Sep 19, 2016 at 3:18 AM, Antoine Cabot  
> wrote:
>> On Sun, Sep 18, 2016 at 3:59 PM, Thierry Carrez  
>> wrote:
>>> Emilien Macchi wrote:
 On Fri, Sep 16, 2016 at 10:22 AM, Thierry Carrez  
 wrote:
> 1. If you have a *hard* conflict that I failed to take into account
> (like the PTL is giving a talk during the one and only fishbowl room the
> team has), let me know and I'll try to find someone you could swap with.

 I'll give a talk on Thu 27  9:50am-10:30am but in same time there is a
 Puppet design session.
 Maybe could we move this Puppet session to another slot (my only
 constraint is to attend also all TripleO sessions).
 I hope we can arrange something :-)
>>>
>>> Argh! I spotted your talk but somehow failed to spot the conflict.
>>>
>>> I think the simpler would be to swap the Puppet workroom at 9:50am with
>>> the Watcher workroom at 11:50am. Antoine: would that work for you ?
>>
>> It works for me.
> 
> Thanks Antoine and all Watcher team :-)
> And of course Thierry for your flexibility on this one.

No problem! I swapped the slots on the schedule.
Cheers,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [release][congress][searchlight] projects in danger of being left out of newton

[Nikhil Komawar]

I think searchlight went right ahead into 1.0.0 so, I doubt if we will
have rc1. (this is just initial info, I will defer the details to the
project lead).



On 9/19/16 9:55 AM, Doug Hellmann wrote:
> We have not had RC1 tags for congress or searchlight, and the project
> leads aren't responding on IRC. These projects are at risk of being
> left out of the newton release. Someone from the core teams for
> these projects should get in touch with the release team as soon
> as possible to let us know your plans.
>
> 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

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing 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] Announcing firehose.openstack.org

[Matthew Treinish]

Hi Everyone,

I wanted to announce the addition of a new infra service we started running
recently, the firehose. Running at firehose.openstack.org the firehose is an
MQTT based unified message bus for infra services. The concept behind is it that
there are a lot of infra services many of which emit events, however there
wasn't a single place to go to for anything. If you have a script or tool which
is listening for events from an infra service, or has a poll loop (like anything
using gerritlib) there is now a single place to go for consuming those messages.
We also have 2 interfaces to subscribe to topics on the firehose, either via the
MQTT protocol on the default port or via a websockets over port 80. The 
websocket
interface should enable easier consumption for people on networks with stricter
firewalls.

Right now the only things sending messages into the firehose is the gerrit event
stream (via germqtt) and launchpad bug events (via lpmqtt) but several other
efforts are in progress to add additional services to the firehose. The plan is
to expand what publishes events to include all the infra services. This way
there is a single location for anything that needs to consume events.

There is also an example on the consuming side with gerritbot, which now has 
support for subscribing to the gerrit event stream over MQTT. You can see the
patch here:

http://git.openstack.org/cgit/openstack-infra/gerritbot/commit/?id=7c6e57983d499b16b3fabb864cf3bd5cfea8ab63

For those interested the spec detailing all the pieces is here:

http://specs.openstack.org/openstack-infra/infra-specs/specs/firehose.html

and the docs are available here:

http://docs.openstack.org/infra/system-config/firehose.html

which contain details on how the services are setup and includes some basic
steps and examples on how to start consuming events from the firehose.

Thanks,

Matt Treinish


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

Re: [openstack-dev] [TripleO] *ExtraConfig, backwards compatibility & deprecation

[Giulio Fidente]

On 09/19/2016 01:25 PM, Steven Hardy wrote:

On Wed, Sep 14, 2016 at 06:32:07PM +0200, Giulio Fidente wrote:

On 09/14/2016 05:59 PM, Giulio Fidente wrote:

On 09/14/2016 02:31 PM, Steven Hardy wrote:

Related to this is the future of all of the per-role customization
interfaces.  I'm thinking these don't really make sense to maintain
long-term now we have the new composable services architecture, and it
would be better if we can deprecate them and move folks towards the
composable services templates instead?


my experience is that the ExtraConfig interfaces have been useful to
provide arbitrary hiera and class includes

I wonder if we could ship by default some roles parsing those parameters?


thinking more about it, the *ExtraConfig interfaces also offer a simple
mechanism to *override* any hiera setting we push via the templates ...
which isn't easy to achieve with roles

a simple short-term solution could be to merge ExtraConfig in the $role
mapped_data, thoughts?


Thanks for the feedback, so yeah I agree there are reasons to keep the
ExtraConfig *parameters* around, or some similar interface.

I probably should have clarified this in my original post, but there are
two types of *ExtraConfig interfaces, the parameters you refer to, which
simply override some hieradata (we probably want to keep this, but it still
means we have ExtraConfig tied the the role (not the service), but
presumably an operator will know what services are deployed on what role).

The second (and more problematic from a containers point of view) is the
ExtraConfig *resources*, where you can pass an arbitrary heat template,
which typically is used to run stuff on the host (which will be impossible,
or at least not useful on an atomic host in a fully containerized
deployment).

I think your concerns are mostly around the ExtraConfig *parameters* thus,
provided we maintain some way to do those hiera overrides, e.g the
documented interfaces for Ceph ExtraConfig can still be used?


hi Steve

ack, my concern is about the way to do hiera overrides and the way to 
push additional hiera data for a service


maybe the latter can be implemented with a custom role but that seems 
overkilling where the need could be just to push some additional hiera 
data for a class; also a custom role would not work nicely to override 
hiera settings


as an alternative, we could add a $serviceExtraConfig parameter to every 
service and merge it with the heat output; this would work nicely with 
containers as well but add some boilerplate code


not sure if there are other ideas?
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente

__
OpenStack Development Mailing 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] Adding ihrachys to the neutron-drivers team

[Henry Fourie]

+1

From: Armando M. [mailto:arma...@gmail.com]
Sent: Saturday, September 17, 2016 9:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers team

Hi folks,

I would like to propose Ihar to become a member of the Neutron drivers team [1].

Ihar wide knowledge of the Neutron codebase, and his longstanding duties as 
stable core, downstream package whisperer, release and oslo liaison (I am sure 
I am forgetting some other capacity he is in) is going to put him at great 
comfort in the newly appointed role, and help him grow and become wise even 
further.

Even though we have not been meeting regularly lately we will resume our 
Thursday meetings soon [2], and having Ihar onboard by then will be highly 
beneficial.

Please, join me in welcome Ihar to the team.

Cheers,
Armando

[1] 
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
[2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
__
OpenStack Development Mailing 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][congress][searchlight] projects in danger of being left out of newton

[Doug Hellmann]

We have not had RC1 tags for congress or searchlight, and the project
leads aren't responding on IRC. These projects are at risk of being
left out of the newton release. Someone from the core teams for
these projects should get in touch with the release team as soon
as possible to let us know your plans.

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] [kolla][release] Branching of stable/newton

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2016-09-18 16:08:04 +0200:
> Steven Dake (stdake) wrote:
> > Release team,
> > 
> > At one point Doug had indicated all projects would automatically branch
> > on tagging of rc1.  I notice in git no Kolla stable/newton branch
> > exists. Fwiw this is actually a good thing, because 33 patches have
> > merged since rc1 relating to things that need to go into Newton,
> > dramatically reducing the amount of backport work we need to do.  Part
> > of this was error on my part – not validating all FFE blueprints that
> > were marked Implemented were actually implemented.  One related to
> > monitoring (and part of the 33 patches since rc1) was actually “Needs
> > Review” rather than Implemented (as it was marked).
> > 
> > I don’t want Kolla to be a special snowflake wrt release processes, and
> > we can live with a branch on rc1.  A branch on rc2 would be far better
> > for us as we have roughly 250 bugs to triage or fix.  I leave it in the
> > release team’s capable judgement to decide best on a course of action.
> 
> I'm probably the one to blame for that. Kolla follows milestones but is
> trailing the release, which makes it a bit of a release snowflake. I
> wasn't sure we should cut the stable branch at RC1 for such a case
> (since you're still far away from final).
> 
> We should discuss what to do here (branch ASAP, branch at RC2...) on
> Monday on the release channel when Doug is around.

As we discussed on IRC today, it seems reasonable to give the trailing
projects a bit more flexibility when we get to the RC period. Let us
know which RC should form the basis of the branch and we'll create it
then.

Doug

> 
> > I would request that the expected time of branch be communicated clearly
> > to us for the Newton cycle.  I have been communicating with our team
> > that rc1 is where we branch.  Folks are now asking “where is the Newton
> > branch of Kolla?”
> 
> FWIW Doug has been working on a spec so that projects communicate more
> clearly when they want the release branch to be cut. For
> milestone-driven projects it's usually clear (we branch at RC1), but for
> other cases (intermediary-released, trailing) options are a bit more
> open so having a way (through the openstack/releases repo) to clearly
> communicate "when" will definitely help.
> 

__
OpenStack Development Mailing 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] Adding ihrachys to the neutron-drivers team

[Morales, Victor]

This achievement reflects the constant effort you makes in OpenStack, kudos Ihar

From: "Armando M."
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Saturday, September 17, 2016 at 11:40 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers team

Hi folks,

I would like to propose Ihar to become a member of the Neutron drivers team [1].

Ihar wide knowledge of the Neutron codebase, and his longstanding duties as 
stable core, downstream package whisperer, release and oslo liaison (I am sure 
I am forgetting some other capacity he is in) is going to put him at great 
comfort in the newly appointed role, and help him grow and become wise even 
further.

Even though we have not been meeting regularly lately we will resume our 
Thursday meetings soon [2], and having Ihar onboard by then will be highly 
beneficial.

Please, join me in welcome Ihar to the team.

Cheers,
Armando

[1] 
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
[2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] LVM vs BDD drivers performance tests results

[John Griffith]

On Mon, Sep 19, 2016 at 4:43 AM, Ivan Kolodyazhny  wrote:

> Hi team,
>
> We did some performance tests [1] for LVM and BDD drivers. All tests were
> executed on real hardware with OpenStack Mitaka release. Unfortunately, we
> didn't have enough time to execute all tests and compare results. We used
> Sahara/Hadoop cluster with TestDFSIO and others tests.
>
> All tests were executed on the same hardware and OpenStack release. Only
> difference were in cinder.conf to enable needed backend and/or target
> driver.
>
> Tests were executed on following configurations:
>
>- LVM +TGT target
>- LVM+LocalTarget: PoC based on [2] spec
>- LVM+LIO
>- Block Device Driver.
>
>
> Feel free to ask question if any about our testing infrastructure,
> environment, etc.
>
>
> [1] https://docs.google.com/spreadsheets/d/1qS_
> ClylqdbtbrVSvwbbDpdWNf2lZPR_ndtW6n54GJX0/edit?usp=sharing
> [2] https://review.openstack.org/#/c/247880/
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ​Thanks Ivan, so I'd like to propose we (the Cinder team) discuss a few
things (again):

1. Deprecate the BDD driver
 Based on the data here LVM+LIO the delta in performance ​(with the
exception of the Terravalidate run against 3TB) doesn't seem significant
enough to warrant maintaining an additional driver that has only a subset
of features implemented.  It would be good to understand why that
particular test has such a significant peformance gap.

2. Consider getting buy off to move the default implementation to use the
LIO driver and consider deprecating the TGT driver

I realize this probably isn't a sufficient enough data set to make those
two decisions but I think it's at least enough to have a more informed
discussion this time.

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

Re: [openstack-dev] [cinder]tempest test case for force detach volume

[Duncan Thomas]

Writing a sensible test for this api is rather tricky, since it is intended
to clean up one very specific error condition, and has few guarantees about
the state it leaves the system in. It is provided as a tool to allow the
system administrator to clean up certain faults and situations without
needing to manually effort the database, however the conditions under which
it is safe to use, and the cleanup actions that are required after calling
it, vary between backends.

The only test I can think of that is  probably safe across all backends is
to call reserve, create_export, reset then delete. (All directly against
the cinder endpoint with no Nova involvement).

There is a substantial danger in the thinking that this call is any sort of
generic fixup - it will happily leave volumes attached behind the scenes,
open to data corruption.

On 18 Sep 2016 05:48, "joehuang"  wrote:

> Hello, Ken,
>
> Thank you for your information, for APIs without tempest test cases,
> it's due to hard to build the test environment, or it's just for the API
> is not mature enough? I want to know why the tempest test cases
> were not added at the same time when the features were implemented.
>
> Best Regards
> Chaoyi Huang(joehuang)
> 
> From: Ken'ichi Ohmichi [ken1ohmi...@gmail.com]
> Sent: 15 September 2016 2:02
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [cinder]tempest test case for force detach
> volume
>
> Hi Chaoyi,
>
> That is a nice point.
> Now Tempest have tests for some volume v2 action APIs which doesn't
> contain os-force_detach.
> The available APIs of tempest are two: os-set_image_metadata and
> os-unset_image_metadata like
> https://github.com/openstack/tempest/blob/master/tempest/
> services/volume/v2/json/volumes_client.py#L27
> That is less than I expected by comparing the API reference.
>
> The corresponding API tests' patches are welcome if interested in :-)
>
> Thanks
> Ken Ohmichi
>
> ---
>
>
> 2016-09-13 17:58 GMT-07:00 joehuang :
> > Hello,
> >
> > Is there ant tempest test case for "os-force_detach" action to force
> detach
> > a volume? I didn't find such a test case both in the repository
> > https://github.com/openstack/cinder/tree/master/cinder/tests/tempest
> > and https://github.com/openstack/tempest
> >
> > The API link is:
> > http://developer.openstack.org/api-ref-blockstorage-v2.
> html#forcedetachVolume
> >
> > 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 Development Mailing 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] [tricircle] Should we discuss the use cases of force volume detach in the Tricircle

[D'Angelo, Scott]

Please keep in mind that Nova keeps some volume state in the BlockDeviceMapping 
table. Without changes to Nova, a force_detach function is not complete.

I am interested in this use case, as are other Cinder developers. Please feel 
free to contact me in IRC with questions as "scottda".


Scott D'Angelo


From: joehuang 
Sent: Sunday, September 18, 2016 3:29:29 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle] Should we discuss the use cases of 
force volume detach in the Tricircle

This is a good question. I also sent a mail in cinder thread that wants to know 
why the tempest test cases missing for the "force volume detach".
The spec for the "force volume detach" could be found here: 
https://github.com/openstack/cinder-specs/blob/master/specs/liberty/implement-force-detach-for-safe-cleanup.rst

From: cr_...@126.com [cr_...@126.com]
Sent: 18 September 2016 16:53
To: openstack-dev
Subject: [openstack-dev] [tricircle] Should we discuss the use cases of force 
volume detach in the Tricircle

Hello，
When the patch "force volume detach" has submited , some proposals have came 
back.
The important point is wheathe this function is needed or safe.
Should we disscuss some uses cases of this function. Such as the define of this 
function, when this function been triggered.



Best regards,
Ronghui Cao, Ph.D. Candidate
College of Information Science and Engineering
Hunan University, Changsha 410082, Hunan, China
__
OpenStack Development Mailing 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] Adding ihrachys to theneutron-drivers team

[John Davidge]

Honestly, I had assumed Ihar was on the Drivers team already :)

A great addition to the team, and much deserved!

From: Paul Michali mailto:p...@michali.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, September 19, 2016 at 11:20 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Adding ihrachys to theneutron-drivers 
team

Congratulations Ihar! Great addition to the Drivers team.

On Mon, Sep 19, 2016 at 4:52 AM Vikram Choudhary 
mailto:vikram.choudh...@huawei.com>> wrote:
Congrats Ihar!

From: reedip banerjee [mailto:reedi...@gmail.com]
Sent: 19 September 2016 14:08

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Adding ihrachys to theneutron-drivers 
team

Congratulations Ihar :)

On Mon, Sep 19, 2016 at 2:00 PM, Martin Hickey 
mailto:martin.hic...@ie.ibm.com>> wrote:

I totally agree. Congrats Ihar.

Regards,
Martin
-
Martin Hickey | Software Development | Open Technologies | Tel: + 353 21 
7306040

[Inactive hide details for Assaf Muller ---17/09/2016 23:12:03---Well deserved 
is an understatement! Ihar is consistently integr]Assaf Muller ---17/09/2016 
23:12:03---Well deserved is an understatement! Ihar is consistently integral to 
the Neutron project. Ihar has w

From: Assaf Muller mailto:as...@redhat.com>>
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: 17/09/2016 23:12
Subject: Re: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers 
team





Well deserved is an understatement! Ihar is consistently integral to
the Neutron project. Ihar has wide knowledge not only of Neutron but
of OpenStack workings and is a key factor to Neutron playing nice with
other projects. Ihar has shown consistent good judgement of priorities
and will in no doubt strengthen the drivers team.

On Sat, Sep 17, 2016 at 1:19 PM, Dariusz Śmigiel
mailto:smigiel.dari...@gmail.com>> wrote:
> Congrats Ihar. You deserve this!
>
> 2016-09-17 18:40 GMT+02:00 Armando M. 
> mailto:arma...@gmail.com>>:
>> Hi folks,
>>
>> I would like to propose Ihar to become a member of the Neutron drivers team
>> [1].
>>
>> Ihar wide knowledge of the Neutron codebase, and his longstanding duties as
>> stable core, downstream package whisperer, release and oslo liaison (I am
>> sure I am forgetting some other capacity he is in) is going to put him at
>> great comfort in the newly appointed role, and help him grow and become wise
>> even further.
>>
>> Even though we have not been meeting regularly lately we will resume our
>> Thursday meetings soon [2], and having Ihar onboard by then will be highly
>> beneficial.
>>
>> Please, join me in welcome Ihar to the team.
>>
>> Cheers,
>> Armando
>>
>> [1]
>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
>> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Darek "dasm" Śmigiel
>
> 
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
>
> __
> OpenStack Development Mailing 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



--
Thanks and Regards,
Reedip Banerjee
IRC: reedip



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

Re: [openstack-dev] [cinder]tempest test case for force detach volume

[D'Angelo, Scott]

The cinder team would welcome submission of any missing Tempest test cases. I'm 
not certain of the history of the os-force_detach API, but you could write 
tests for them and they would be reviewed.


Scott D'Angelo


From: joehuang 
Sent: Saturday, September 17, 2016 8:47:48 PM
To: OpenStack Development Mailing List (not for usage questions); shinobu.kj; 
Shinobu KINJO
Subject: Re: [openstack-dev] [cinder]tempest test case for force detach volume

Hello, Ken,

Thank you for your information, for APIs without tempest test cases,
it's due to hard to build the test environment, or it's just for the API
is not mature enough? I want to know why the tempest test cases
were not added at the same time when the features were implemented.

Best Regards
Chaoyi Huang(joehuang)

From: Ken'ichi Ohmichi [ken1ohmi...@gmail.com]
Sent: 15 September 2016 2:02
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder]tempest test case for force detach volume

Hi Chaoyi,

That is a nice point.
Now Tempest have tests for some volume v2 action APIs which doesn't
contain os-force_detach.
The available APIs of tempest are two: os-set_image_metadata and
os-unset_image_metadata like
https://github.com/openstack/tempest/blob/master/tempest/services/volume/v2/json/volumes_client.py#L27
That is less than I expected by comparing the API reference.

The corresponding API tests' patches are welcome if interested in :-)

Thanks
Ken Ohmichi

---


2016-09-13 17:58 GMT-07:00 joehuang :
> Hello,
>
> Is there ant tempest test case for "os-force_detach" action to force detach
> a volume? I didn't find such a test case both in the repository
> https://github.com/openstack/cinder/tree/master/cinder/tests/tempest
> and https://github.com/openstack/tempest
>
> The API link is:
> http://developer.openstack.org/api-ref-blockstorage-v2.html#forcedetachVolume
>
> 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 Development Mailing 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] [Product] Project Navigator - Maturity Metrics

[gordon chung]

is this updated with a script or manually? i just took a quick look at 
this and some of the projects have a different information between the 
high-level "all projects" view and the detailed individual project view. 
this was something that was brought up a months ago so i assume it 
hasn't been looked at in a while.

for example, i'm not a PTL but it says i am one.

On 16/09/16 06:02 PM, Shamail wrote:
> Hi Kenny,
>
> The maturity metrics in the project navigator are derived using TC Managed 
> Tags[1] (binary) and Operator Tags[2] (non-binary).  The description each tag 
> can be found in the provided links.  The values for the tags are refreshed 
> periodically (e.g. once a release cycle for operator tags) and these are 
> pulled into the project navigator and displayed as the 8 maturity indicators 
> for the projects.  The ops-tag team meets once a month when we have new 
> submissions to review.  Anyone is welcome to submit a tag/indicator for 
> review.
>
> [1] https://governance.openstack.org/reference/tags/
> [2] https://github.com/openstack/ops-tags-team/tree/master/descriptions
>
> Thanks,
> Shamail
>
>> On Sep 16, 2016, at 2:04 PM, Kenny Johnston  wrote:
>>
>> OpenStackers,
>>
>> What is the best way to understand the past discussion, and perhaps start a
>> new conversation about the maturity metrics found in the project
>> navigator[1]? I don't want to propose anything without knowing more of the
>> context of why the current metrics and thresholds were chosen.
>>
>> Thanks!
>>
>> --
>> Kenny Johnston | irc:kencjohnston | @kencjohnston
>>
>> [1]https://www.openstack.org/software/project-navigator/
>> ___
>> Product-wg mailing list
>> product...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

cheers,

-- 
gord

__
OpenStack Development Mailing 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] Barcelona Design Summit track layout

[Emilien Macchi]

On Mon, Sep 19, 2016 at 3:18 AM, Antoine Cabot  wrote:
> On Sun, Sep 18, 2016 at 3:59 PM, Thierry Carrez  wrote:
>> Emilien Macchi wrote:
>>> On Fri, Sep 16, 2016 at 10:22 AM, Thierry Carrez  
>>> wrote:
 1. If you have a *hard* conflict that I failed to take into account
 (like the PTL is giving a talk during the one and only fishbowl room the
 team has), let me know and I'll try to find someone you could swap with.
>>>
>>> I'll give a talk on Thu 27  9:50am-10:30am but in same time there is a
>>> Puppet design session.
>>> Maybe could we move this Puppet session to another slot (my only
>>> constraint is to attend also all TripleO sessions).
>>> I hope we can arrange something :-)
>>
>> Argh! I spotted your talk but somehow failed to spot the conflict.
>>
>> I think the simpler would be to swap the Puppet workroom at 9:50am with
>> the Watcher workroom at 11:50am. Antoine: would that work for you ?
>
> It works for me.

Thanks Antoine and all Watcher team :-)
And of course Thierry for your flexibility on this one.

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



-- 
Emilien Macchi

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

Re: [openstack-dev] [TripleO] *ExtraConfig, backwards compatibility & deprecation

[Steven Hardy]

On Wed, Sep 14, 2016 at 06:32:07PM +0200, Giulio Fidente wrote:
> On 09/14/2016 05:59 PM, Giulio Fidente wrote:
> > On 09/14/2016 02:31 PM, Steven Hardy wrote:
> > > Related to this is the future of all of the per-role customization
> > > interfaces.  I'm thinking these don't really make sense to maintain
> > > long-term now we have the new composable services architecture, and it
> > > would be better if we can deprecate them and move folks towards the
> > > composable services templates instead?
> > 
> > my experience is that the ExtraConfig interfaces have been useful to
> > provide arbitrary hiera and class includes
> > 
> > I wonder if we could ship by default some roles parsing those parameters?
> 
> thinking more about it, the *ExtraConfig interfaces also offer a simple
> mechanism to *override* any hiera setting we push via the templates ...
> which isn't easy to achieve with roles
> 
> a simple short-term solution could be to merge ExtraConfig in the $role
> mapped_data, thoughts?

Thanks for the feedback, so yeah I agree there are reasons to keep the
ExtraConfig *parameters* around, or some similar interface.

I probably should have clarified this in my original post, but there are
two types of *ExtraConfig interfaces, the parameters you refer to, which
simply override some hieradata (we probably want to keep this, but it still
means we have ExtraConfig tied the the role (not the service), but
presumably an operator will know what services are deployed on what role).

The second (and more problematic from a containers point of view) is the
ExtraConfig *resources*, where you can pass an arbitrary heat template,
which typically is used to run stuff on the host (which will be impossible,
or at least not useful on an atomic host in a fully containerized
deployment).

I think your concerns are mostly around the ExtraConfig *parameters* thus,
provided we maintain some way to do those hiera overrides, e.g the
documented interfaces for Ceph ExtraConfig can still be used?

Steve

__
OpenStack Development Mailing 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] [qa] resigning from Tempest core

[Jordan Pittier]

Hi Marc,
Thanks for your good work on Tempest all these years.

I know you are still contributing to other areas of OpenStack so that's
good for the project as a whole.

Cheers,
Jordan

On Mon, Sep 19, 2016 at 11:51 AM, Koderer, Marc  wrote:

> Hi folks,
>
> as already mentioned during the current code sprint:
> I am currently lacking time for reviews and code contributions.
>
> I think it better to step back and let other’s in that are more active.
>
> Thanks for all the support and it was really fun the past 3 years working
> with
> you!
>
> Regards
> Marc
>
>
> __
> OpenStack Development Mailing 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] [Fuel] Getting rid of ISO

[Vladimir Kozhukalov]

Ruijing,

In a nutshell, the guide would be
0) install vanilla Centos 7
1) install fuel-release package (it configures necessary yum repos)
wget
http://packages.fuel-infra.org/repositories/centos/master-centos7/snapshots/os-2016-09-19-093900/x86_64/Packages/fuel-release-10.0.0-1.mos6376.git.a8c98d0.noarch.rpm
rpm -Uvh fuel-release-10.0.0-1.mos6376.git.a8c98d0.noarch.rpm
2) install fuel-setup package
yum install fuel-setup
3) run bootstrap script (be aware, that bootstrap script reconfigures some
of system parameters)
/usr/sbin/bootstrap_admin_node.sh

I'll describe the whole procedure on the Fuel wiki page. Fuel deployment
procedure is to be improved in Ocata.

Regarding your previous question about docker image, we are not planning to
provide a single Fuel docker image (docker containers are not VMs).
Container is an isolated process and Fuel assumes we run multiple processes
(API, RPC, etc.). Given that, Fuel should be a set of docker containers. We
used to run Fuel in containers, but those were kind of mess when we ran
puppet when building images and we put those images inside rpms and inside
ISO. We definitely don't want to have something like this again. But if you
use Docker images that are built from pure Dockerfiles (not using puppet,
from source code) and publishing them on docker registry that could be a
way to provide development environment (for plugin developers it could be
super convenient). Yes, that was in our plans for Newton, but we didn't
manage to implement this. Maybe in Ocata.




Vladimir Kozhukalov

On Mon, Sep 19, 2016 at 9:33 AM, Guo, Ruijing  wrote:

> Hi, Vladimir
>
>
>
> Any guide to install from rpm?
>
>
>
> Thanks,
>
> -Ruijing
>
> *From:* Vladimir Kozhukalov [mailto:vkozhuka...@mirantis.com]
> *Sent:* Tuesday, August 16, 2016 4:58 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* [openstack-dev] [Fuel] Getting rid of ISO
>
>
>
> Dear colleagues,
>
> We finally have working custom deployment job that deploys Fuel admin node
> using online RPM repositories (not ISO) on vanilla Centos 7.0.
>
> Currently all Fuel system and deployment tests use ISO and we are planning
> to re-implement all these jobs (including BVT, SWARM, and Fuel CI jobs) to
> exclude ISO from the pipeline. That will allow us to get rid of ISO as our
> deliverable and instead rely totally on package repositories. Linux
> distributions like Ubuntu, Debian, RHEL, etc. are already delivered via
> ISO/qcow2/etc. images and we'd better stop reinventing a wheel and support
> our own ISO build code. That will allow us to make Fuel admin node
> deployment more flexible.
>
>
>
> I will infrom about our next steps here in the thread.
>
>
> Vladimir Kozhukalov
>
> __
> OpenStack Development Mailing 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] [cinder] LVM vs BDD drivers performance tests results

[Ivan Kolodyazhny]

Hi team,

We did some performance tests [1] for LVM and BDD drivers. All tests were
executed on real hardware with OpenStack Mitaka release. Unfortunately, we
didn't have enough time to execute all tests and compare results. We used
Sahara/Hadoop cluster with TestDFSIO and others tests.

All tests were executed on the same hardware and OpenStack release. Only
difference were in cinder.conf to enable needed backend and/or target
driver.

Tests were executed on following configurations:

   - LVM +TGT target
   - LVM+LocalTarget: PoC based on [2] spec
   - LVM+LIO
   - Block Device Driver.


Feel free to ask question if any about our testing infrastructure,
environment, etc.


[1]
https://docs.google.com/spreadsheets/d/1qS_ClylqdbtbrVSvwbbDpdWNf2lZPR_ndtW6n54GJX0/edit?usp=sharing
[2] https://review.openstack.org/#/c/247880/

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