settingsLogin | Registersettings

Re: [openstack-dev] OpenStack-dev Digest, Vol 41, Issue 49

0 votes

Topic - Fuel

Hi,

My deployment is failing beacuse of following reason :

Verification failed.
Method verify_networks. Network verification not avaliable because nodes
["3", "4", "6", "7"] not avaliable via mcollective. Inspect Astute logs for
the details

anybody can help here ?

On Thu, Sep 17, 2015 at 3:42 PM, openstack-dev-request@lists.openstack.org
wrote:

Send OpenStack-dev mailing list submissions to
openstack-dev@lists.openstack.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
or, via email, send a message with subject or body 'help' to
openstack-dev-request@lists.openstack.org

You can reach the person managing the list at
openstack-dev-owner@lists.openstack.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenStack-dev digest..."

Today's Topics:

  1. Re: [Congress] CLI equivalent (Alex Yip)
  2. Re: [relmgt] PTL non-candidacy (Thomas Goirand)
  3. [Trove] PTL Candidacy (Craig Vyvial)
  4. Re: [Congress] PTL candidacy (Ramki_Krishnan@Dell.com)
  5. [storlets] Review requests suggestion (Eran Rom)
  6. Re: [cinder] LVM snapshot performance issue -- why isn't thin
    provisioning the default? (Duncan Thomas)
  7. Re: [puppet] service default value functions (Cody Herriges)
  8. Re: [cinder] LVM snapshot performance issue -- why isn't thin
    provisioning the default? (Eric Harney)
  9. Re: [puppet][keystone] Choose domain names with 'composite
    namevar' or 'meaningless name'? (Cody Herriges)

    1. Re: [Fuel] Nominate Olga Gusarenko for fuel-docs core
      (Sheena Gregson)
    2. Re: [Fuel] Nominate Olga Gusarenko for fuel-docs core
      (Dmitry Borodaenko)
    3. [ironic] PTL candidacy (Devananda van der Veen)
    4. [oslo][doc] Oslo doc sprint 9/24-9/25 (James Carey)
    5. [neutron][lbaas] Proposing Michael Johnson for neutron-lbaas
      core team (Doug Wiegley)
    6. Re: [neutron][lbaas] Proposing Michael Johnson for
      neutron-lbaas core team (Al Miller)
    7. Re: [neutron][lbaas] Proposing Michael Johnson for
      neutron-lbaas core team (Eichberger, German)
    8. Re: [neutron][lbaas] Proposing Michael Johnson for
      neutron-lbaas core team (Phillip Toohill)
    9. [QA] Meeting Thursday September 17th at 9:00 UTC (GHANSHYAM MANN)
    10. Re: [neutron][lbaas] Proposing Michael Johnson for
      neutron-lbaas core team (Kyle Mestery)
    11. [gate] requirement conflict on Babel breaks grenade jobs
      (Armando M.)
    12. [Cue] PTL Candidacy (Vipul Sabhaya)
    13. Re: [Barbican] Providing service user read access to all
      tenant's certificates (Vijay Venkatachalam)
    14. Re: [Barbican] Providing service user read access to all
      tenant's certificates (Vijay Venkatachalam)
    15. Re: ceilometer code debugging (gord chung)
    16. Re: [Congress] PTL candidacy (Rui Chen)
    17. Re: how to get current memory utilization of an instance
      (Abhishek Talwar)
    18. [all][gate] grende jobs failing. (Tony Breeds)
    19. [i18n] PTL candidacy (Ying Chun Guo)
    20. [defcore] Scoring for DefCore 2016.01 Guideline (Chris Hoge)
    21. Re: [all][gate] grende jobs failing. (Tony Breeds)
    22. [Glance] PTL candidacy (Nikhil Komawar)
    23. Re: [neutron][lbaas] Proposing Michael Johnson for
      neutron-lbaas core team (Samuel Bercovici)
    24. Re: [Magnum] API response on k8s failure (Ton Ngo)
    25. [dragonflow] Low OVS version for Ubuntu (Li Ma)
    26. Re: [neutron] RFE process question (Li Ma)
    27. [oslo][oslo.config] Reloading configuration of service (mhorban)
    28. [neutron] Please help review this RFE (Li Ma)
    29. Re: [dragonflow] Low OVS version for Ubuntu (Sudipto Biswas)
    30. [oslo][oslo.config] Reloading configuration of service (mhorban)
    31. Re: [puppet] service default value functions (Yanis Guenane)
    32. Re: [Fuel] Bugs which we should accept in 7.0 after Hard Code
      Freeze (Adam Heczko)
    33. Re: [all][gate] grende jobs failing. (Tony Breeds)
    34. questions about nova compute monitors extensions (Hou Gang HG Liu)
    35. Re: [dragonflow] Low OVS version for Ubuntu (Gal Sagie)
    36. Re: [cinder] LVM snapshot performance issue -- why isn't thin
      provisioning the default? (Duncan Thomas)
    37. [magnum][ptl] Magnum PTL Candidacy (Hongbin Lu)

Message: 1
Date: Wed, 16 Sep 2015 19:47:57 +0000
From: Alex Yip ayip@vmware.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Congress] CLI equivalent
Message-ID: 1442433064831.38322@vmware.com
Content-Type: text/plain; charset="iso-8859-1"

Try this:

openstack congress policy row list classification error?


From: Shiv Haris sharis@Brocade.com
Sent: Wednesday, September 16, 2015 12:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Congress] CLI equivalent

Do we have a CLI way for doing the equivalent of:

$ curl -X GET localhost:1789/v1/policies/classification/tables/error/rows
As described in the tutorial:

https://github.com/openstack/congress/blob/master/doc/source/tutorial-tenant-sharing.rst#listing-policy-violations
<
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_congress_blob_master_doc_source_tutorial-2Dtenant-2Dsharing.rst-23listing-2Dpolicy-2Dviolations&d=BQMGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=djA1lFdIf0--GIJ_8gr44Q&m=m3vnP788yf3Iil8q67Kfx9ViGERr356Hb7b2KBSss9M&s=PUH7xM0t0Uy3ovTTmks2NWmKbdfY_90-EJsXIoNvSEQ&e=
>

-Shiv

From: Tim Hinrichs [mailto:tim@styra.com]
Sent: Thursday, September 10, 2015 8:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Congress] Ending feature freeze

Hi all,

We're now finished with feature freeze. We have our first release
candidate and the stable/liberty branch. So master is once again open for
new features. Couple of things to note:

  1. Documentation. We should also look through the docs and update them.
    Documentation is really important. There's one doc patch not yet merged,
    so be sure to pull that down before editing. That patch officially
    deprecates a number of API calls that don't make sense for the new
    distributed architecture. If you find places where we don't mention the
    deprecation, please fix that.

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

  1. Bugs. We should still all be manually testing, looking for bugs, and
    fixing them. This will be true especially as other projects change their
    clients, which as we've seen can break our datasource drivers.

All bug fixes first go into master, and then we cherry-pick to
stable/liberty. Once you've patched a bug on master and it's been merged,
you'll create another change for your bug-fix and push it to review. Then
one of the cores will +2/+1 it (usually without needing another formal
round of reviews). Here's the procedure.

// pull down the latest changes for master
$ git checkout master
$ git pull

// create a local branch for stable/liberty and switch to it
$ git checkout origin/stable/liberty -b stable/liberty

// cherry-pick your change from master onto the local stable/liberty
// The -x records the original in the commit msg
$ git cherry-pick -x

// Push to review and specify the stable/liberty branch.
// Notice in gerrit that the branch is stable/liberty, not master
$ git review stable/liberty

// Once your change to stable/liberty gets merged, fetch all the new
// changes.

// switch to local version of stable/liberty
$ git checkout stable/liberty

// fetch all the new changes to all the branches
$ git fetch origin

// update your local branch
$ git rebase origin/stable/liberty

Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/52432cf9/attachment-0001.html
>


Message: 2
Date: Wed, 16 Sep 2015 22:01:33 +0200
From: Thomas Goirand zigo@debian.org
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [relmgt] PTL non-candidacy
Message-ID: 55F9CA9D.2060408@debian.org
Content-Type: text/plain; charset=windows-1252

On 09/16/2015 11:33 AM, Thierry Carrez wrote:

Hi everyone,

I have been handling release management for OpenStack since the
beginning of this story, well before Release Management was a program or
a project team needing a proper elected PTL. Until recently it was
largely a one-man job. But starting with this cycle, to accommodate the
Big Tent changes, we grew the team significantly, to the point where I
think it is healthy to set up a PTL rotation in the team.

I generally think it's a good thing to change the PTL for a team from
time to time. That allows different perspectives, skills and focus to be
brought to a project team. That lets you take a step back. That allows
to recognize the efforts and leadership of other members, which is
difficult if you hold on the throne. So I decided to put my foot where
my mouth is and apply those principles to my own team.

That doesn't mean I won't be handling release management for Mitaka, or
that I won't ever be Release Management PTL again -- it's just that
someone else will take the PTL hat for the next cycle, drive the effort
and be the most visible ambassador of the team.

Cheers,

If we are switching from you to Doug, we'll be switching from an awesome
person to another also awesome one. Thanks for all the work.

Cheers,

Thomas


Message: 3
Date: Wed, 16 Sep 2015 20:03:35 +0000
From: Craig Vyvial cp16net@gmail.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Trove] PTL Candidacy
Message-ID:
<
CAOK58XR8X7MMRXgj4EKJ7ZtQfPNDxgWuqJHs6XMLpQmZhakH1A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello,

My name is Craig Vyvial and I'd like run for Mitaka Trove PTL. I've been
working on Trove for about 4 years and a core member for about 2 years.
Over the this time, Trove has continued to evolve and the community has
grown. My passion is to help make sure that Trove continues this trend and
guide Trove to be a world class database as a service for OpenStack.

Trove started just provisioing a single MySQL instance and has grown to a
total of 12 datastores to date with a few datastores supporting clustering.
I think there are a few areas that make sense with this kind of growth that
we should focus on during Mitaka.

  • Add CI tests for other datastores with third patry CI systems. With so
    many new datastores available within Trove, we need to make sure that we
    stabilize tests on multiple datastores.

  • Advance the features of Trove for all datastores.

  • Simplify the installation of Trove that includes install, upgrades,
    building guest images, and management operations.

  • Continue the trend of growing the trove community.

As PTL of Trove, I will help the project move forward by looking to the
community for input and making sure we take steps toward making OpenStack a
better platform as well as Trove the ideal solution for users looking for a
database as a service solution.

Thanks,


Message: 4
Date: Wed, 16 Sep 2015 15:09:32 -0500
From: Ramki_Krishnan@Dell.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Congress] PTL candidacy
Message-ID:
<
DF91EBC32A031943A8B78D81D40122BC0404D4FB5E@AUSX7MCPC103.AMER.DELL.COM>

Content-Type: text/plain; charset="utf-8"

+1 and looking forward to see you in Tokyo.

Thanks,
Ramki

From: Tim Hinrichs [mailto:tim@styra.com]
Sent: Tuesday, September 15, 2015 1:23 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Congress] PTL candidacy

Hi all,

I?m writing to announce my candidacy for Congress PTL for the Mitaka
cycle. I?m excited at the prospect of continuing the development of our
community, our code base, and our integrations with other projects.

This past cycle has been exciting in that we saw several new, consistent
contributors, who actively pushed code, submitted reviews, wrote specs, and
participated in the mid-cycle meet-up. Additionally, our integration with
the rest of the OpenStack ecosystem improved with our move to running
tempest tests in the gate instead of manually or with our own CI. The code
base matured as well, as we rounded out some of the features we added near
the end of the Kilo cycle. We also began making the most significant
architectural change in the project?s history, in an effort meet our
high-availability and API throughput targets.

I?m looking forward to the Mitaka cycle. My highest priority for the code
base is completing the architectural changes that we began in Liberty.
These changes are undoubtedly the right way forward for production use
cases, but it is equally important that we make Congress easy to use and
understand for both new developers and new end users. I also plan to
further our integration with the OpenStack ecosystem by better utilizing
the plugin architectures that are available (e.g. devstack and tempest). I
will also work to begin (or continue) dialogues with other projects that
might benefit from consuming Congress. Finally I?m excited to continue
working with our newest project members, helping them toward becoming core
contributors.

See you all in Tokyo!
Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/6ed1879f/attachment-0001.html
>


Message: 5
Date: Wed, 16 Sep 2015 23:19:18 +0300
From: Eran Rom ERANR@il.ibm.com
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [storlets] Review requests suggestion
Message-ID:
<
OFAF5DC7D8.6A8D3CF1-ONC2257EC2.006F4467-C2257EC2.006FA199@il.ibm.com>
Content-Type: text/plain; charset="us-ascii"

Hi All,
I suggest that until we have functional tests in place, each commit
message should specify that:
(1) For a code change - the system tests were executed successfully with
the change -
(2) For installation related change that the installation was tested with
this.

I further suggest that if the commit message does not have this the
reviewer can assume that the committer forgot to do these and -1
Opinions?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/451c3b22/attachment-0001.html
>


Message: 6
Date: Wed, 16 Sep 2015 23:25:18 +0300
From: Duncan Thomas duncan.thomas@gmail.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [cinder] LVM snapshot performance issue
-- why isn't thin provisioning the default?
Message-ID:
<CAOyZ2aGZn6a-eRUv_TmB2r4s2FD719NONvBihzS4hNEKhNC=
Nw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On 16 Sep 2015 20:42, "yang, xing" xing.yang@emc.com wrote:

On 9/16/15, 1:20 PM, "Eric Harney" eharney@redhat.com wrote:

This sounds like a good idea, I'm just not sure how to structure it yet
without creating a very confusing set of config options.

I?m thinking we could have a prefix with vendor name for this and it also
requires documentation by driver maintainers if they are using a
different
config option. I proposed a topic to discuss about this at the summit.

We already have per-backend config values in cinder.conf. I'm not sure how
the config code will need to be structured to achieve it, but ideally I'd
like a single config option that can be:

(i) set in the default section if desired
(in) overridden in the per driver section, and (iii) have a default set in
each driver.

I don't think oslo.config lets us do (I'll) yet though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/a06a65d2/attachment-0001.html
>


Message: 7
Date: Wed, 16 Sep 2015 13:35:47 -0700
From: Cody Herriges cody@puppetlabs.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org, Hunter Haugen
hunter@puppetlabs.com
Subject: Re: [openstack-dev] [puppet] service default value functions
Message-ID: 55F9D2A3.8010006@puppetlabs.com
Content-Type: text/plain; charset="utf-8"

Emilien Macchi wrote:

On 09/16/2015 12:53 PM, Alex Schultz wrote:

Hey puppet folks,

Based on the meeting yesterday[0], I had proposed creating a parser
function called isservicedefault[1] to validate if a variable matched
our agreed upon value of ''. This got me thinking
about how can we maybe not use the arbitrary string throughout the
puppet that can not easily be validated. So I tested creating another
puppet function named service_default[2] to replace the use of '' throughout all the puppet modules. My tests seemed to
indicate that you can use a parser function as parameter default for
classes.

I wanted to send a note to gather comments around the second function.
When we originally discussed what to use to designate for a service's
default configuration, I really didn't like using an arbitrary string
since it's hard to parse and validate. I think leveraging a function
might be better since it is something that can be validated via tests
and a syntax checker. Thoughts?

Let me add your attempt to make it work in puppet-cinder:
https://review.openstack.org/#/c/224277

I like the proposal, +1.

Hunter,

Do you off hand know what kind of overhead is generated by this?

--
Cody

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: OpenPGP digital signature
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/e4c794ef/attachment-0001.pgp
>


Message: 8
Date: Wed, 16 Sep 2015 16:43:30 -0400
From: Eric Harney eharney@redhat.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [cinder] LVM snapshot performance issue
-- why isn't thin provisioning the default?
Message-ID: 55F9D472.5000505@redhat.com
Content-Type: text/plain; charset=windows-1252

On 09/16/2015 04:25 PM, Duncan Thomas wrote:

On 16 Sep 2015 20:42, "yang, xing" xing.yang@emc.com wrote:

On 9/16/15, 1:20 PM, "Eric Harney" eharney@redhat.com wrote:

This sounds like a good idea, I'm just not sure how to structure it yet
without creating a very confusing set of config options.

I?m thinking we could have a prefix with vendor name for this and it
also
requires documentation by driver maintainers if they are using a
different
config option. I proposed a topic to discuss about this at the summit.

We already have per-backend config values in cinder.conf. I'm not sure
how
the config code will need to be structured to achieve it, but ideally
I'd
like a single config option that can be:

(i) set in the default section if desired
(in) overridden in the per driver section, and (iii) have a default set
in
each driver.

I don't think oslo.config lets us do (I'll) yet though.

I think there may be other issues to sort through to do that.
Currently, at least some options set in [DEFAULT] don't apply to
per-driver sections, and require you to set them in the driver section
as well.

If we keep that behavior (which I think is broken, personally), then
trying to do option (iii) may be pretty confusing, because the deployer
won't know which of the global vs. driver defaults are actually going to
be applied.


Message: 9
Date: Wed, 16 Sep 2015 13:58:30 -0700
From: Cody Herriges cody@puppetlabs.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [puppet][keystone] Choose domain names
with 'composite namevar' or 'meaningless name'?
Message-ID: 55F9D7F6.2000604@puppetlabs.com
Content-Type: text/plain; charset="iso-8859-1"

I wrote my first composite namevar type a few years and ago and all the
magic is basically a single block of code inside the type...

https://github.com/puppetlabs/puppetlabs-java_ks/blob/master/lib/puppet/type/java_ks.rb#L145-L169

It basically boils down to these three things:

While it looks like the README never got updated, the java_ks example
supports both meaningful titles and arbitrary ones.

javaks { 'activemqpuppetca_keystore':
ensure => latest,
name => 'puppetca',
certificate => '/etc/puppet/ssl/certs/ca.pem',
target => '/etc/activemq/broker.ks',
password => 'puppet',
trustcacerts => true,
}

javaks { 'broker.example.com:/etc/activemq/broker.ks':
ensure => latest,
certificate =>
'/etc/puppet/ssl/certs/broker.example.com.pe-internal-broker.pem',
private
key =>
'/etc/puppet/ssl/private_keys/broker.example.com.pe-internal-broker.pem',
password => 'puppet',
}

You'll notice the first being an arbitrary title and the second
utilizing a ":" as a delimiter and omitting the name and target parameters.

Another code example can be found in the package type.

https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/package.rb#L268-L291
.

--
Cody

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: OpenPGP digital signature
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/73c3b7f1/attachment-0001.pgp
>


Message: 10
Date: Wed, 16 Sep 2015 16:22:02 -0500
From: Sheena Gregson sgregson@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Cc: Olga Gusarenko ogusarenko@mirantis.com
Subject: Re: [openstack-dev] [Fuel] Nominate Olga Gusarenko for
fuel-docs core
Message-ID: 7e65f8d3e04579ba78d3c14bdea4dcb2@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

+1 Thanks for being a great docs contributor and community member.

From: Alexander Adamov [mailto:aadamov@mirantis.com]
Sent: Monday, September 14, 2015 5:44 AM
To: OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
Cc: Olga Gusarenko ogusarenko@mirantis.com
Subject: Re: [openstack-dev] [Fuel] Nominate Olga Gusarenko for fuel-docs
core

+1

Nice!)

Alexander

On Fri, Sep 11, 2015 at 8:19 PM, Dmitry Borodaenko <
dborodaenko@mirantis.com>
wrote:

+1

Great work Olga!

On Fri, Sep 11, 2015, 11:09 Irina Povolotskaya <ipovolotskaya@mirantis.com
>
wrote:

Fuelers,

I'd like to nominate Olga Gusarenko for the fuel-docs-core.

She has been doing great work and made a great contribution

into Fuel documentation:

http://stackalytics.com/?user_id=ogusarenko&release=all&project_type=all&module=fuel-docs

It's high time to grant her core reviewer's rights in fuel-docs.

Core reviewer approval process definition:
https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

--

Best regards,

Irina


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/9d63d703/attachment-0001.html
>

Message: 11
Date: Wed, 16 Sep 2015 14:28:59 -0700
From: Dmitry Borodaenko dborodaenko@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Cc: Olga Gusarenko ogusarenko@mirantis.com
Subject: Re: [openstack-dev] [Fuel] Nominate Olga Gusarenko for
fuel-docs core
Message-ID:
<
CAM0pNLMoTfdds-N6mXpeeE360YopScqbgbW3e-hUhPT3oysKvA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

5 days and no objections: welcome to Fuel Docs core reviewers! Keep up
the great work!

On Fri, Sep 11, 2015 at 11:07 AM, Irina Povolotskaya
ipovolotskaya@mirantis.com wrote:

Fuelers,

I'd like to nominate Olga Gusarenko for the fuel-docs-core.

She has been doing great work and made a great contribution
into Fuel documentation:

http://stackalytics.com/?user_id=ogusarenko&release=all&project_type=all&module=fuel-docs

It's high time to grant her core reviewer's rights in fuel-docs.

Core reviewer approval process definition:
https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

--
Best regards,

Irina


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

--
Dmitry Borodaenko


Message: 12
Date: Wed, 16 Sep 2015 21:35:51 +0000
From: Devananda van der Veen devananda.vdv@gmail.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [ironic] PTL candidacy
Message-ID:
<
CAExZKEoTHvniLyO09cesYsB9VEOg3frfoYMqHpQfXVJgdZkg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi all,

( repost from https https://review.openstack.org/223753://
https://review.openstack.org/223753review.openstack.org
https://review.openstack.org/223753/223753
https://review.openstack.org/223753 )

It's that time again, where encumbent PTLs are supposed to write about what
features or changes they accomplished and what goals they have for the next
cycle.

I'm not going to do that this time.

Even you though you may have read similar things from others (either in
this or in previous cycles) I'm going to reiterate something. Contrary to
being the technical lead, OpenStack requires the PTL to do a whole slew of
less glamorous things (or delegate them to other people).

  • launchpad monkey
  • midcycle coordinator
  • release coordinator
  • public speaker
  • cross project liaison
  • vendor buffer
  • cat wrangler

Historically, PTL meant "project technical lead", but as OpenStack grew, we
/ the TC realized that it is more^D^D^D^Ddifferent than that, and so now
the acronym is defined as "project team lead" [0]. And that is much more
representative of the responsibilities a PTL has today. In short, being PTL
and the lead architect for a successful/sizable project at the same time ==
two full time jobs.

Even before I was doing anything internal at HP, it seemed like my upstream
work was never done since I was trying to be both the team and tech leads
for Ironic. That said, it was also extremely rewarding to found this
project and exercise my social and organizational skills in building a
community around it. I could not be more satisfied with the results -- all
of you make Ironic much more awesome than I could have done alone. That's
the point, after all :)

Last election cycle, I stepped down from the TC so that I could have more
time for my roles as tech and team lead, and to focus on some internal work
(yup, still three jobs). That other work, for better or for worse, took a
greater tax on me than I had anticipated, and my activity upstream has
suffered (sorry!). This has created room for many of the other core
developers, who've been around the project almost as long as I have, to
come forward and fill in the gaps I left in the project management. And
that's really awesome. Thank you all.

I am thrilled that more of the project responsibilities are being handled
by Jim, Ruby, Chris, Lucas, and everyone else now. They are all leading
different areas in their own ways. As PTLs, each would bring a different
viewpoint to the project's day-to-day operations, and if they were to run,
I would support all of them (even though we disagree some times). Today,
there are multiple people who could run the project in my stead, and that
makes me very happy.

If elected, I promise to continue enabling the core team to do more without
my direct involvement, to continue leading in the technical vision for the
project, and liaising with vendors and operators to ensure the project
matures in such a way that it meets their needs.

If you believe I've done a great job as PTL and want me to continue doing
what I've been doing, then please re-elect me. (*)

If you'd like to see a change of pace, please don't hesitate to elect
another PTL :)

Thank you,
Devananda

(*) If you think I haven't done a great job as PTL, I invite you to tell me
how you think I could do better. For the sake of the election archives,
please don't reply to this email.

[0]

https://github.com/openstack/governance/commit/319fae1ea13775d16f865f886db0388e42cd0d1b
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/da01d068/attachment-0001.html
>


Message: 13
Date: Wed, 16 Sep 2015 16:40:27 -0500
From: James Carey bellerophon@flyinghorsie.com
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [oslo][doc] Oslo doc sprint 9/24-9/25
Message-ID:
<CAHjMoV0vx=
mEcnsJHyq29hwoAA6oq9fwdXYqVFGttVCwLEeicg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

In order to improve the Oslo libraries documentation, the Oslo team is
having a documentation sprint from 9/24 to 9/25.

We'll kick things off at 14:00 UTC on 9/24 in the

openstack-oslo-docsprint IRC channel and we'll use an etherpad [0].

All help is appreciated. If you can help or have suggestions for
areas of focus, please update the etherpad.

[0] https://etherpad.openstack.org/p/oslo-liberty-virtual-doc-sprint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/dd80ed8e/attachment-0001.html
>


Message: 14
Date: Wed, 16 Sep 2015 16:33:59 -0600
From: Doug Wiegley dougwig@parksidesoftware.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson
for neutron-lbaas core team
Message-ID:
FB4D40AE-3C76-4069-81D7-6593C5AFEB89@parksidesoftware.com
Content-Type: text/plain; charset=utf-8

Hi all,

As the Lieutenant of the advanced services, I nominate Michael Johnson to
be a member of the neutron-lbaas core reviewer team.

Review stats are in line with other cores[2], and Michael has been
instrumental in both neutron-lbaas and octavia.

Existing cores, please vote +1/-1 for his addition to the team (that?s
Brandon, Phil, Al, and Kyle.)

Thanks,
doug

1.
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
2. http://stackalytics.com/report/contribution/neutron-lbaas/90


Message: 15
Date: Wed, 16 Sep 2015 22:40:51 +0000
From: Al Miller ajmiller@ajmiller.net
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael
Johnson for neutron-lbaas core team
Message-ID:

<EFBE70D7D09F0A4397281F770E1802DBA87A2451@uc2-exmbx15-n1.UC2.Chicago.Hostway
>

Content-Type: text/plain; charset="utf-8"

+1

Al

-----Original Message-----
From: Doug Wiegley [mailto:dougwig@parksidesoftware.com]
Sent: Wednesday, September 16, 2015 3:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for
neutron-lbaas core team

Hi all,

As the Lieutenant of the advanced services, I nominate Michael Johnson to
be a member of the neutron-lbaas core reviewer team.

Review stats are in line with other cores[2], and Michael has been
instrumental in both neutron-lbaas and octavia.

Existing cores, please vote +1/-1 for his addition to the team (that?s
Brandon,
Phil, Al, and Kyle.)

Thanks,
doug

  1. http://docs.openstack.org/developer/neutron/policies/core-
    reviewers.html#core-review-hierarchy
  2. http://stackalytics.com/report/contribution/neutron-lbaas/90



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

Message: 16
Date: Wed, 16 Sep 2015 22:44:27 +0000
From: "Eichberger, German" german.eichberger@hpe.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael
Johnson for neutron-lbaas core team
Message-ID: D21F3EA2.17995%german.eichberger@hpe.com
Content-Type: text/plain; charset="Windows-1252"

Great news! From the Octavia end I totally support that choice?

German

On 9/16/15, 3:40 PM, "Al Miller" ajmiller@ajmiller.net wrote:

+1

Al

-----Original Message-----
From: Doug Wiegley [mailto:dougwig@parksidesoftware.com]
Sent: Wednesday, September 16, 2015 3:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for
neutron-lbaas core team

Hi all,

As the Lieutenant of the advanced services, I nominate Michael Johnson
to
be a member of the neutron-lbaas core reviewer team.

Review stats are in line with other cores[2], and Michael has been
instrumental in both neutron-lbaas and octavia.

Existing cores, please vote +1/-1 for his addition to the team (that?s
Brandon,
Phil, Al, and Kyle.)

Thanks,
doug

  1. http://docs.openstack.org/developer/neutron/policies/core-
    reviewers.html#core-review-hierarchy
  2. http://stackalytics.com/report/contribution/neutron-lbaas/90



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-
request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Message: 17
Date: Wed, 16 Sep 2015 23:03:22 +0000
From: Phillip Toohill phillip.toohill@RACKSPACE.COM
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael
Johnson for neutron-lbaas core team
Message-ID:
<
45ef3cc22894430a97c42f7693fe843b@543881-IEXCH01.ror-uc.rackspace.com>
Content-Type: text/plain; charset="Windows-1252"

+1

Phillip V. Toohill III
Software Developer

phone: 210-312-4366
mobile: 210-440-8374


From: Eichberger, German [german.eichberger@hpe.com]
Sent: Wednesday, September 16, 2015 5:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson
for neutron-lbaas core team

Great news! From the Octavia end I totally support that choice?

German

On 9/16/15, 3:40 PM, "Al Miller" ajmiller@ajmiller.net wrote:

+1

Al

-----Original Message-----
From: Doug Wiegley [mailto:dougwig@parksidesoftware.com]
Sent: Wednesday, September 16, 2015 3:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for
neutron-lbaas core team

Hi all,

As the Lieutenant of the advanced services, I nominate Michael Johnson
to
be a member of the neutron-lbaas core reviewer team.

Review stats are in line with other cores[2], and Michael has been
instrumental in both neutron-lbaas and octavia.

Existing cores, please vote +1/-1 for his addition to the team (that?s
Brandon,
Phil, Al, and Kyle.)

Thanks,
doug

  1. http://docs.openstack.org/developer/neutron/policies/core-
    reviewers.html#core-review-hierarchy
  2. http://stackalytics.com/report/contribution/neutron-lbaas/90



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-
request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Message: 18
Date: Thu, 17 Sep 2015 08:56:53 +0900
From: GHANSHYAM MANN ghanshyammann@gmail.com
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [QA] Meeting Thursday September 17th at 9:00
UTC
Message-ID:
<CACE3TKW=Ldh4=Xg0Ggo4apepB0_4Nu=
6ZdKNsmf0kWsBbw2EeA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi everyone,

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

The agenda for the meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting
Anyone is welcome to add an item to the agenda.

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

04:00 EDT
18:00 JST
18:30 ACST
11:00 CEST
04:00 CDT
02:00 PDT

--
Thanks & Regards
Ghanshyam Mann


Message: 19
Date: Wed, 16 Sep 2015 20:07:17 -0500
From: Kyle Mestery mestery@mestery.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael
Johnson for neutron-lbaas core team
Message-ID:
<
CAL3VkVz13METd05kGu25-ao7nvhqTod09a3PwAG9jnsRV3yYOw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

+1

On Wed, Sep 16, 2015 at 5:33 PM, Doug Wiegley <
dougwig@parksidesoftware.com>
wrote:

Hi all,

As the Lieutenant of the advanced services, I nominate Michael Johnson to
be a member of the neutron-lbaas core reviewer team.

Review stats are in line with other cores[2], and Michael has been
instrumental in both neutron-lbaas and octavia.

Existing cores, please vote +1/-1 for his addition to the team (that?s
Brandon, Phil, Al, and Kyle.)

Thanks,
doug

1.

http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/ff556612/attachment-0001.html
>


Message: 20
Date: Wed, 16 Sep 2015 18:07:57 -0700
From: "Armando M." armamig@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [gate] requirement conflict on Babel breaks
grenade jobs
Message-ID:
<CAK+RQebrUhwYS=
UveyPRHH+ASUQ5o67XouSOigH33BLxU4uA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

https://bugs.launchpad.net/grenade/+bug/1496650

HTH
Armando
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/9de4060e/attachment-0001.html
>


Message: 21
Date: Wed, 16 Sep 2015 18:16:17 -0700
From: Vipul Sabhaya vipuls@gmail.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Cue] PTL Candidacy
Message-ID:
<
CAHC46jtoP5A5Pe7w26LFb+A06W6icr1jeEYJgPsFQDbjw21CXQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello,

This will be the first official PTL election for Cue, and I would be
honored to serve another term leading the project for the M Cycle.

Cue is a relatively new project in Openstack, and was approved into the Big
Tent during Liberty. I have been involved with Cue from the beginning,
from initial POC to having a product that is production worthy. In my past
life, i?ve been a member of the Trove Core team.

During the Liberty Cycle, Cue has become a solid product with a control
plane that can manage per-tenant RabbitMQ Clusters. We spent a lot of time
beefing up our tests, and boast >90% unit test coverage. We also added
Tempest tests, and Rally tests, including gating jobs for both. Our
documentation has also been revamped considerably, and allows new
contributors to ramp up quickly with the project.

During the M cycle, I would like to focus on building a community and
getting additional contributors to Cue. I would also like to focus the
team on multi-broker support, including adding Kafka as a broker that is
managed by Cue.

I believe Cue has come a long ways in a short time, and going forward have
the opportunity accelerate the growth in terms of features, quality, and
adoption.

Thanks for your consideration!
-Vipul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/470c335c/attachment-0001.html
>


Message: 22
Date: Thu, 17 Sep 2015 01:57:44 +0000
From: Vijay Venkatachalam Vijay.Venkatachalam@citrix.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Barbican] Providing service user read
access to all tenant's certificates
Message-ID:
<26B082831A2B1A4783604AB89B9B2C080E89F58B@SINPEX01CL02.citrite.net
>
Content-Type: text/plain; charset="us-ascii"

How does lbaas do step 2?
It does not have the privilege for that secret/container using the service
user.
Should it use the keystone token through which user created LB config and
assign read access for the secret/container to the LBaaS service user?

Thanks,
Vijay V.

From: Fox, Kevin M [mailto:Kevin.Fox@pnnl.gov]
Sent: 16 September 2015 19:24
To: OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access
to all tenant's certificates

Why not have lbaas do step 2? Even better would be to help with the
instance user spec and combined with lbaas doing step 2, you could restrict
secret access to just the amphora that need the secret?

Thanks,
Kevin


From: Vijay Venkatachalam
Sent: Tuesday, September 15, 2015 7:06:39 PM
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org
openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Barbican] Providing service user read access to
all tenant's certificates
Hi,
Is there a way to provide read access to a certain user to
all secrets/containers of all project/tenant's certificates?
This user with universal "read" privilege's will be used as
a service user by LBaaS plugin to read tenant's certificates during LB
configuration implementation.
           Today's LBaaS users are following the below mentioned

process

  1. tenant's creator/admin user uploads a certificate info as secrets
    and container

  2. User then have to create ACLs for the LBaaS service user to access
    the containers and secrets

  3. User creates LB config with the container reference

  4. LBaaS plugin using the service user will then access container
    reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5
where the lbaas plugin's service user checks if the user configuring the LB
has read access to the container reference provided.

Thanks,
Vijay V.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/1e0b37b1/attachment-0001.html
>


Message: 23
Date: Thu, 17 Sep 2015 02:02:44 +0000
From: Vijay Venkatachalam Vijay.Venkatachalam@citrix.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Barbican] Providing service user read
access to all tenant's certificates
Message-ID:
<26B082831A2B1A4783604AB89B9B2C080E89F5CB@SINPEX01CL02.citrite.net
>
Content-Type: text/plain; charset="us-ascii"

The user here is the LBaaS service user which needs read access. This
service user does play any role in the config creator's project. The
service user might be playing a different role is in a common project.
For ex. "admin" user with "admin" role in "admin" project is the service
user in devstack for LBaaS.

--Vijay

From: Dave McCowan (dmccowan) [mailto:dmccowan@cisco.com]
Sent: 16 September 2015 18:36
To: OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access
to all tenant's certificates

A user with the role "observer" in a project will have read access to all
secrets and containers for that project, using the default settings in the
policy.json file.

--Dave McCowan

From: Vijay Venkatachalam <Vijay.Venkatachalam@citrix.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org

>
Date: Tuesday, September 15, 2015 at 10:06 PM
To: "OpenStack Development Mailing List (openstack-dev@lists.openstack.org
openstack-dev@lists.openstack.org)" <
openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org
>
Subject: [openstack-dev] [Barbican] Providing service user read access to
all tenant's certificates

Hi,
Is there a way to provide read access to a certain user to
all secrets/containers of all project/tenant's certificates?
This user with universal "read" privilege's will be used as
a service user by LBaaS plugin to read tenant's certificates during LB
configuration implementation.

           Today's LBaaS users are following the below mentioned

process

  1. tenant's creator/admin user uploads a certificate info as secrets
    and container

  2. User then have to create ACLs for the LBaaS service user to access
    the containers and secrets

  3. User creates LB config with the container reference

  4. LBaaS plugin using the service user will then access container
    reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5
where the lbaas plugin's service user checks if the user configuring the LB
has read access to the container reference provided.

Thanks,
Vijay V.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/9a2da227/attachment-0001.html
>


Message: 24
Date: Wed, 16 Sep 2015 22:10:23 -0400
From: gord chung gord@live.ca
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] ceilometer code debugging
Message-ID: BLU437-SMTP72E84AA275C3A5BD36B6DDE5A0@phx.gbl
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

hi,

i'm not familiar with eclipse+pydev but you should be able to run that
command as is in terminal

'./tools/ceilometer-test-event.py'

the main question i have is what are you trying to debug? that script,
to be honest, does not do much. it seems to just test the event
conversion functionality. you might find some useful information in the
dev docs[1] if you have questions about Ceilometer. if it's a pydev
specific question you might want to generalise your subject line to have
more eyes.

[1] http://docs.openstack.org/developer/ceilometer

On 16/09/15 08:42 AM, Nanda Devi Sahu wrote:

Hello,

I am trying to debug Ceilometer code taken from git. I have configured
Eclipse with Pydev for the same. The configuration seems to be fine
but when I do a debug of the code it shows to be running but I do not
see the flow of the code. LIke the main thread and the following threads.

Attached is the debug prespective view where the run is working
without any code stack.

Could you please suggest what Am I missing to get the flow. I have
also attached the debug configuration image for reference.

Regards,
Nanda.

L&T Technology Services Ltd

www.LntTechservices.com http://www.lnttechservices.com/

This Email may contain confidential or privileged information for the
intended recipient (s). If you are not the intended recipient, please
do not use or disseminate the information, notify the sender and
delete it from your system.


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

--
gord

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/34169458/attachment-0001.html
>


Message: 25
Date: Thu, 17 Sep 2015 10:27:40 +0800
From: Rui Chen chenrui.momo@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Congress] PTL candidacy
Message-ID:
<CABHH=
5D0-XNG1ebhYEbBSvHf8BMfs0x8tMxw36d9j_AMS5qrEQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

+1

Tim is an excellent and passionate leader, go ahead, Congress :-)

2015-09-17 4:09 GMT+08:00 Ramki_Krishnan@dell.com:

+1 and looking forward to see you in Tokyo.

Thanks,

Ramki

From: Tim Hinrichs [mailto:tim@styra.com]
Sent: Tuesday, September 15, 2015 1:23 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Congress] PTL candidacy

Hi all,

I?m writing to announce my candidacy for Congress PTL for the Mitaka
cycle. I?m excited at the prospect of continuing the development of our
community, our code base, and our integrations with other projects.

This past cycle has been exciting in that we saw several new, consistent
contributors, who actively pushed code, submitted reviews, wrote specs,
and
participated in the mid-cycle meet-up. Additionally, our integration
with
the rest of the OpenStack ecosystem improved with our move to running
tempest tests in the gate instead of manually or with our own CI. The
code
base matured as well, as we rounded out some of the features we added
near
the end of the Kilo cycle. We also began making the most significant
architectural change in the project?s history, in an effort meet our
high-availability and API throughput targets.

I?m looking forward to the Mitaka cycle. My highest priority for the
code
base is completing the architectural changes that we began in Liberty.
These changes are undoubtedly the right way forward for production use
cases, but it is equally important that we make Congress easy to use and
understand for both new developers and new end users. I also plan to
further our integration with the OpenStack ecosystem by better utilizing
the plugin architectures that are available (e.g. devstack and
tempest). I
will also work to begin (or continue) dialogues with other projects that
might benefit from consuming Congress. Finally I?m excited to continue
working with our newest project members, helping them toward becoming
core
contributors.

See you all in Tokyo!

Tim


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/e6eb8e3f/attachment-0001.html
>


Message: 26
Date: Thu, 17 Sep 2015 10:00:38 +0530
From: Abhishek Talwar abhishek.talwar@tcs.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] how to get current memory utilization of
an instance
Message-ID:
<OFE5715C3D.F5F7173F-ON65257EC3.0018C71C-65257EC3.0018C722@tcs.com
>
Content-Type: text/plain; charset="us-ascii"

An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/17a718cc/attachment-0001.html
>


Message: 27
Date: Thu, 17 Sep 2015 15:01:53 +1000
From: Tony Breeds tony@bakeyournoodle.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [all][gate] grende jobs failing.
Message-ID: 20150917050153.GE68449@thor.bakeyournoodle.com
Content-Type: text/plain; charset="utf-8"

Hi all,
The recent relapse of oslo.utils 1.4.1[1] (for juno) is valid in
kilo. The
juno global-requirements for Babel are not compatible with kilo so nothing
can
get through grenade :(

We're working it
https://bugs.launchpad.net/oslo.utils/+bug/1496678

Yours Tony.

[1] https://review.openstack.org/#/c/223909/ sorry :(
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/67c713cc/attachment-0001.pgp
>


Message: 28
Date: Thu, 17 Sep 2015 13:22:23 +0800
From: Ying Chun Guo guoyingc@cn.ibm.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [i18n] PTL candidacy
Message-ID:
<
OF4A738412.8EF74BD1-ON48257EC3.001CE928-48257EC3.001D8417@cn.ibm.com>
Content-Type: text/plain; charset="us-ascii"

I, also known as "Daisy", would like to continue as the I18n PTL,
if you will have me.

I had a great time as the I18n PTL in Liberty,
working with the whole team to make important changes happen.
I would like to have another term to stabilize them.

In June, I18n project became an official project.
Translation contributors are treated the same as code contributors.
30+ active translators are regarded as ATC's in Liberty.
It is a great milestone for I18n team and translators.
We are getting more official and more visible.

In July, we started the trial of the new tool -Zanata,
which is a open source based and OpenStack hosted translation website.
After a long time evaluation and improvement, in September,
we officially migrated translations to Zanata.
49 language teams are created and 130+ translators have been registered.
Now we are running Liberty translation there.

In September, we kicked off Liberty translation, which is under
processing now. It's the first time that we translate on top of Zanata,
the first time that we include Nova in the translation plan,
and the first time we formally use two phases of string freeze.
I'm trying my best to make sure everything is running well.
When Liberty translation is done, we could review how we did and how
to make them better.

In Mitaka, I'm going to focus on blew items:

  1. Get official recoginization to translators
    I'm going to add translation metric in stackalytics,
    and automate the process to award active translators "ATC"

  2. Improve translation quality
    I'm going to improve the list of translation terminologies, promote
    its broad adoption in all language teams.
    I'm going to boost the enablement of translation check website.

  3. Better cooperation with development team and documentation team

I welcome any good ideas which could help the team to achieve
these goals. Hope to get your support for my PTL role in Mitaka.
I am honored to work with everyone to build up a better I18n project.

Thank you.
Daisy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/f4f33730/attachment-0001.html
>


Message: 29
Date: Wed, 16 Sep 2015 22:26:17 -0700
From: Chris Hoge chris@openstack.org
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [defcore] Scoring for DefCore 2016.01
Guideline
Message-ID: 0AC92343-7973-4015-A9C2-E8ADD1B5355B@openstack.org
Content-Type: text/plain; charset=us-ascii

The DefCore Committee is working on scoring capabilities for the upcoming
2016.01 Guideline, a solid draft of which will be available at the Mitaka
summit for community review and will go to the Board of Directors for
approaval in Janaury [1]. The current 2015.07 Guideline [2] covers Nova,
Swift, and Keystone. Scoring for the upcoming Guideline may includes new
capabilities for Neutron, Glance, Cinder, and Heat, as well as
updated capabilities for Keystone and Nova.

As part of our process, we want to encourage the development and user
communities to give feedback on the proposed capability categorizations
and how they are currently graded against the Defcore criteria [3].

Capabilities we're currently considering for possible inclusion are:
Neutron: https://review.openstack.org/#/c/210080/
Glance: https://review.openstack.org/#/c/213353/
Cinder: https://review.openstack.org/#/c/221631/
Heat: https://review.openstack.org/#/c/216983/
Keystone: https://review.openstack.org/#/c/213330/
Nova: https://review.openstack.org/#/c/223915/

We would especially like to thank the PTL's and technical community members
who helped draft the proposed capabilities lists and provided
feedback--your input has been very helpful.

[1]
http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/2015A.rst#n13
[2] http://git.openstack.org/cgit/openstack/defcore/tree/2015.07.json
[3]
http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst


Message: 30
Date: Thu, 17 Sep 2015 15:34:30 +1000
From: Tony Breeds tony@bakeyournoodle.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][gate] grende jobs failing.
Message-ID: 20150917053429.GF68449@thor.bakeyournoodle.com
Content-Type: text/plain; charset="utf-8"

On Thu, Sep 17, 2015 at 03:01:53PM +1000, Tony Breeds wrote:

Hi all,
The recent relapse of oslo.utils 1.4.1[1] (for juno) is valid in
kilo. The
juno global-requirements for Babel are not compatible with kilo so
nothing can
get through grenade :(

We're working it
https://bugs.launchpad.net/oslo.utils/+bug/1496678

Here's my best effort for right now.
https://review.openstack.org/#/c/224429/

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/4fc3d53f/attachment-0001.pgp
>


Message: 31
Date: Thu, 17 Sep 2015 01:58:59 -0400
From: Nikhil Komawar nik.komawar@gmail.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Glance] PTL candidacy
Message-ID: 55FA56A3.4000001@gmail.com
Content-Type: text/plain; charset=utf-8

Hello everyone,

I would like to herewith propose my candidacy for the role of Glance PTL
for the Mitaka release cycle.

I. Personal Commitment

I am a full time upstream OpenStacker at IBM and have recently
transitioned into this role with the condition that I will be given 100%
time to focus on community issues, development and help solve upstream
challenges. I am also committed to giving my full attention to Glance.
Not too long ago, I have had a few conversations with the PTLs of other
projects for either help them better use Glance or for dissolving the
issues they were facing in their projectsw. However, in this cycle I
would like to work with some of you in the capacity of inter-project
liaisons to help better understand the usage and stability of Glance in
respective areas and yet be involved with you in addressing those
issues. I know this is added work that must not go unrewarded so, I
would like to work out a plan with you that will enable distribution of
power (if with more power comes more responsibility, visa versa must
true, making it true claim). It has been enabled in Glance to some
extent & I have learnt other bigger projects implementing this. I would
like to make it a complete reality in Glance. I am also committed to
documenting and improving the current specs process and criterion that
will enable quicker turnaround time.

At IBM, I have the pleasure of being part of team that has some of the
most outstanding OpenStackers and I hope to collaborate more with them
in Mitaka for solving (hard) problems.

II. Liberty

a) Stability

Over 100 bugs were fixed in Liberty (including python-glanceclient,
glance_store and Glance servers) with a relatively small review team.
Glance is gradually improving momentum to help the different code
proposals get time-justice for code reviews. Some features in Kilo
introduced a number security bugs beyond expectations so, the further
development of those features has been slowed down and focus has been
shifted to fix the functionality, making it more stable and secure.
Experimental features showed a smooth progress and close to no issues of
such sort. A close eye on the reviews was kept to ensure so. Any spec
proposals that showed potential security risks, shake stability or
performance or refactor major parts of the code base were given a wait
signal.

b) Performance

I consider them as systematic optimizations and sometimes systematic
improvisations. Major disagreements on the path forward for optimizing
streaming workflows for images data have been sorted out. Many new
proposals were made however, due to lack of early time commitment from
developers they were unable to be seen through. Continued feedback
should be expected for similar proposals for glance_store in early Mitaka.

c) Cross project communications & Process Evolution

I have made an attempt to continually evolve our process to make it more
engaging and community friendly. Now there are three meetings weekly
that are a good place for collaboration on different aspects of Glance.
Either me or a member of the Glance community is at the weekly CPL
meeting to gather feedback from horizontal teams, cross project
decision/efforts etc. as well as input has been provided using Glance?s
perspective. I have had regular chats with Nova PTL on the outstanding
issues of the Images APIs and adoption of v2 Images API by Nova.
Feedback was provided at the DefCore mid-cycle as well as a welcoming
hand was presented for attending Glance mid-cycle (even virtually) for
those who could not make it. In Mitaka, I hope to continue
collaborating with the interested members there as well as in the other
projects. I would like to pay close personal attention to the pressing
matters that need short team resolution like the adoption of v2 API by
Nova and Images API suitable for DefCore. Unfortunately, any of the
existing (half) attempts at fixing this issue have been wasted as they
were breaking some of the fundamental aspects of project. This matter
would need wider input for a fine resolution and a change that would not
break the world; of-course compromise is very likely for some but
doesn?t need to be fundamentally disjoint with the newly established
DefCore standard. It was realized early that a half baked attempt of
making such a critical change would break core of Glance so, I have been
contemplating on the future of the project. More clarity of thought has
been accomplished during the conversations with the TC members, PTLs,
Product WG liaisons etc. and I will continue to gather more feedback in
Mitaka. It has been a pleasure to be part of (collaborating with) teams
that help build very large cloud deployments and I find that experience
valuable for solving this complicated matter. Not only upstream but at
IBM too, I plan to closely interact with the technical and product
leaders of the Public and Private cloud deployment to help solve such
issues. My team at IBM enables me to have such interactions with
veterans of OpenStack.

III. Direction

a) Short Term Goals
There are four short team goals that seem important right away: DefCore
requirements; Nova and Cinder v2 adoption/stability; cadence between
developer and reviewer bandwidth; better collaboration via
documentation, CPL & inter project liaisons power distribution.

b) Mid Term Goals
I think it?s vital that we pin down subtle aspects of v2 API in
mid-term, primarily focus on Images however, at the same time ensure
that all of our APIs are efficient and performant.

The concept of tasks needs to have a clear picture in all the developers
as well as operators viewpoints. There are equally compelling arguments
to make them user centric only, admin only and open to both. Most
important use cases will be taken into account and a plan for tasks will
be setup.

Some of the operators and active developers wish to focus on performance
improvement and reliaiblity of image data delivery ? so this will be
another very important mid-term goal.

Definition of core fundamentals like immutability of images & Glance
architecture seems critical. Also, it is necessary to be aware about the
side-effects of feature proposals that can potentially lead to breaking
changes. It has come to my notice that many a times such proposals are
made and the proposers find it difficult to grasp how the change could
affect Glance. We will try to solve this issue via collaboration and
documentation.

c) Long Term Goals

The long term goals follow the mid-term goals. Solidification of the
Images v2 API and planning long term support for the same. There?s
already some work happening to set a direction for this.

Artifacts and a generic repository ? as per Glance?s mission statement,
this is an important goal. A generic data asset service would be an
excellent one stop shop for users. Possibly evolving in to a Marketplace
like stage for many of OpenStack assets (Artifacts).

Addressing storage and retrieval of Images issues for smaller size data
(Image record in DB) and for larger blobs of data (stored in the backend
store) ? this may be termed as performance problem but as a long term
objective it will be a clear separation of concerns and give ability to
operators to work on image or artifact data in a efficient manner.

VII. Community

Glance community has been traditionally known to be friendly to help new
developers join and it avoids the influx vs. outflux issues. Keeping the
long term objectives in mind this remains important. I will try to keep
it a conducive environment for all concerned individuals. Without losing
hind sight help focus on the short term goals, I will enable specific
individuals to make important calls if it helps move forward with
pressing issues.

VIII. Solving Hard Problems

a) Collaboration

The tradition of pre-summit, within cycle video and face-to-face syncs
will be continued. Inputs of the CPLs, inter-project liaisons will be
encouraged and welcomed. Glance representatives will engage in certain
important projects regarding images related subject matter. Artifacts
representatives will engage in other working groups to make the API more
usable and adoptable. I plan to keep working with the DefCore committee
and PTLs to help bridge the gap of overlapping issues. OpenStack is a
diverse community and so is the Glance team. So, we will focus on
keeping weekly syncs addressing important issues interactively. Overall,
collaboration will be one of the most vital component of this cycle.

b) Themed Focus

The most important themes that come to mind at this point of time are:
getting a standard API for DefCore, interaction with Nova team to enable
v2 adoption, documentation of the features and processes (this will also
help with collaboration), Artifacts and it?s API, performance and
reliablilty & stability. A sub-team leader would be chosen for each of
these themes and periodic sync would be made effective for a good team
effort.

c) Core reviewer bandwidth, their influx and outflux

Glance has had the mis-fortune for losing important and talented
developers time and again due to commitment changes (and not a result of
drive away from the team). We will continue to keep the doors open for
them and if any of the super active OpenStackers wish to become core in
short window, there will be a easier process of doing so. This will help
fix any outstanding bugs, keep the gate steady and help a good momentum
for the release of libraries. Good collaborators have always been good
drivers & it would be wise to continue in that direction. Good
developers have been engaged in Liberty to become part of Glance and I
will continue to do so for Mitaka.

d) One OpenStack

No matter how easy it is to define solo project priorities, we all live
in the single OpenStack realm. Operators have to deploy Glance alongside
other OpenStack services and there is a level of understanding that will
be put in into action while defining Glance priorities so that other
projects are not severely affected. I believe in ?One OpenStack & a
unified vision? and hope you are with me.

Thank you for your consideration in allowing me to continue serving as
PTL for Mitaka cycle.

Nikhil Komawar


Message: 32
Date: Thu, 17 Sep 2015 06:06:57 +0000
From: Samuel Bercovici SamuelB@Radware.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael
Johnson for neutron-lbaas core team
Message-ID:
F36E8145F2571242A675F56CF6096456A069A64E@ILMB1.corp.radware.com
Content-Type: text/plain; charset="utf-8"

And then they were 6 =D>

-Sam.

-----Original Message-----
From: Doug Wiegley [mailto:dougwig@parksidesoftware.com]
Sent: Thursday, September 17, 2015 1:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for
neutron-lbaas core team

Hi all,

As the Lieutenant of the advanced services, I nominate Michael Johnson to
be a member of the neutron-lbaas core reviewer team.

Review stats are in line with other cores[2], and Michael has been
instrumental in both neutron-lbaas and octavia.

Existing cores, please vote +1/-1 for his addition to the team (that?s
Brandon, Phil, Al, and Kyle.)

Thanks,
doug

1.
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
2. http://stackalytics.com/report/contribution/neutron-lbaas/90


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

Message: 33
Date: Wed, 16 Sep 2015 23:07:26 -0700
From: "Ton Ngo" ton@us.ibm.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Magnum] API response on k8s failure
Message-ID: 201509170607.t8H67XWo014648@d01av04.pok.ibm.com
Content-Type: text/plain; charset="us-ascii"

Hi Ryan,
There is a bug opened with a similar failure symptom, although I am
not sure if the cause is the same:
https://bugs.launchpad.net/magnum/+bug/1481889

Trying to use kubectl to deploy the V1 manifest, I get this error message:
Error: unable to recognize "redis-master.yaml": no object named "Pod" is
registered

Clearly the error handling from the k8s handler needs to be improved. If
the bug above is different from what you found, I think opening a new bug
would be best.

Ton Ngo,

From: Adrian Otto adrian.otto@rackspace.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Date: 09/14/2015 05:34 PM
Subject: Re: [openstack-dev] [Magnum] API response on k8s failure

Ryan,

Thanks for sharing this. Sorry you got out to a bumpy start. I suggest you
do file a bug for this against magnum and we can decide how best to handle
it. I can not tell from your email what the kubectl would do with the same
input. We might have an opportunity to make both better.

If you need guidance for how to file a bug, feel free to email me directly
and I can point you in the right direction.

Thanks,

Adrian

On Sep 14, 2015, at 3:05 PM, Ryan Rossiter rlrossit@linux.vnet.ibm.com
wrote:

I was giving a devstacked version of Magnum a try last week, and from a
new user standpoint, I hit a big roadblock that caused me a lot of
confusion. Here's my story:

I was attempting to create a pod in a k8s bay, and I provided it with an
sample manifest from the Kubernetes repo. The Magnum API then returned the
following error to me:

ERROR: 'NoneType' object has no attribute 'host' (HTTP 500)

I hunted down the error to be occurring here [1]. The k8s_api call was
going bad, but conductor was continuing on anyways thinking the k8s API
call went fine. I dug through the API calls to find the true cause of the
error:

{u'status': u'Failure', u'kind': u'Status', u'code': 400, u'apiVersion':
u'v1beta3', u'reason': u'BadRequest', u'message': u'Pod in version v1
cannot be handled as a Pod: no kind "Pod" is registered for version "v1"',
u'metadata': {}}

It turned out the error was because the manifest I was using had
apiVersion v1, not v1beta3. That was very unclear by Magnum originally
sending the 500.

This all does occur within a try, but the k8s API isn't throwing any sort
of exception that can be caught by [2]. Was this caused by a regression in
the k8s client? It looks like the original intention of this was to catch
something going wrong in k8s, and then forward on the message & error code
on to let the magnum API return that.

My question here is: does this classify as a bug? This happens in more
places than just the pod create. It's changing around API returns (quite a
few of them), and I don't know how that is handled in the Magnum project.
If we want to have this done as a blueprint, I can open that up and target
it for Mitaka, and get to work. If it should be opened up as a bug, I can
also do that and start work on it ASAP.

[1]

https://github.com/openstack/magnum/blob/master/magnum/conductor/handlers/k8s_conductor.py#L88-L108

[2]

https://github.com/openstack/magnum/blob/master/magnum/conductor/handlers/k8s_conductor.py#L94

--
Thanks,

Ryan Rossiter (rlrossit)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/3a0c21e5/attachment-0001.html
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/3a0c21e5/attachment-0001.gif
>


Message: 34
Date: Thu, 17 Sep 2015 14:52:36 +0800
From: Li Ma skywalker.nick@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [dragonflow] Low OVS version for Ubuntu
Message-ID:
<CALFEDVcXE18WAWS=
64sOQkyLn6ob2R0Nx+G2jSP3xOo37Zcubg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi all,

I tried to run devstack to deploy dragonflow, but I failed with lower
OVS version.

I used Ubuntu 14.10 server, but the official package of OVS is 2.1.3
which is much lower than the required version 2.3.1+?

So, can anyone provide a Ubuntu repository that contains the correct
OVS packages?

Thanks,
--

Li Ma (Nick)
Email: skywalker.nick@gmail.com


Message: 35
Date: Thu, 17 Sep 2015 15:13:17 +0800
From: Li Ma skywalker.nick@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] RFE process question
Message-ID:
<CALFEDVdLfL9FD01=JbXUJxqfxSF_9T=
KGr8UkkD2FRzSPESUoA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

A reasonable user story. Other than tag, a common description field
for Neutron resources is also usable.

I submitted a RFE bug for review:
https://bugs.launchpad.net/neutron/+bug/1496705


Message: 36
Date: Thu, 17 Sep 2015 10:14:30 +0300
From: mhorban mhorban@mirantis.com
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [oslo][oslo.config] Reloading configuration
of service
Message-ID: 55FA6856.1@mirantis.com
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Josh,

Sounds like a useful idea if projects can plug-in themselves into the
reloading process. I definitely think there needs to be a way for
services to plug-in to this, although I'm not quite sure it will be
sufficient at the current time though.

An example of why:

-

https://github.com/openstack/cinder/blob/stable/kilo/cinder/volume/__init__.py#L24

(unless this module is purged from python and reloaded it will likely
not reload correctly).

Likely these can all be easily fixed (I just don't know how many of
those exist in the various projects); but I guess we have to start
somewhere so getting the underlying code able to be reloaded is a first
step of likely many.

Each of openstack component should contain code responsible for
reloading such objects.
What objects will be reloaded? It depends of inspire and desire of
developers/users.
Writing such code is a second step.

Marian


Message: 37
Date: Thu, 17 Sep 2015 15:16:50 +0800
From: Li Ma skywalker.nick@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] Please help review this RFE
Message-ID:
<CALFEDVeR=s81c9ux7bWDv=+
x8YqwemUCSMfBmMhHYRky_ja7xA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi Neutron folks,

I'd like to introduce a pure python-driven network configuration
library to Neutron. A discussion just started in the RFE ticket [1].
I'd like to get feedback on this proposal.

[1]: https://bugs.launchpad.net/neutron/+bug/1492714

Take a look and let me know your thoughts.
--

Li Ma (Nick)
Email: skywalker.nick@gmail.com


Message: 38
Date: Thu, 17 Sep 2015 12:54:36 +0530
From: Sudipto Biswas sbiswas7@linux.vnet.ibm.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [dragonflow] Low OVS version for Ubuntu
Message-ID: 55FA6AB4.5030605@linux.vnet.ibm.com
Content-Type: text/plain; charset=windows-1252; format=flowed

On Thursday 17 September 2015 12:22 PM, Li Ma wrote:

Hi all,

I tried to run devstack to deploy dragonflow, but I failed with lower
OVS version.

I used Ubuntu 14.10 server, but the official package of OVS is 2.1.3
which is much lower than the required version 2.3.1+?

So, can anyone provide a Ubuntu repository that contains the correct
OVS packages?

Why don't you just build the OVS you want from here:
http://openvswitch.org/download/

Thanks,


Message: 39
Date: Thu, 17 Sep 2015 10:26:28 +0300
From: mhorban mhorban@mirantis.com
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [oslo][oslo.config] Reloading configuration
of service
Message-ID: 55FA6B24.5000602@mirantis.com
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Doug,

Rather than building hooks into oslo.config, why don't we build them
into the thing that is catching the signal. That way the app can do lots
of things in response to a signal, and one of them might be reloading
the configuration.

Hm... Yes... It is really stupid idea to put reloading hook into
oslo.config.
I'll move that hook mechanism into oslo.service. oslo.service is
responsible for catching/handling signals.

Is it enough to have one callback function? Or should I must add ability
to register many different callback functions?

What is your point of view?

Marian


Message: 40
Date: Thu, 17 Sep 2015 09:28:11 +0200
From: Yanis Guenane yguenane@redhat.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [puppet] service default value functions
Message-ID: 55FA6B8B.1090203@redhat.com
Content-Type: text/plain; charset=windows-1252

On 09/16/2015 09:39 PM, Emilien Macchi wrote:

On 09/16/2015 12:53 PM, Alex Schultz wrote:

Hey puppet folks,

Based on the meeting yesterday[0], I had proposed creating a parser
function called isservicedefault[1] to validate if a variable matched
our agreed upon value of ''. This got me thinking
about how can we maybe not use the arbitrary string throughout the
puppet that can not easily be validated. So I tested creating another
puppet function named service_default[2] to replace the use of '' throughout all the puppet modules. My tests seemed to
indicate that you can use a parser function as parameter default for
classes.

I wanted to send a note to gather comments around the second function.
When we originally discussed what to use to designate for a service's
default configuration, I really didn't like using an arbitrary string
since it's hard to parse and validate. I think leveraging a function
might be better since it is something that can be validated via tests
and a syntax checker. Thoughts?
Let me add your attempt to make it work in puppet-cinder:
https://review.openstack.org/#/c/224277

I like the proposal, +1.
Alex, thank you for this proposal.

I like your approach :

  • as it will make writing manifest more idiomatic.

$foo = servicedefault() with if isservice_default($foo) { } reads
better than
$foo = '' with if $foo == ''.

  • if for any reason, hopefully this shouldn't happen but we need to
    change the value,
    it will happen only on few places. (less commit to review)

  • the end result is the exact same one as the one we have today.

For me it's a go, let's see what the other have to say about it

Thank you,


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Message: 41
Date: Thu, 17 Sep 2015 09:48:59 +0200
From: Adam Heczko aheczko@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Fuel] Bugs which we should accept in 7.0
after Hard Code Freeze
Message-ID:
<CAJciqMyBC_=
5AmWjwHK53Wa9pZPL77vctm-f-MEGyADh5hHvFA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi, I'd like to ask for fixing these security related bugs in stable/7.0
branch:

https://bugs.launchpad.net/fuel/+bug/1496407
https://bugs.launchpad.net/fuel/+bug/1488732

Both are fuel-library related tasks, it is Apache2 and NTPD configuration
lifting.

Thanks,

Adam

On Tue, Sep 15, 2015 at 12:19 AM, Mike Scherbakov <
mscherbakov@mirantis.com>
wrote:

Thanks Andrew.
Team, if there are any disagreements - let's discuss it. Otherwise, I
think we should be just strict and follow defined process. We can deliver
high priority bugfixes in updates channel later if needed.

I hope that reasoning is clear for everything. Every bugfix has a
potential to break something. It's basically a risk.

On Mon, Sep 14, 2015 at 8:57 AM Andrew Maksimov amaksimov@mirantis.com
wrote:

Hi Everyone!

I would like to reiterate the bugfix process after Hard Code Freeze.
According to our HCF definition [1] we should only merge fixes for
Critical bugs to stable/7.0 branch, High and lower priority bugs
should NOT be accepted to stable/7.0 branch anymore.
Also we should accept patches for critical bugs to stable/7.0 branch
only after the corresponding patchset with same ChangeID was accepted
into
master.

[1] - https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze

Regards,
Andrey Maximov
Fuel Project Manager


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

--
Mike Scherbakov

mihgen


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

--
Adam Heczko
Security Engineer @ Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/eb282b28/attachment-0001.html
>


Message: 42
Date: Thu, 17 Sep 2015 18:03:53 +1000
From: Tony Breeds tony@bakeyournoodle.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][gate] grende jobs failing.
Message-ID: 20150917080353.GA72725@thor.bakeyournoodle.com
Content-Type: text/plain; charset="utf-8"

On Thu, Sep 17, 2015 at 03:34:30PM +1000, Tony Breeds wrote:

On Thu, Sep 17, 2015 at 03:01:53PM +1000, Tony Breeds wrote:

Hi all,
The recent relapse of oslo.utils 1.4.1[1] (for juno) is valid in
kilo. The
juno global-requirements for Babel are not compatible with kilo so
nothing can
get through grenade :(

We're working it
https://bugs.launchpad.net/oslo.utils/+bug/1496678

Here's my best effort for right now.
https://review.openstack.org/#/c/224429/

For those playing along at home the new plan is to:
1. Release a version of oslo.utils with the kilo requirements
This needs to be done as a revert because 1.4.2 must follow 1.4.1
- https://review.openstack.org/#/c/224472/
2 Tag that as 1.4.2

Then the gate should be okay again, while the stable team (and me) work
out how
to fix juno without breaking kilo.

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/1a6cbef7/attachment-0001.pgp
>


Message: 43
Date: Thu, 17 Sep 2015 16:13:24 +0800
From: Hou Gang HG Liu liuhoug@cn.ibm.com
To: jaypipes@gmail.com
Cc: openstack-dev@lists.openstack.org
Subject: [openstack-dev] questions about nova compute monitors
extensions
Message-ID:
<
OFDB00AB2C.88557596-ON48257EC3.002CD29A-48257EC3.002D4C16@cn.ibm.com>
Content-Type: text/plain; charset="gb2312"

Hi Jay,

I notice nova compute monitor now only tries to load monitors with
namespace "nova.compute.monitors.cpu", and only one monitor in one
namespace can be enabled(
https://review.openstack.org/#/c/209499/6/nova/compute/monitors/__init__.py
).

Is there a plan to make MonitorHandler.NAMESPACES configurable or just
hard code constraint as it is now? And how to make compute monitor support
user defined as it was?

Thanks!
B.R

Hougang Liu ?????
Developer - IBM Platform Resource Scheduler
Systems and Technology Group

Mobile: 86-13519121974 | Phone: 86-29-68797023 | Tie-Line: 87023 ??
????????42?????3?
E-mail: liuhoug@cn.ibm.com Xian, Shaanxi
Province 710075, China

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/cd7ad50b/attachment-0001.html
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/cd7ad50b/attachment-0001.gif
>


Message: 44
Date: Thu, 17 Sep 2015 11:17:09 +0300
From: Gal Sagie gal.sagie@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org, Eran Gampel
Eran.Gampel@huawei.com
Subject: Re: [openstack-dev] [dragonflow] Low OVS version for Ubuntu
Message-ID:
<
CAG9LJa554aMjAF06G8U5AiGTOuZ1ODtci+6ykfNO-VaetB4Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello Li Ma,

Dragonflow uses OpenFlow1.3 to communicate with OVS and thats why we need
OVS 2.3.1.
As suggested you can build it from source.
For Fedora 21 OVS2.3.1 is part of the default yum repository.

You can ping me on IRC (gsagie at freenode) if you need any additional help
how
to compile OVS.

Thanks
Gal.

On Thu, Sep 17, 2015 at 10:24 AM, Sudipto Biswas <
sbiswas7@linux.vnet.ibm.com> wrote:

On Thursday 17 September 2015 12:22 PM, Li Ma wrote:

Hi all,

I tried to run devstack to deploy dragonflow, but I failed with lower
OVS version.

I used Ubuntu 14.10 server, but the official package of OVS is 2.1.3
which is much lower than the required version 2.3.1+?

So, can anyone provide a Ubuntu repository that contains the correct
OVS packages?

Why don't you just build the OVS you want from here:
http://openvswitch.org/download/

Thanks,
>


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

--
Best Regards ,

The G.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/7ba72dce/attachment-0001.html
>


Message: 45
Date: Thu, 17 Sep 2015 12:00:22 +0300
From: Duncan Thomas duncan.thomas@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [cinder] LVM snapshot performance issue
-- why isn't thin provisioning the default?
Message-ID:
<CAOyZ2aFFnsrY6AaMe7bYrff5iGfQHcM7ZZtP=_
yXYxY-75aqSw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On 16 September 2015 at 23:43, Eric Harney eharney@redhat.com wrote:

Currently, at least some options set in [DEFAULT] don't apply to
per-driver sections, and require you to set them in the driver section
as well.

This is extremely confusing behaviour. Do you have any examples? I'm not
sure if we can fix it without breaking people's existing configs but I
think it is worth trying. I'll add it to the list of things to talk about
briefly in Tokyo.

--
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/e6e722e1/attachment-0001.html
>


Message: 46
Date: Thu, 17 Sep 2015 07:18:32 +0000
From: Hongbin Lu hongbin.lu@huawei.com
To: "openstack-dev@lists.openstack.org"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [magnum][ptl] Magnum PTL Candidacy
Message-ID:
<
0957CD8F4B55C0418161614FEC580D6BCE4960@SZXEMI503-MBS.china.huawei.com>

Content-Type: text/plain; charset="us-ascii"

Hi all,

I would like to announce my candidacy for the PTL position of Magnum.

I involved in Magnum project starting from December 2014. At that time,
Magnum's code base is much smaller than right now. Since then, I worked
with a diverse set of team members to land features, discuss the roadmap,
fix the gate, do pre-release test, fix the documentation, etc.. Thanks to
our team efforts, in the past a few months, I saw important features were
landed one after another, which I really proud of.

To address the question why I am a good candidate for Magnum, here are the
key reasons:
* I contributed a lot to Magnum's code base and feature set.
* I am familiar with every aspects of the project, and understand both the
big picture and technical details.
* I will have time and resources to take the PTL responsibility, mostly
because I am a full time allocated to this project.
* I love container.
* I care the project.
Here is more details of my involvement in the project:
http://stackalytics.com/?module=magnum-group
https://github.com/openstack/magnum/graphs/contributors

In my opinion, Magnum needs to focus on the following in the next cycle:
* Production ready: Work on everything that are possible to make it happen.
* Baremetal: Complete and optimize our Ironic integration to enable
running containers on baremetal.
* Container network: deliver a network solution that is high performance
and customizable.
* UI: Integrate with Horizon to give users a friendly interface to use
Magnum.
* Pluggable COE: A pluggable design is a key feature for users to
customize Magnum, which is always the case.
* Grow community: Attract more contributors to contribute to Magnum.

If elected, I will strictly follow the principal of being a OpenStack
project, especially the four opens. The direction of the project will be
community-driven as always.

I hope you will give me an opportunity to serve as Magnum's PTL in the
next cycle.

Best regards,
Hongbin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/6a41cb83/attachment.html
>



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

End of OpenStack-dev Digest, Vol 41, Issue 49



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Oct 5, 2015 in openstack-dev by santosh_parihar (120 points)  

2 Responses

0 votes
responded Oct 5, 2015 by Andrew_Woodward (6,960 points)   2 3 5
0 votes

[ Was: Re: [openstack-dev] OpenStack-dev Digest, Vol 41, Issue 49]

Santosh Parihar,

This implies that the nodes are (in order of most to least likely):
a) currently offline
b) un-accessible from the fuel master node
c) the mcollective agent is not running on them
d) rabbitmq on the fuel node (rabbitmq container) is not functioning
properly

Fuel uses mcollective (MCO) to issue commands to remote nodes.
You can start by pining the nodes, from the CLI you can issue fuel node
and it will show the nodes id, and IP address. From there you can use mco ping to determine if mcollective can talk to the nodes. From there you can
triage individual nodes connectivity, or restart them. Alternately you can
investigate and restart the mcollective and or rabbitmq containers.

We are also on IRC #Fuel on irc.freenode.net. We have alot of the European
folks on around when you posted this message so you can drop a line in
there if you would like to get some more interactive help.

-
Andrew
Fuel Community.

On Mon, Oct 5, 2015 at 1:55 AM santosh parihar santosh.parihar8@gmail.com
wrote:

Topic - Fuel

Hi,

My deployment is failing beacuse of following reason :

Verification failed.
Method verify_networks. Network verification not avaliable because nodes
["3", "4", "6", "7"] not avaliable via mcollective. Inspect Astute logs for
the details

anybody can help here ?

--

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 5, 2015 by Andrew_Woodward (6,960 points)   2 3 5
...