Re: [openstack-dev] [CI] How to set a proxy for zuul.

[Tang Chen]

On 07/14/2015 01:46 PM, Abhishek Shrivastava wrote:

Instead of it use reusable_node option.


Thanks. Problem resolved. :)

BTW, single_use_node is written in layout.yaml by default.
If it doesn't exist anymore, do we need a patch to fix it ?

For someone who uses CI for the first time, it is really a problem..

And also, if I want to post patch for zuul, where should I post the patch ?

Thanks.



On Tue, Jul 14, 2015 at 9:12 AM, Tang Chen tangc...@cn.fujitsu.com 
mailto:tangc...@cn.fujitsu.com wrote:


Hi Abhishek, All,

I found the problem.

My /etc/zuul/layout/layout.yaml has the following config:

jobs:
  - name: ^dsvm-tempest.*$
parameter-function: single_use_node

But in _parseConfig() in zuul/scheduler.py, it failed to find
single_use_node().

fname = config_job.get('parameter-function', None)
if fname:
func = config_env.get(fname, None)
if not func:
raise Exception(Unable to find function %s %
fname)

So projects section was not parsed.

Does anyone know why ?

Thanks.




On 07/14/2015 10:54 AM, Tang Chen wrote:

Hi Abhishek,

I printed the self.layout.projects in zuul/scheduler.py, it is empty.
So the project was not found.

But I did do the jenkins-jobs --flush-cache update
/etc/jenkins_jobs/config/
And I did configure openstack-dev/sandbox in layout.yaml.

Do you have any idea what's wrong here ?

Thanks.


On 07/13/2015 05:58 PM, Tang Chen wrote:


On 07/13/2015 04:35 PM, Abhishek Shrivastava wrote:

Updating jobs using sudo jenkins-jobs --flush-cache update
/etc/jenkins_jobs/config/. Also update the myvendor in
examples.yaml



Sorry, I updated the jobs, restart the whole machine. But it
still doesn't work.

By the way, there is no vendor in examples.yaml.

It is still this error: Project openstack-dev/sandbox not found

Anything else should I pay attention to?

Thanks.



On Mon, Jul 13, 2015 at 1:45 PM, Tang Chen
tangc...@cn.fujitsu.com mailto:tangc...@cn.fujitsu.com wrote:


On 07/13/2015 03:50 PM, Abhishek Shrivastava wrote:

Use tester or something, also are you updating the jobs or
not?


I used tester as my vendor. It doesn't work.

And what do you mean by updating the jobs ? I built the
noop-check-cimmunitication
job once in Jenkins UI. Does it matter ? All the others are
not touched.

And referring to the error, Project openstack-dev/sandbox
not found, it seems like
somewhere the project name was wrong.

right ?


Thanks.



On Mon, Jul 13, 2015 at 1:16 PM, Tang Chen
tangc...@cn.fujitsu.com mailto:tangc...@cn.fujitsu.com
wrote:

Hi Abhishek,

Thanks for the quick reply.

On 07/13/2015 03:16 PM, Abhishek Shrivastava wrote:

Also check that Gearman is connecting or not through
Jenkins UI.

On Mon, Jul 13, 2015 at 12:45 PM, Abhishek
Shrivastava abhis...@cloudbyte.com
mailto:abhis...@cloudbyte.com wrote:

First of all, change the vendor to your vendor
name in /etc/jenkins_jobs/config/projects.yaml
file. Also, restart the zuul and zuul merger.



I did the check. Gearman plugin works find. In Jenkins
UI, I tested the connection, and it succeeded.

And also, I restarted zuul and zuul merger every time
I modified the yaml files.

But it doesn't work.

And the vendor, does that matter ?  And what vendor
name should I provide ?
I cannot find any vendor info in my Gerrit service
account profile.
For example, is XXX OK ?

Thanks.





On Mon, Jul 13, 2015 at 12:29 PM, Tang Chen
tangc...@cn.fujitsu.com
mailto:tangc...@cn.fujitsu.com wrote:

Hi all,

I have constructed my CI system.
When I tested it with sandbox project, I
posted a patch to Gerrit.

https://review.openstack.org/201002

But I got this error in zuul scheduler:

2015-07-14 14:07:24,921 DEBUG zuul.Scheduler:
Run handler awake
2015-07-14 14:07:24,921 DEBUG zuul.Scheduler:
Fetching trigger event
2015-07-14 14:07:24,922 DEBUG zuul.Scheduler:
Processing trigger event TriggerEvent
comment-added openstack-dev/sandbox master
201002,1 Verified:1
2015-07-14 14:07:24,922 DEBUG zuul.Scheduler:
Project openstack-dev/sandbox not found
   

Re: [openstack-dev] [CI] How to set a proxy for zuul.

[Abhishek Shrivastava]

Also if you want to change it you will need to talk with Asselin Ramy who
is the owner of the repo you followed.

On Tue, Jul 14, 2015 at 12:18 PM, Abhishek Shrivastava 
abhis...@cloudbyte.com wrote:

 ​Basically it is not required, and if you see /etc/jenkins_jobs/config
 folder you will find one dsvm-cinder-tempest.yaml which is to be used
 basically not examples.yaml. So its not an issue.​

 On Tue, Jul 14, 2015 at 12:07 PM, Tang Chen tangc...@cn.fujitsu.com
 wrote:


 On 07/14/2015 01:46 PM, Abhishek Shrivastava wrote:

  Instead of it use reusable_node option.


 Thanks. Problem resolved. :)

 BTW, single_use_node is written in layout.yaml by default.
 If it doesn't exist anymore, do we need a patch to fix it ?

 For someone who uses CI for the first time, it is really a problem..

 And also, if I want to post patch for zuul, where should I post the patch
 ?

 Thanks.



 On Tue, Jul 14, 2015 at 9:12 AM, Tang Chen tangc...@cn.fujitsu.com
 wrote:

  Hi Abhishek, All,

 I found the problem.

 My /etc/zuul/layout/layout.yaml has the following config:

 jobs:
   - name: ^dsvm-tempest.*$
 parameter-function: single_use_node

 But in _parseConfig() in zuul/scheduler.py, it failed to find
 single_use_node().

 fname = config_job.get('parameter-function', None)
 if fname:
 func = config_env.get(fname, None)
 if not func:
 raise Exception(Unable to find function %s % fname)

 So projects section was not parsed.

 Does anyone know why ?

 Thanks.




 On 07/14/2015 10:54 AM, Tang Chen wrote:

 Hi Abhishek,

 I printed the self.layout.projects in zuul/scheduler.py, it is empty.
 So the project was not found.

 But I did do the jenkins-jobs --flush-cache update
 /etc/jenkins_jobs/config/
 And I did configure openstack-dev/sandbox in layout.yaml.

 Do you have any idea what's wrong here ?

 Thanks.


 On 07/13/2015 05:58 PM, Tang Chen wrote:


 On 07/13/2015 04:35 PM, Abhishek Shrivastava wrote:

  Updating jobs using sudo jenkins-jobs --flush-cache update
 /etc/jenkins_jobs/config/. Also update the myvendor in examples.yaml


 Sorry, I updated the jobs, restart the whole machine. But it still
 doesn't work.

 By the way, there is no vendor in examples.yaml.

 It is still this error: Project openstack-dev/sandbox not found

 Anything else should I pay attention to?

 Thanks.


 On Mon, Jul 13, 2015 at 1:45 PM, Tang Chen tangc...@cn.fujitsu.com
 wrote:


 On 07/13/2015 03:50 PM, Abhishek Shrivastava wrote:

  ​ Use tester or something, also are you updating the jobs or not?​


  I used tester as my vendor. It doesn't work.

 And what do you mean by updating the jobs ? I built the
 noop-check-cimmunitication
 job once in Jenkins UI. Does it matter ? All the others are not touched.

 And referring to the error, Project openstack-dev/sandbox not found,
 it seems like
 somewhere the project name was wrong.

 right ?


 Thanks.


 On Mon, Jul 13, 2015 at 1:16 PM, Tang Chen tangc...@cn.fujitsu.com
 wrote:

  Hi Abhishek,

 Thanks for the quick reply.

 On 07/13/2015 03:16 PM, Abhishek Shrivastava wrote:

  Also check that Gearman is connecting or not through Jenkins UI.

 On Mon, Jul 13, 2015 at 12:45 PM, Abhishek Shrivastava 
 abhis...@cloudbyte.com wrote:

  First of all, change the vendor to your vendor name in
 /etc/jenkins_jobs/config/projects.yaml file. Also, restart the zuul
 and zuul merger.


  I did the check. Gearman plugin works find. In Jenkins UI, I tested
 the connection, and it succeeded.

 And also, I restarted zuul and zuul merger every time I modified the
 yaml files.

 But it doesn't work.

 And the vendor, does that matter ?  And what vendor name should I
 provide ?
 I cannot find any vendor info in my Gerrit service account profile.
 For example, is XXX OK ?

 Thanks.




 On Mon, Jul 13, 2015 at 12:29 PM, Tang Chen tangc...@cn.fujitsu.com
 wrote:

 Hi all,

 I have constructed my CI system.
 When I tested it with sandbox project, I posted a patch to Gerrit.

 https://review.openstack.org/201002

 But I got this error in zuul scheduler:

 2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Run handler awake
 2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Fetching trigger event
 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Processing trigger
 event TriggerEvent comment-added openstack-dev/sandbox master 201002,1
 Verified:1
 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Project
 openstack-dev/sandbox not found
 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Run handler sleeping


 My /etc/zuul/layout/layout.yaml looks like this:

 projects:
   - name: openstack-dev/sandbox
 check:
   - noop-check-communication


 My /etc/jenkins_jobs/config/projects.yaml looks like this:

 - project:
 name: sandbox
 github-org: openstack-dev
 node: master
 vendor: myvendor

 jobs:
 - noop-check-communication
 - dsvm-tempest-full:
 node: 'devstack_slave || devstack-precise-check || 

[openstack-dev] [neutron][security-group] rules for filter mac-addresses

[yan_xing...@163.com]

Hi, all:

Here is a requirement: deny/permit incoming packets on VM by mac addresses,
I have tried to find better method than modifying neutron code, but failed.
Any suggesion is grateful. Thank you.

Yan.



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

Re: [openstack-dev] [stackforge][deb][packges] Upstream repositories for OpenStack deb “server” packages

[Hayes, Graham]

On 07/13/2015 08:44 PM, Igor Yozhikov wrote:
Hello everyone.

 During the Liberty summit in Vancouver, the idea to maintain OpenStack 
packages for Debian and Ubuntu on upstream infra sparked. As part of the 
Openstack and Debian community we still want to push for it. Instead of trying 
to directly go for the /openstack namespace, we currently want to start with 
smaller baby steps, using Stackforge. Mostly, it is server packages for Debian 
which we want to see maintained there. All of the dependencies (including Oslo 
libraries and python-*client) will continue to be maintained using 
git.debian.orghttp://git.debian.org, as a shared effort between Debian and 
Ubuntu.

Purpose:

  *   One centralized place at stackforge to maintain package build 
manifests/specs for main OpenStack projects.

  *   Stackforge already has gerrit where could be attached additional gates 
for building and testing OpenStack packages for deb based Linux distributions.

  *   All changes related to the ways of how one or another OpenStack project 
should be installed would be represented or proposed to one place. So not only 
famous package maintainers can work on build manifests for packages, but also 
the entire community interested in packaging of OpenStack projects. Also this 
place could become as main base for packages for all deb based Linux 
distributions like Debian and Ubuntu.

  *   Package build manifests could be reviewed or adjusted not only by package 
maintainers, but also by python developers, that are writing OpenStack code and 
that's could be very valuable due to possible changes in configuration, paths 
and so on.


Projects list:

Here I propose list of OpenStack projects, it consists of about 25 of projects 
which of course would be changed with time due to possible birth of new 
projects .

Project name


Possible stackforge repository


ceilometer


http://github.com/stackforge/deb-ceilometer


ceilometermiddleware


http://github.com/stackforge/deb-ceilometermiddleware


cinder


http://github.com/stackforge/deb-cinder


glance


http://github.com/stackforge/deb-glance


glance_store


http://github.com/stackforge/deb-glance_store


heat


http://github.com/stackforge/deb-heat


horizon


http://github.com/stackforge/deb-horizon


ironic


http://github.com/stackforge/deb-ironic


keystone


http://github.com/stackforge/deb-keystone


keystonemiddleware


http://github.com/stackforge/deb-keystonemiddleware


mistral


http://github.com/stackforge/deb-mistral


mistral-dashboard


http://github.com/stackforge/deb-mistral-dashboard


murano


http://github.com/stackforge/deb-murano


murano-dashboard


http://github.com/stackforge/deb-murano-dashboard


neutron


http://github.com/stackforge/deb-neutron


neutron-fwaas


http://github.com/stackforge/deb-neutron-fwaas


neutron-lbaas


http://github.com/stackforge/deb-neutron-lbaas


neutron-vpnaas


http://github.com/stackforge/deb-neutron-vpnaas


nova


http://github.com/stackforge/deb-nova


rally


http://github.com/stackforge/deb-rally


sahara


http://github.com/stackforge/deb-sahara


sahara-dashboard


http://github.com/stackforge/deb-sahara-dashboard


swift


http://github.com/stackforge/deb-swift


tempest


http://github.com/stackforge/deb-tempest


trove


http://github.com/stackforge/deb-trove




Thanks,
Igor Yozhikov
Senior Deployment Engineer
at Mirantishttp://www.mirantis.com
skype: igor.yozhikov
cellular: +7 901 5331200
slack: iyozhikov
http://www.hp.com/
 You are missing designate (which is already packaged by both Debian and 
Ubuntu). We also now have a dashboard repo, along the same lines as sahara, 
mistral and murano.

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

Re: [openstack-dev] [all][heat][oslo] Public show and validation clients methods

[Sergey Kraynev]

Doug, Terry.

Thank you for the feedback.
I will create a BP with list of desired public methods and will add all
projects to it.

Regards,
Sergey.

On 9 July 2015 at 21:20, Doug Hellmann d...@doughellmann.com wrote:

 Excerpts from Sergey Kraynev's message of 2015-07-09 18:26:09 +0300:
  Hi community.
 
  I want to raise couple questions about openstack clients.
  In Heat we use other python-*clients for manipulating service's
 resources,
  but some stuff placed in shell.py modules and we are forced to duplicate
  some existing code.
 
  There are couple examples which I met last time:
   - getting resource by name or id
 
  All clients implement this logic in the shell.py module and it's not
  possible to re-use it from client
  directly as single call of some function resolve_by_name_or_id
  (unfortunately same is for Heat too ). As result all external developers
  (and we too as orchestration tool) should copy logic in our repos and
  implement similar resolve methods for all services/resources.
 
  - show command for clients
 
  some of clients use base Resource class and they have ._info attribute,
  but it's private and use it is not right too. But I did not see another
  solution, because clients have not some *_show public method for it too
  (except neutron :) ). Also there is additional issue, when clients use
  their own classes, without this attribute, e.g. glance v2.
 
  So my question: can we create mentioned above public methods for such
 stuff
  and make it as standard for all clients or may be discuss list of common
  public interfaces for all clients?

 Until the SDK is ready for use, adding public methods or attributes
 seems like the best approach.

 Doug

 
  If it was raised early please point me, because this issue is really
  painful, when you try to implement
  common approach for all projects.
 
  Regards,
  Sergey.

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

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

[openstack-dev] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Sean Dague]

I just saw this Nova review come in -
https://review.openstack.org/#/c/200908

Why are we merging 2.6 requirements for projects that don't support 2.6?
That seems potentially confusing to end users that now think the project
does, because there are still references in the code.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/14/2015 01:46 AM, Perry, Sean wrote:
 -Original Message- From: Doug Hellmann
 [mailto:d...@doughellmann.com] Sent: Monday, July 13, 2015 3:41
 PM To: openstack-dev Subject: Re: [openstack-dev] [all] Time to
 remove Python2.6 jobs from master
 
 Excerpts from Robert Collins's message of 2015-07-14 09:05:43
 +1200:
 On 14 July 2015 at 02:10, Jeremy Stanley fu...@yuggoth.org
 wrote:
 On 2015-07-13 09:39:36 -0400 (-0400), Doug Hellmann wrote: 
 [...]
 On the other hand, how much longer will we be supporting
 Juno? A matter of months, right?
 
 The reason it's being brought up again at this point is to
 ask whether it's more important that we keep master
 clients/libs working with 2.6 for several more months, or be
 able to push forward with our constraints overhaul between
 now and then. I'll be hard to have the necessary tooling in
 place before the liberty release if we can't actually use it
 before then (since that's roughly when juno EOL is
 scheduled).
 
 Additional detail: - generating 2.6 pins for global
 requirements requires access to 2.6 where the periodic job runs
 *and where devs are generating updates*. - so that means docker
 or lxc or something in both the CI system and widely available
 for devs.
 
 So its a non-trivial impact; we can do it to move things
 forward, but it would be a lot cheaper not to.
 
 I don't *want* to keep 2.6 support around, and I do understand
 that the requirements work will be made easier.  I'm just trying
 to understand what other impact dropping it will have.
 
 
 It will break RHEL 5 (maybe early 6 too) and older RH systems.
 Ubuntu older than 9 I think (which is beyond unsupported). Not sure
 about other Linux dists.
 
 Basically if RHEL 5 is no longer a valid target and we are sure all
 of the 6s have updated then let's nuke it from orbit.
 

I don't believe there was any release of RHEL-OSP that targeted RHEL
5. As for RHEL 6, the last version that got support for it was OSP5
which is based on Icehouse.

Speaking of RDO, there were attempts to get nova pieces of Juno
backported to RHEL 6 (mostly for CERN). Other than that, I don't think
anyone considers to run anything Kilo+ on RHEL 6, and it will probably
fail to work properly since a lot of underlying platform components in
RHEL 6 would be not ready for new features. (RHEL-OSP could
potentially get all the needed pieces in place, but there was a
decision not to go this route and instead require RHEL 7 for anything
Juno+).

Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVpMlOAAoJEC5aWaUY1u57aqMH/jUqVjZeYTFGIG5ncxU62IuU
Jenu/c5GaGiwMdU4dDG4x25hH6NRN3vNmbXE6oF5HrkbCq7oqih7IjoTI/3Wfo6U
Pwk951VU986duN8syxH+dINWZiOrZ8UNDgO2VI3Tn15TUG/S3eZtMTuM9BHoLn2K
cQYlqZrKQnKVK+zNHdZI7X58P728BNeWONUl5ry7mwOZcWDs7PzvsGJ1t8zrDsE4
sGT3QT3x9VCi+tVD17DW7ZuBA+W1oVtNp3RdDkIN5fsaSE0WDZPr9PPW6jIxHNKo
BP+GS7GPvqZEOK2A4I1foZg6tpkDYlxQo1D5Pz7Ep/9LIDahvE5EUQHRQoUPVH8=
=CuFo
-END PGP SIGNATURE-

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

[openstack-dev] [neutron] [ml2] Any other patch needed for hierarchical port binding?

[loy wolfe]

We want to try hierarchical port binding for some TOR vtep. However it
seems that the patch [1] could not be applied directly onto JUNO
release. So are there any other patch needed when merging this patch?

Thanks a lot!

[1] https://blueprints.launchpad.net/neutron/+spec/ml2-hierarchical-port-binding

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

[openstack-dev] [nova] Reminder: July 16 is non-priority feature proposal freeze

[John Garbutt]

Hi,

Please note, the non-priority feature freeze is on: July 30

Blueprint assignees (as always, but especially now), please update
your blueprint to:
* NeedsCodeReview, once all your code ready for review
* Implemented, once all your code has merged
Not doing this, will force me to guess randomly, which is unlikely to go well.

This proposal freeze is designed to optimise the number of completed
blueprints by the above freeze date. This freeze is to ensure the
priority items for Liberty get the attention they need. For more
details, please see:
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Non-priority_Blueprint_Feature_Freeze
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Why_is_there_a_non-priority_Feature_Freeze_in_Nova.3F

I am expecting zero proposal freeze exceptions at this point, given
the amount of really useful features that are already up for review.
Please contact me directly, ideally on IRC, if you need an exception.

Many thanks,
John

PS
There are some good proposals being drawn up for an alternative
process to the non-priority feature proposal freeze:
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Runways
We will discuss these ideas, and more, during the midcycle, in the
hope we can get some agreement (and work) on a new process, before the
start of the M release.

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

Re: [openstack-dev] [all][tests] Fix it friday! [mock failure in CI]

[Kevin Benton]

Oh, no I didn't. By the time I got around to it I saw 264 and figured that
would cover the issue.

On Mon, Jul 13, 2015 at 7:33 PM, Robert Collins robe...@robertcollins.net
wrote:

 On 10 July 2015 at 22:07, Kevin Benton blak...@gmail.com wrote:
  No prob. The fixes for Neutron were relatively trivial.
  https://review.openstack.org/#/c/200420/
 
  The only one that was a bit surprising was the failure of autospec in
 this
  file:
 
 https://review.openstack.org/#/c/200420/4/neutron/tests/unit/services/metering/agents/test_metering_agent.py
 
  It was coming back with argument count mismatch failures. It seems like
 the
  log decorator[1] trips up autospec in the new version.
 
  1.
 
 https://github.com/openstack/neutron/blob/master/neutron/services/metering/drivers/noop/noop_driver.py#L22

 Did you file a bug for that on mock? I don't recall seeing one.

 https://github.com/testing-cabal/mock/issues/264 has a patch upstream
 and it works on mock itself, so I'm applying that to cPython and
 backporting now.

 -Rob

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




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

Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master

[Luigi Toscano]

On Tuesday 14 of July 2015 10:33:18 Ihar Hrachyshka wrote:
 On 07/14/2015 01:46 AM, Perry, Sean wrote:
  -Original Message- From: Doug Hellmann
  
  I don't *want* to keep 2.6 support around, and I do understand
  that the requirements work will be made easier.  I'm just trying
  to understand what other impact dropping it will have.
  
  It will break RHEL 5 (maybe early 6 too) and older RH systems.
  Ubuntu older than 9 I think (which is beyond unsupported). Not sure
  about other Linux dists.
  
  Basically if RHEL 5 is no longer a valid target and we are sure all
  of the 6s have updated then let's nuke it from orbit.
 
 I don't believe there was any release of RHEL-OSP that targeted RHEL
 5. As for RHEL 6, the last version that got support for it was OSP5
 which is based on Icehouse.
 
 Speaking of RDO, there were attempts to get nova pieces of Juno
 backported to RHEL 6 (mostly for CERN). Other than that, I don't think
 anyone considers to run anything Kilo+ on RHEL 6, and it will probably
 fail to work properly since a lot of underlying platform components in
 RHEL 6 would be not ready for new features. (RHEL-OSP could
 potentially get all the needed pieces in place, but there was a
 decision not to go this route and instead require RHEL 7 for anything
 Juno+).

Some Sahara plugins (HDP, CDH) supports only CentOS6/RHEL6. In order to 
generate images for them, even if diskimage-builder some scripts need to run 
on the guest directly. So at least diskimage-builder should keep Python 2.6 
support for guests (RHEL6 ships with Python 2.6)

Ciao
-- 
Luigi


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

Re: [openstack-dev] [nova] Switching the bug status of ~200 bugs at once; Problem?

[Markus Zoeller]

Markus Zoeller/Germany/IBM@IBMDE wrote on 07/10/2015 03:55
 [...]
  
  So you have a bunch of bugs that are Confirmed (or Triaged) + an
  assignee set. I would argue that you need to separate two cases:
  
  the bug had no activity for the last 60 days: assignee should be 
removed
  
  the bug had activity in the last 60 days: status should be in 
progress
  
  otherwise you further hide the fact that the bug is abandoned by 
setting
  status in addition to the assignee.
  
  Cheers,
  
  -- 
  Thierry Carrez (ttx)
 
 Right. My first intention was to switch all to in progress and then
 switch a subset of that back to the previous status, depending on their
 activity. I see now that this would cause confusion. 
 I'll process them seperately like Thierry suggested to avoid that
 confusion. I'll announce the expected changes in the next days before
 I actually execute them.
 
 Regards,
 Markus Zoeller (markus_z)

Here are the numbers. From the currently 215 Confirmed and Triaged
bugs which have an assignee (= inconsistency), there are:

 active  inactive
-
Triaged   4 5
Confirmed57   149

active = there is a comment within the last 60 days in Launchpad
  - or -
   the bug mentions at least one patch set in gerrit which is 
   * under review
   * verified by Jenkins
   * and without negative code reviews (older than 28 days)

inactive = the last update of the bug is older than 60 days
 - and -
 the bug mentions no active patch sets or only patch sets 
 which have -1s which are not addressed for 28 days.

I'm not sure why the number of the inactive confirmed bugs is so big.
Could it be that this is a way to bookmark bugs where one wants to
work on in the future?

Below are the details of the Confirmed and Triaged bugs which would
be affected as soon as I run the mentioned script in 'active' mode.

Maybe a short note why I think that this could improve Nova: I assume
that the average turnaround time of the bugs, from their creation until
they get closed with appropriate patch sets, can be decreased if the
'stale' bugs get a regular cleanup to enable other contributers to work
on them.

I'll wait a week until I execute this to give you some time to speak up.


Details:


Legend:
---
=In Progress: Switch the status of the bug to In Progress
-Assignee: Remove the current assignee
Age  : Days since the last update (in LP or Gerrit)
Patch Set ...: A summary of a patch set in Gerrit. Constructed as:
[review-id] (+2s +1s -1s -2s) 
(G:Jenkins Vote W:Workflow Flag) last update in days
 
===
CleanUpReport(9 Items): 'Triaged' bugs with an assignee
===
Bug ID  Title  Age Contributer  Cleanup Action 
 
---
1467409 HyperV destroy vm fails on Wi[...]  21 Adelina Tuve =In Progress  
 
1177570 Hyper-V tests can be refactor[...] 368 Alessandro P -Assignee  
1355171 Can not have IPv4 or IPv6 onl[...]  91 Chris Gacsal -Assignee  
1412480 Hyper-V: Instance booted from[...] 175 Claudiu Belu -Assignee  
1458013 ec2 code uses requests to tal[...]  29 Deepti Ramak =In Progress  
 
1436079 There is no API samples funct[...] 103 Eli Qiao -Assignee  
1458934 Ironic: heavy polling   25 Lucas Alvare =In Progress  
 
1441361 Don't trace on InstanceInfoCa[...]  96 Matt Riedema -Assignee  
1415087 [OSSA 2015-011] Format-guessi[...]   7 Tony Breeds  =In Progress  
 
---
4 x =In Progress
5 x -Assignee
===


===
CleanUpReport(206 Items): 'Confirmed' bugs with an assignee
===
Bug ID  Title  Age Contributer  Cleanup Action 
 
---
1309184 nova should delete neutron po[...] 305 Aaron Rosen  -Assignee  
1265447 floating-ip-bulk-delete metho[...] 151 Abhishek Tal -Assignee  
1301368 Hyper-V configdrive is not at[...] 105 Adrian Vladu -Assignee  
1335784 remove secgroup rule won't cu[...] 305 Akash Gangil -Assignee  
1153842 nova volume-attach vmid vo[...] 500 Alessandro P -Assignee  
1408176 Nova instance not boot after [...]  26 Alex Xu  =In Progress  
 
1301532 Quotas can be exceeded by mak[...]  90 Alex Xu  -Assignee  
Patch Set: [110863] (2 1 0 0) (G:0 W:None) age(d):341 - MERGED
1443494 Return supported micro-versio[...]  69 Alex Xu  -Assignee  
1253571 

Re: [openstack-dev] [neutron][security-group] rules for filter mac-addresses

[Kevin Benton]

Unfortunately the security groups API does not have mac-level rules right
now.

On Tue, Jul 14, 2015 at 2:17 AM, yan_xing...@163.com yan_xing...@163.com
wrote:

 Hi, all:

 Here is a requirement: deny/permit incoming packets on VM by mac addresses,
 I have tried to find better method than modifying neutron code, but failed.
 Any suggesion is grateful. Thank you.

 Yan.

 --
 yan_xing...@163.com

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




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

Re: [openstack-dev] [openstack-announce] End of life for managed stable/icehouse branches

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/14/2015 12:33 AM, Thomas Goirand wrote:
 I missed this announce...
 
 On 07/02/2015 05:32 AM, Jeremy Stanley wrote:
 Per the Icehouse EOL discussion[1] last month, now that the
 final 2014.1.5 release[2] is behind us I have followed our usual
 end of life steps for stable/icehouse branches on repos under the
 control of the OpenStack Release Cycle Management project-team. 
 Specifically, for any repos with the release:managed[3] tag, 
 icehouse-specific test jobs were removed from our CI system and
 all open change reviews were abandoned for stable/icehouse. Then
 the final states of the branches were tagged as icehouse-eol
 and the branches subsequently deleted.
 
 I believe I asked you about 10 times to keep these branches alive,
 so that distributions could work together on a longer support, even
 without a CI behind it.
 
 I have also asked for a private gerrit for maintaining the
 Icehouse patches after EOL.
 
 While I understand the later means some significant work, I don't 
 understand why you have deleted the Icehouse branches.
 
 Effectively, under these conditions, I am giving up doing any kind
 of coordination between distros for security patches of Icehouse.
 :(

As far as I know, there was no real coordination on those patches
before, neither I saw any real steps from any side to get it up.

That said, anyone can come up with an initiative to maintain those
branches under some 3party roof (just push -eol tag into github and
advertise), and if there is real (and not just anticipated)
collaboration going on around it, then the project may reconsider
getting it back in the big stadium.

I am tired to say that again and again, but there should be some
resource investment from interested parties, upfront, before infra
takes part of the burden on their shoulders. Asking won't help.

Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVpMhVAAoJEC5aWaUY1u57wY8IAN0Sjyjl+l25ZJQi0o/z/DDA
GZo7NbQu1IynGK8KB2nBxBJUCo8NZORNbh5NPJIHKItHpZn60C7GUCo8AGWRjryf
BFFGZERPfAXgJ9z/6+Vun34YX1R/uorZnhKitJlbCneBQygJRzHEV5IxybnHzvWf
j9koqCIjwZQzvDGT5CjkX+W83+FLvwdc7Sl57Ej091rHMzdvZO36tmulfMmGt/R0
lo8GMrHp9swasvZwt1mynYJkbQhProav5dxDNoLKhhawhseLWjYKwepWvJoweYT9
jMm1P0asdwWdpDcLR53ni1ljHh5lLNV1/H+uQJS1+hcKm75M7VYHxXDMY/Bodxo=
=q6Od
-END PGP SIGNATURE-

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

Re: [openstack-dev] [Murano] Versioning of Murano packages and MuranoPL classes

[Alexander Tivelkov]

Gosha,

Could you please elaborate what do you mean by extra blocks? Glance V3
comes with Glance out-of-the box, no extra deployment is needed. The only
thing one will have to install is Murano Package Type plugin - but it will
be installed at the same time with Murano.

--
Regards,
Alexander Tivelkov

On Mon, Jul 13, 2015 at 5:54 PM, Georgy Okrokvertskhov 
gokrokvertsk...@mirantis.com wrote:



 On Mon, Jul 13, 2015 at 2:19 AM, Alexander Tivelkov 
 ativel...@mirantis.com wrote:

 Hi Gosha,

 Supporting versioning in existing backend will require us to re-implement
 the significant part of Artifact Repository in Murano API: we'll need to
 add versions and dependencies concepts into our model (which is already
 complicated and dirty enough), extend appropriate API calls etc. And all
 the efforts will be a waste of time once we finally migrate to Artifacts.

 Also, what do you mean by set by default? V3 API is experimental, but
 it is already merged into upstream Glance, so there is no problem with
 using it in Murano right away.

 This is exactly why I have these concerns. I wonder how much customers
 will use experimental API in production. I just don't want to add extra
 block on Murano adoption way.



 --
 Regards,
 Alexander Tivelkov

 On Fri, Jul 10, 2015 at 5:56 PM, Georgy Okrokvertskhov 
 gokrokvertsk...@mirantis.com wrote:

 Hi Alex,

 Thank you for the great summary.

 I have a concern about item #8. Can we add an option to Murano to use
 previous storage engine rather then Glance v3? We need to make sure that v3
 API in Glance is set by default before we do a hard dependency on it in
 Murano.

 Thanks
 Gosha

 On Fri, Jul 10, 2015 at 4:53 AM, Alexander Tivelkov 
 ativel...@mirantis.com wrote:

 Hi folks,

 Ability to manage multiple versions of application packages and their
 dependencies was always an important item in Murano roadmap, however we
 still don't have a clear spec for this feature.
 Yesterday we hosted a small design session to come up with a plan on
 what can be done in Liberty timeframe to have proper versioning for
 MuranoPL classes and packages. Stan Lagun, Kirill Zaitsev and myself
 participated offline, some other muranoers joined remotely. Thanks to
 everybody who joined us.

 TL;DR: it turns out that now we have a clear plan which will allow us
 to achieve proper versioning of the packages and classes, and we'll try to
 implement the most important parts of it in Liberty.

 Here is the detailed outcome of the session:


1. We'll use the standard Semantic Versioning format
('Major.Minor.Patch[-dev-build.label[+metadata.label]]') to version our
packages: changes which break backwards-compatibility should increment 
 the
major segment, non-breaking new features increment the minor segment and
all non-breaking bugfixes increment the patch segment. The developers
should be carefull with the new features part: if you add a new 
 method to
a class, it may be considered a breaking change if the existing 
 subclasses
of this class have the same method already declared. We still assume 
 that
such changes should lead to increment of 'minor' segment, however it is 
 up
to best judgement of developers in particular case: if the risk of such
method override is really high it may worth to increment the 'major'
segment. Proper guideline on the versioning rules will be published 
 closer
to L release.

2. A new field 'Version' is introduced into package manifest file
which should define package version in complete semver format. The field
itself is optional (so existing apps are not broken), if it is not
specified the package is assumed to have version '0.0.0'

3. The existing 'Require' block of Application manifest will be
used to specify the package dependencies. Currently it is a yaml-based
dictionary, with the keys set to fully-qualified names of the dependency
packages and the values set to the version of those dependencies. 
 Currently
this block is used only for integration with apps stored at
apps.openstack.org. It is suggested to use this block in the
deployment process as well, and extend its semantics.
The version of the dependency specified there should also follow
the semver notation, however it may be specified in the shortened 
 format,
i.e. without specifying the 'patch' or 'patch' and 'minior' components. 
 In
this case the dependency will be specified as a range of allowed 
 versions.
For example, a dependency version 1.2 will mean a (1.2.0 = version  
 1.3)
range.
If the version of a dependency is not specified (like in this
existing app - [1]) then we assume the version 0 - i.e. the last
available pre-release version of a package.

4. Murano core library is also a package which has its own version.
The current one is assumed to have a version 0.1.0, the one which is 
 going
to be released in L will be probably called 0.2.0. The 

Re: [openstack-dev] [Nova] Friday July 10 is Nova's non-priority feature review bash day

[John Garbutt]

On 10 July 2015 at 19:08, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:
 On 7/7/2015 12:35 PM, John Garbutt wrote:

 Hi,

 Friday is: non-priority feature review bash day

 https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Dates_overview

 The idea is the whole nova community is invited to concentrate on
 reviewing some some of the low priority blueprints that have been
 hanging around for a while.

 *Note*
 the whole nova community are invited, its not just core reviewers, as
 with all review efforts

 The suggested starting point are low priority blueprints marked as
 NeedsCodeReview here:
 https://blueprints.launchpad.net/nova/liberty

 To help focus our efforts I am trying to curate a list of blueprints
 that have been waiting a long time for a review, see the Low
 priority, and longest waiting Blueprint patches section of the usual
 etherpad as a starting point:
 https://etherpad.openstack.org/p/liberty-nova-priorities-tracking

 Please lets group together and really get some of these long standing
 blueprints merged before next weeks non-priority feature proposal
 freeze, and the upcoming non-priority feature freeze.

 As usual, any questions or ideas, please do get in touch.

 Thanks,
 johnthetubaguy

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


 This is a good idea and thanks for pulling together the list in the
 etherpad.

 However, Friday is probably not the best for this (as I'm writing this at
 1pm on the day of the bash).  We are having gate issues today draining some
 resources, plus quite a few people aren't really around, and I had a big
 lunch and it's quiet and I feel like sleeping. :)

 So maybe we should reschedule this for like, Tuesday 7/14 when people are
 actually around?

Sorry, I have been out over the weekend and yesterday, so only just
seen this. Emergencies happen.

It was really just a Friday, as it used to be considered the best
day for these review pushes in the past, open to trying other days.

I think the list is still valid. Lets all catch up on IRC to pick a
time to push hard on some more reviews of these blueprint.

Thanks,
John

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

Re: [openstack-dev] [keystone] Liberty SFE Request - Dynamic Policies

[Marek Denis]

I am +1 on this SFE.
Dynamic Policy team has been working hard on this and they will for sure 
deliver nice features for Liberty.



-- Marek Denis [marek.de...@cern.ch]
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Andrey Kurilin]

Hi!
It looks like novaclient still supports py26 :) At least, there is a
gate-python-novaclient-python26 job.
Also, I checked several commands(boot, *list, delete ) with python 2.6 env
and they work as expected for me.

On Tue, Jul 14, 2015 at 2:03 PM, Sean Dague s...@dague.net wrote:

 I just saw this Nova review come in -
 https://review.openstack.org/#/c/200908

 Why are we merging 2.6 requirements for projects that don't support 2.6?
 That seems potentially confusing to end users that now think the project
 does, because there are still references in the code.

 -Sean

 --
 Sean Dague
 http://dague.net

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




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

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

[Harm Weites]

no-brainer: +1

Op 14-07-15 om 13:19 schreef Ryan Hallisey:

+1 I echo all the prior comments.

-Ryan

- Original Message -
From: Steven Dake (stdake) std...@cisco.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Sent: Monday, July 13, 2015 10:40:11 PM
Subject: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

Hey folks,

I am proposing Paul Bourke for the Kolla core team. He did a fantastic job 
getting Kolla into shape to support multiple distros and from source/from 
binary installation. His statistics are fantastic including both code and 
reviews. His reviews are not only voluminous, but consistently good. Paul is 
helping on many fronts and I would feel make a fantastic addition to our core 
reviewer team.

Consider my proposal to count as one +1 vote.

Any Kolla core is free to vote +1, abstain, or vote –1. A –1 vote is a veto for 
the candidate, so if you are on the fence, best to abstain :) We require 3 core 
reviewer votes to approve a candidate. I will leave the voting open until July 
20th  UTC. If the vote is unanimous prior to that time or a veto vote is 
received, I’ll close voting and make appropriate adjustments to the gerrit 
groups.

Regards
-steve

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

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



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

Re: [openstack-dev] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Jeremy Stanley]

On 2015-07-14 07:03:34 -0400 (-0400), Sean Dague wrote:
 I just saw this Nova review come in -
 https://review.openstack.org/#/c/200908
 
 Why are we merging 2.6 requirements for projects that don't support 2.6?
 That seems potentially confusing to end users that now think the project
 does, because there are still references in the code.

We could likely consider treating 2.6+2.7-supporting vs 2.7-only
(and 2.7+3.4-supporting? and 2.6+2.7+3.4?) repos differently where
requirements sync and enforcement are concerned, but a first step
for that would involve coming up with and maintaining a list of
which repos have support on which branches for which Python
versions. We don't have such a thing today as far as I'm aware, as
it's merely an emergent property based on a combination of factors
in zuul's layout file (the names of 2.6-based jobs, which repos run
them, and the branches on which they're allowed to run).
-- 
Jeremy Stanley

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

Re: [openstack-dev] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Sean Dague]

On 07/14/2015 08:32 AM, Jeremy Stanley wrote:
 On 2015-07-14 07:03:34 -0400 (-0400), Sean Dague wrote:
 I just saw this Nova review come in -
 https://review.openstack.org/#/c/200908

 Why are we merging 2.6 requirements for projects that don't support 2.6?
 That seems potentially confusing to end users that now think the project
 does, because there are still references in the code.
 
 We could likely consider treating 2.6+2.7-supporting vs 2.7-only
 (and 2.7+3.4-supporting? and 2.6+2.7+3.4?) repos differently where
 requirements sync and enforcement are concerned, but a first step
 for that would involve coming up with and maintaining a list of
 which repos have support on which branches for which Python
 versions. We don't have such a thing today as far as I'm aware, as
 it's merely an emergent property based on a combination of factors
 in zuul's layout file (the names of 2.6-based jobs, which repos run
 them, and the branches on which they're allowed to run).

There is trove classification in the projects themselves right?

[metadata]
name = nova
version = 12.0.0
summary = Cloud computing fabric controller
description-file =
README.rst
author = OpenStack
author-email = openstack-dev@lists.openstack.org
home-page = http://www.openstack.org/
classifier =
Environment :: OpenStack
Intended Audience :: Information Technology
Intended Audience :: System Administrators
License :: OSI Approved :: Apache Software License
Operating System :: POSIX :: Linux
Programming Language :: Python
Programming Language :: Python :: 2
Programming Language :: Python :: 2.7


That seems like it should be enough information to know the 2.6 question.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Jeremy Stanley]

On 2015-07-14 08:38:57 -0400 (-0400), Sean Dague wrote:
 There is trove classification in the projects themselves right?
[...]
 That seems like it should be enough information to know the 2.6 question.

I got to thinking through what this might look like, and while
filtering down the markers based on versions stated in trove
classifiers is fairly trivial when it's just a single == or != (such
as your example), we would also want to take into account inequality
operators for version ranges and logical constructions (and, or,
parenthetical ordering) which suggest that any marker simplification
routine is probably better implemented in setuptools/pkg_resources
which is already parsing these.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [neutron][security-group] rules for filter mac-addresses

[yan_xing...@163.com]

Thank you, Kevin. 
I search the blueprint about this point in launchpad.net, and got nothing, then 
register one at:
https://blueprints.launchpad.net/neutron/+spec/security-group-mac-rule 




Yan Xing'an
 
From: Kevin Benton
Date: 2015-07-14 18:31
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][security-group] rules for filter 
mac-addresses
Unfortunately the security groups API does not have mac-level rules right now.

On Tue, Jul 14, 2015 at 2:17 AM, yan_xing...@163.com yan_xing...@163.com 
wrote:
Hi, all:

Here is a requirement: deny/permit incoming packets on VM by mac addresses,
I have tried to find better method than modifying neutron code, but failed.
Any suggesion is grateful. Thank you.

Yan.



yan_xing...@163.com

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




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

Re: [openstack-dev] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Sean Dague]

On 07/14/2015 08:11 AM, Andrey Kurilin wrote:
 Hi!
 It looks like novaclient still supports py26 :) At least, there is a
 gate-python-novaclient-python26 job.
 Also, I checked several commands(boot, *list, delete ) with python 2.6
 env and they work as expected for me.

Ah, right fair, my bad. I had thought we'd adjusted that with all the
branching.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Fuel] Separate repo for Fuel Agent

[Vladimir Kozhukalov]

Dear colleagues,

New repository [1] has been created. So, please port all your review
requests to stackforge/fuel-web related to Fuel Agent to this new
repository. Currently, I am testing these two patches
https://review.openstack.org/#/c/200595
https://review.openstack.org/#/c/200025. If they work, we need to merge
them and that is it. Review is welcome.



[1] https://github.com/stackforge/fuel-agent.git

Vladimir Kozhukalov

On Fri, Jul 10, 2015 at 8:14 PM, Vladimir Kozhukalov 
vkozhuka...@mirantis.com wrote:

 Ok, guys.

 Looks like there are no any objections. At the moment I need to create
 actual version of upstream repository which is going to be sucked in by
 OpenStack Infra. Please, be informed that all patches changing
 fuel-web/fuel_agent that will be merged after this moment will need to be
 ported into the new fuel-agent repository.


 Vladimir Kozhukalov

 On Fri, Jul 10, 2015 at 6:38 PM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Guys, we are next to moving fuel_agent directory into a separate
 repository. Action flow is going to be as follows:

 1) Create verify jobs on our CI https://review.fuel-infra.org/#/c/9186
 (DONE)
 2) Freeze fuel_agent directory in https://github.com/stackforge/fuel-web
 (will announce in a separate mail thread). That means we stop merging
 patches into master which change fuel_agent directory. Unfortunately, all
 review requests need to be re-sent, but it is not going to be very
 difficult.
 3) Create temporary upstream repository with fuel_agent/* as a content.
 I'm not planning to move 5.x and 6.x branches. Only master. So, all fixes
 for 5.x and 6.x will be living in fuel-web.
 4) This upstream repository is going to be sucked in by openstack-infra.
 Patch is here https://review.openstack.org/#/c/199178/ (review is
 welcome) I don't know how long it is going to take. Will try to poke infra
 people to do this today.
 5) Then we need to accept two patches into new fuel-agent repository:
  - rpm spec (extraction from fuel-web/specs/nailgun.spec) (ready, but
 there is no review request)
  - run_tests.sh (to run tests) (ready, but there is no review request)

 !!! By this moment there won't be any impact on ISO build process !!!

 6) Then we need to change two things at the same time (review is welcome)
   - fuel-web/specs/nailgun.spec in order to prevent fuel-agent package
 building  https://review.openstack.org/#/c/200595
   - fuel-main so as to introduce new fuel-agent repository into the build
 process https://review.openstack.org/#/c/200025

 And good luck to me -)


 Vladimir Kozhukalov

 On Wed, Jul 8, 2015 at 12:53 PM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 There were some questions from Alexandra Fedorova about independent
 release cycle.

 according to the configuration [1] Infra team won't be able to do
 branching or any kind of release management for new repository.

 Could you please clarify, do we plan to version new repository the
 same way as we do for main fuel repositories or there going to be
 separate releases as in python-fuelclient [2]? Who should drive the
 release process for this repo and how this change will affect Fuel ISO
 release?

 [1]
 https://review.openstack.org/#/c/199178/1/gerrit/acls/stackforge/fuel-agent.config,cm
 [2]
 http://lists.openstack.org/pipermail/openstack-dev/2015-July/068837.html

 IMO all Fuel components should be as much independent as possible with
 highly defined APIs used for their interaction, with their own teams, with
 their own independent release cycles. But we cannot switch to this model
 immediately. For the start, we can just move those components into separate
 repositories, leaving the same access rights and core team as we have for
 fuel-web.

 When Fuel Agent is a separate repository we discuss team. It looks like
 a team leader is the best person to manage releases for a particular
 component. This thread is totally about separation stuff and how to do this
 not breaking anything.



 Vladimir Kozhukalov

 On Wed, Jul 8, 2015 at 12:24 PM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Dear colleagues,

 I am going to move Fuel Agent into a separate git repository. The thing
 is that we have quite a few review requests to fuel-web with changes for
 Fuel Agent. The new repository is going to look like this
 https://github.com/kozhukalov/fuel-agent i.e. there is no additional
 sub-directory fuel_agent. In fact, I don't think it is a big deal to update
 all fuel agent related review requests.

 Work items:
 0) request to openstack-infra https://review.openstack.org/#/c/199178/1
 0.1) upstream for this request with commit history
 https://github.com/kozhukalov/fuel-agent
 1) fuel-agent/specs/fuel-agent.spec is an extraction from
 fuel-web/specs/nailgun.spec (separate commit, in progress)
 2) modify fuel-main to build fuel-agent package (in progress)
 3) create jenkins-jobs/servers/fuel-ci/verify-fuel-agent.yaml (in
 progress)

 For the start Fuel Agent core team 

Re: [openstack-dev] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Jeremy Stanley]

On 2015-07-14 08:38:57 -0400 (-0400), Sean Dague wrote:
 There is trove classification in the projects themselves right?
[...]
 That seems like it should be enough information to know the 2.6 question.

Only if it's kept up to date. If we're going to rely on it (not a
terrible idea) then we should enforce it in tests somewhere first.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

[Ryan Hallisey]

+1 I echo all the prior comments.

-Ryan

- Original Message -
From: Steven Dake (stdake) std...@cisco.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Sent: Monday, July 13, 2015 10:40:11 PM
Subject: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

Hey folks, 

I am proposing Paul Bourke for the Kolla core team. He did a fantastic job 
getting Kolla into shape to support multiple distros and from source/from 
binary installation. His statistics are fantastic including both code and 
reviews. His reviews are not only voluminous, but consistently good. Paul is 
helping on many fronts and I would feel make a fantastic addition to our core 
reviewer team. 

Consider my proposal to count as one +1 vote. 

Any Kolla core is free to vote +1, abstain, or vote –1. A –1 vote is a veto for 
the candidate, so if you are on the fence, best to abstain :) We require 3 core 
reviewer votes to approve a candidate. I will leave the voting open until July 
20th  UTC. If the vote is unanimous prior to that time or a veto vote is 
received, I’ll close voting and make appropriate adjustments to the gerrit 
groups. 

Regards 
-steve 

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

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

Re: [openstack-dev] Cinder as generic volume manager

[Jan Safranek]

On 07/10/2015 12:19 AM, Walter A. Boring IV wrote:
 On 07/09/2015 12:21 PM, Tomoki Sekiyama wrote:
 Hi all,

 Just FYI, here is a sample script I'm using for testing os-brick which
 attaches/detaches the cinder volume to the host using cinderclient and
 os-brick:

 https://gist.github.com/tsekiyama/ee56cc0a953368a179f9

 python attach.py volume-uuid will attach the volume to the executed
 host and shows a volume path. When you hit the enter key, the volume is
 detached.

 Note this is skipping reserve or start_detaching APIs so the volume
 state is not changed to Attaching or Detaching.

 Regards,
 Tomoki
 
 Very cool Tomoki.  After chatting with folks in the Cinder IRC channel
 it looks like we are going to look at going with something more like what
 your script is doing.   We are most likely going to create a separate
 command line tool that does this same orchestration, using cinder client, a 
 new
 Cinder API that John Griffith is working on, and os-brick.

Very cool indeed, it looks exactly like as what I need.


Jan


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

Re: [openstack-dev] [Murano] Versioning of Murano packages and MuranoPL classes

[Kirill Zaitsev]

Alexander, do you plan to update the https://review.openstack.org/#/c/140402/ 
versioning spec? We can possibly try to make it a joint effort, if you like.


-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 14 Jul 2015 at 11:34:56, Alexander Tivelkov (ativel...@mirantis.com) wrote:

Gosha,

Could you please elaborate what do you mean by extra blocks? Glance V3 comes 
with Glance out-of-the box, no extra deployment is needed. The only thing one 
will have to install is Murano Package Type plugin - but it will be installed 
at the same time with Murano.

--
Regards,
Alexander Tivelkov

On Mon, Jul 13, 2015 at 5:54 PM, Georgy Okrokvertskhov 
gokrokvertsk...@mirantis.com wrote:


On Mon, Jul 13, 2015 at 2:19 AM, Alexander Tivelkov ativel...@mirantis.com 
wrote:
Hi Gosha,

Supporting versioning in existing backend will require us to re-implement the 
significant part of Artifact Repository in Murano API: we'll need to add 
versions and dependencies concepts into our model (which is already complicated 
and dirty enough), extend appropriate API calls etc. And all the efforts will 
be a waste of time once we finally migrate to Artifacts.

Also, what do you mean by set by default? V3 API is experimental, but it is 
already merged into upstream Glance, so there is no problem with using it in 
Murano right away.

This is exactly why I have these concerns. I wonder how much customers will use 
experimental API in production. I just don't want to add extra block on Murano 
adoption way.

 
--
Regards,
Alexander Tivelkov

On Fri, Jul 10, 2015 at 5:56 PM, Georgy Okrokvertskhov 
gokrokvertsk...@mirantis.com wrote:
Hi Alex,

Thank you for the great summary.

I have a concern about item #8. Can we add an option to Murano to use previous 
storage engine rather then Glance v3? We need to make sure that v3 API in 
Glance is set by default before we do a hard dependency on it in Murano.

Thanks
Gosha

On Fri, Jul 10, 2015 at 4:53 AM, Alexander Tivelkov ativel...@mirantis.com 
wrote:
Hi folks,

Ability to manage multiple versions of application packages and their 
dependencies was always an important item in Murano roadmap, however we still 
don't have a clear spec for this feature. 
Yesterday we hosted a small design session to come up with a plan on what can 
be done in Liberty timeframe to have proper versioning for MuranoPL classes and 
packages. Stan Lagun, Kirill Zaitsev and myself participated offline, some 
other muranoers joined remotely. Thanks to everybody who joined us.

TL;DR: it turns out that now we have a clear plan which will allow us to 
achieve proper versioning of the packages and classes, and we'll try to 
implement the most important parts of it in Liberty.

Here is the detailed outcome of the session:

We'll use the standard Semantic Versioning format 
('Major.Minor.Patch[-dev-build.label[+metadata.label]]') to version our 
packages: changes which break backwards-compatibility should increment the 
major segment, non-breaking new features increment the minor segment and all 
non-breaking bugfixes increment the patch segment. The developers should be 
carefull with the new features part: if you add a new method to a class, it 
may be considered a breaking change if the existing subclasses of this class 
have the same method already declared. We still assume that such changes should 
lead to increment of 'minor' segment, however it is up to best judgement of 
developers in particular case: if the risk of such method override is really 
high it may worth to increment the 'major' segment. Proper guideline on the 
versioning rules will be published closer to L release.

A new field 'Version' is introduced into package manifest file which should 
define package version in complete semver format. The field itself is optional 
(so existing apps are not broken), if it is not specified the package is 
assumed to have version '0.0.0'

The existing 'Require' block of Application manifest will be used to specify 
the package dependencies. Currently it is a yaml-based dictionary, with the 
keys set to fully-qualified names of the dependency packages and the values set 
to the version of those dependencies. Currently this block is used only for 
integration with apps stored at apps.openstack.org. It is suggested to use this 
block in the deployment process as well, and extend its semantics.
The version of the dependency specified there should also follow the semver 
notation, however it may be specified in the shortened format, i.e. without 
specifying the 'patch' or 'patch' and 'minior' components. In this case the 
dependency will be specified as a range of allowed versions. For example, a 
dependency version 1.2 will mean a (1.2.0 = version  1.3) range.
If the version of a dependency is not specified (like in this existing app - 
[1]) then we assume the version 0 - i.e. the last available pre-release 
version of a package.

Murano core library is also a package which has its own version. The 

Re: [openstack-dev] [neutron] Adding results to extension callbacks (ml2 port_update ext handling).

[Robert Kukura]

I haven't had a chance to review this patch in detail yet, but am 
wondering if this is being integrated with ML2 as an extension driver? 
If so, that should clearly address how dictionaries are extended and 
input values are validated. If not, why?


-Bob

On 7/13/15 10:50 PM, Miguel Angel Ajo wrote:

Inline reply (I've added to CC relevant people for ml2/plugin.py
port_update extension
handing -via git blame-) as they probably have an opinion here
(specially the last
two options).

Kevin Benton wrote:

This sounds like a lot of overlap with the dict extend functions. Why
weren't they adequate for the QoS use case?


Let me explain, I believe Mike exceeded the proposal with AFTER_READ,
that's not the plan,
even if we could do as he proposed,

AFTER_READ dict extension is just a temporary workaround until we have
a separate explicit
api @armax is working on. Making explicit that your service is going
to extend resources,
and handled that in an ordered way is a good thing.

Afterwards, the source of this review has came from ML2 implementation of
AFTER_CREATE/AFTER_UPDATE notification for ports/nets.

Let me explain:

 As a decoupled, mixinless service extending core resources, we
need to do two things:

1) Extending the core resources as other extensions would do, adding
stuff to the port/network
dicts, here's where it comes the current AFTER_READ dict extension,
and future API making
that more explicit and more controlled.

2) Verifying the extended values we receive on core resources, by
registering to BEFORE_*
callbacks. For example, if a tenant is trying to use a qos_profile_id
he doesn't have access to,
or that doesn't exist, we can cancel the operation by throwing an
exception.

  We need to extend the notifications for ports and networks, as
that's not notified currently.
Mike will work on that too in a separate patch.


3) Taking the finally extended values and store associations in database
 (AFTER_UPDATE/AFTER_CREATE) so any later reads of the
port/network will get the right
 qos_profile_later in after read.


We have found that AFTER_CREATE/AFTER_UPDATE happens at plugin level
(neutron/plugins/ml2/plugin.py / update_port) and that information
passed down is
very brief to our case (basically a None port if no ml2-know
attribute is changed), and
ml2 has to be aware of every single extension.

Here there are two options:
   a) we make ml2 also aware of qos_profile_id changes, complicating
the business logic down
there, or...

   b) we send the AFTER_CREATE/UPDATE events, and we listen to the
callback
listeners to such notification, and they will tell us if there's any
relevant field which must
be propagated down to agents. Then it's up to the agents to use such
field or not.


   Mike's patch proposal is in the direction of (b), he's a long term
thinker, I was proposing him
to just go (a) for now, but let's discuss and find what's more right.



On Mon, Jul 13, 2015 at 7:58 AM, Mike Kolesnikmkole...@redhat.com
wrote:


Hi,

I sent a simple patch to check the possibility to add results to
callbacks:
https://review.openstack.org/#/c/201127/

This will allow us to decouple the callback logic from the ML2
plugin in
the QoS scenario where we need to update the agents in case the
profile_id
on a port/network changes.
It will also allow for a cleaner way to extend resource attributes as
AFTER_READ callbacks can return a dict of fields to add to the original
resource instead of mutating it directly.

Please let me know what you think of this idea.

Regards,
Mike


__

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





__

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





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

Re: [openstack-dev] [all] Setting epoch in setup.cfg??

[Ian Cordasco]

On 7/13/15, 16:19, Joshua Harlow harlo...@outlook.com wrote:

Ian Cordasco wrote:

 On 7/13/15, 15:09, Dave Walkerem...@daviey.com  wrote:

 On 13 Jul 2015 8:52 pm, Ian Cordascoian.corda...@rackspace.com
wrote:
 On 7/13/15, 03:38, Thierry Carrezthie...@openstack.org  wrote:
 SNIP
 By counter-productive, I meant: likely to generate more confusion
 than
 clarity. If you provide an epoch in the version and it doesn't match
 downstream packagers ones, it's hard to rely on it.
 I see what you mean now. The thing is that for Debian/Fedora the epoch
 syntax is different from PEP 440

 For them it's

 [distro-epoch]:[upstream-version][otherstuff]

 PEP 440 epochs are separated by a !, so let's say $(distro) has an
epoch
 value of 1 and we choose 2, for glance the version would look ugly
 but
 would be:

 1:2!11.0.0

 SNIP
 This would be a problem for at least Ubuntu and Debian as the version
 string is specifically not allowed to contain a '!'.
 The upstream_version may contain only alphanumerics and the
characters .
 +- : ~ (full stop, plus, hyphen, colon, tilde) and should start with a
 digit. [0]

 Thanks for the input Dave. I didn't see that part since I was
specifically
 looking for how epochs are denoted. I still am quite certain that we
have
 no choice but to use the proper versioning tools upstream though and
that
 means using ! to indicate the epoch in our version strings because these
 are fundamentally Python packages.

+1 we produce python versions, and people use them (whether they are
uploaded to pypi or not) so we should try to do the right thing here no
matter what. If downstream distro (rh, ubuntu, other...) wants to
convert that into its local epoch scheme that's cool (and I would expect
them to do that in the correct manner that is appropriate for there
packages).

Since the mailing list reaches the largest number of people, I thought I'd
continue some of this discussion here.

Yesterday some further discussion happened in #openstack-infra (on IRC),
and the crux of the argument against Epochs seems to be that they make it
hard to deal with archives on the command line, e.g., you'd have an
archive generated that looks like:

nova-1!12.0.0.tar.gz

Perhaps I'm misunderstanding, but any relatively modern shell that allows
for tab completion will properly tab-complete that when using the filename.

Another argument is that this is something ugly that we'll have to live
with for the rest of OpenStack's life. Without it, however, we'll have to
live with 12.0.0  (the last four years of version numbers) as a sorting
mechanism as far as Python packaging is concerned.

There's also the argument that (paraphrasing) this isn't really a problem
for people using pip because you can do `pip install -U nova==12.0.0` once
and you're done. Except that if you have a local package index and you're
support reproducible builds of multiple versions, say, Juno (2014.2.x),
Kilo (2015.1.y), Liberty (your version number depends on project but is
strictly less than both Juno and Kilo), and M. If you upgrade a project
from Liberty to M, you have to still use `pip install -U nova==13.0.0`
because `pip install -U nova` will install Kilo because neither Liberty
nor M are using an epoch. We're effectively saying if you support more
than one release at a time using the python packaging ecosystem, you're a
second class citizen in OpenStack.

In other words, this will be an ongoing problem. Epochs are clearly a
necessity, otherwise our downstream distributors wouldn't be using them
and the PEP 440 authors wouldn't have included them. Epochs were designed
exactly for this situation, and while they're ugly, they're the absolutely
correct approach here.

As a sidenote, in case people are wondering how epochs even work with pip,
2015.1.0 has an implicit epoch of 0, e.g., the version can be equivalently
written as 0!2015.1.0. 1!12.0.0 would sort higher because 1 has a higher
value than the implicit 0. 1!13.0.0 then defers to the rest of the version
string because they belong to the same epoch.

Cheers,
Ian


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

[openstack-dev] [docs] [tc] Project and service names

[Anne Gentle]

Hi all,
Renamed the thread to get some topics in the subject, and I wanted to bring
this review to everyone's attention.

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

I will reconsider these guidelines based on feedback. That said, I have
done the legwork to ask about legal guidance and I still believe that
lowercase nearly always is best to reduce cognitive burden.

Thanks,
Anne

On Tue, Jul 7, 2015 at 9:36 PM, Anne Gentle annegen...@justwriteclick.com
wrote:




  Forwarded Message 
 Subject:[openstack-dev] Should project name be uppercase or
 lowercase?
 Date:   Tue, 7 Jul 2015 18:21:57 +0900
 From:   Yuiko Takada yuikotakada0...@gmail.com
 Reply-To:   OpenStack Development Mailing List (not for usage
 questions)
 openstack-dev@lists.openstack.org
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org



 Hi folks,

 I found the difference between wiki[1] and governance[2].


 Yes, we are aware of the differences. I have asked the OpenStack
 Foundation legal counsel and they do not have a legal reason to capitalize
 project names.

 So, in documentation for consistency and to work on more valuable efforts,
 we need to stick to the established Documentation Conventions that have
 been in place since October 2013.


 https://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_project_names



 wiki says Generally the capitalization of the project team names like
 swift is lowercase.
 But in governance, written as uppercase like Nova, Swift.


 I don't believe a machine-readable YAML file indicates style or
 conventions for capitalization for a collection.

 Yes, I will be doing a patch for service names since it is a source of
 reference and if we think it will alleviate confusion I'll also lowercase
 the names of the projects in a separate patch.


 How do you think which should we use uppercase vs lowercase for
 representing project names?


 I'll be patching the governance repo with some guidelines we have been
 using to make them official. The projects.yaml file is the reference point
 for the service catalog and documentation, and the doc team maintains a
 lookup list on the wiki page referenced above.

 Conventions for service names:

- Uppercase first letter of first word only.
- Do not use OpenStack in the name of the service.
- Use module if it is consuming other services (such as heat).
- Use service in general as that is mostly what is being added as
projects.

 Conventions for project names:

- In documentation published to docs.openstack.org, use lower case for
project names except at the beginning of a sentence or heading title.
(Note that all heading titles use sentence case for ease of learning
capitalization rules.)
- In the service catalog, use lower case.

 I hope this clarification helps. Please let me know if you have any
 questions or concerns.


Hi again all,
I have



 Thanks,
 Anne





 [1]https://wiki.openstack.org/wiki/Documentation/Conventions
 [2]
 http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml


 Best Regards,
 Yuiko Takada



 --
 Christian Berendt
 Cloud Solution Architect
 Tel.: +49-171-5542175
 Mail: bere...@b1-systems.de

 B1 Systems GmbH
 Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
 GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537




 --
 Anne Gentle
 Rackspace
 Principal Engineer
 www.justwriteclick.com




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

Re: [openstack-dev] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2015-07-14 13:08:46 +:
 On 2015-07-14 08:38:57 -0400 (-0400), Sean Dague wrote:
  There is trove classification in the projects themselves right?
 [...]
  That seems like it should be enough information to know the 2.6 question.
 
 I got to thinking through what this might look like, and while
 filtering down the markers based on versions stated in trove
 classifiers is fairly trivial when it's just a single == or != (such
 as your example), we would also want to take into account inequality
 operators for version ranges and logical constructions (and, or,
 parenthetical ordering) which suggest that any marker simplification
 routine is probably better implemented in setuptools/pkg_resources
 which is already parsing these.

I did some work to find the supported versions in
https://review.openstack.org/#/c/181165/4/inc/python,cm as part of the
changes to devstack to support python 3.

Doug

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

[openstack-dev] [requirements][all] policy on approving constraint changes

[Doug Hellmann]

At one point Robert proposed that we change the policy for approving
constraint changes like https://review.openstack.org/#/c/201408/ to
allow a single reviewer to approve it, assuming the tests were green.
Is that our current policy, or are we waiting for the integration of
constraints with our tox environments before deciding whether to make
that change?

Doug

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

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

[Daneyon Hansen (danehans)]

+1

From: Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, July 13, 2015 at 7:40 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

Hey folks,

I am proposing Paul Bourke for the Kolla core team.  He did a fantastic job 
getting Kolla into shape to support multiple distros and from source/from 
binary installation.  His statistics are fantastic including both code and 
reviews.  His reviews are not only voluminous, but consistently good.  Paul is 
helping on many fronts and I would feel make a fantastic addition to our core 
reviewer team.

Consider my proposal to count as one +1 vote.

Any Kolla core is free to vote +1, abstain, or vote –1.  A –1 vote is a veto 
for the candidate, so if you are on the fence, best to abstain :)  We require 3 
core reviewer votes to approve a candidate.  I will leave the voting open until 
July 20th  UTC.  If the vote is unanimous prior to that time or a veto vote 
is received, I’ll close voting and make appropriate adjustments to the gerrit 
groups.

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

Re: [openstack-dev] [all] Setting epoch in setup.cfg??

[Monty Taylor]

On 07/14/2015 11:08 AM, Ian Cordasco wrote:
 
 
 On 7/13/15, 16:19, Joshua Harlow harlo...@outlook.com wrote:
 
 Ian Cordasco wrote:

 On 7/13/15, 15:09, Dave Walkerem...@daviey.com  wrote:

 On 13 Jul 2015 8:52 pm, Ian Cordascoian.corda...@rackspace.com
 wrote:
 On 7/13/15, 03:38, Thierry Carrezthie...@openstack.org  wrote:
 SNIP
 By counter-productive, I meant: likely to generate more confusion
 than
 clarity. If you provide an epoch in the version and it doesn't match
 downstream packagers ones, it's hard to rely on it.
 I see what you mean now. The thing is that for Debian/Fedora the epoch
 syntax is different from PEP 440

 For them it's

 [distro-epoch]:[upstream-version][otherstuff]

 PEP 440 epochs are separated by a !, so let's say $(distro) has an
 epoch
 value of 1 and we choose 2, for glance the version would look ugly
 but
 would be:

 1:2!11.0.0

 SNIP
 This would be a problem for at least Ubuntu and Debian as the version
 string is specifically not allowed to contain a '!'.
 The upstream_version may contain only alphanumerics and the
 characters .
 +- : ~ (full stop, plus, hyphen, colon, tilde) and should start with a
 digit. [0]

 Thanks for the input Dave. I didn't see that part since I was
 specifically
 looking for how epochs are denoted. I still am quite certain that we
 have
 no choice but to use the proper versioning tools upstream though and
 that
 means using ! to indicate the epoch in our version strings because these
 are fundamentally Python packages.

 +1 we produce python versions, and people use them (whether they are
 uploaded to pypi or not) so we should try to do the right thing here no
 matter what. If downstream distro (rh, ubuntu, other...) wants to
 convert that into its local epoch scheme that's cool (and I would expect
 them to do that in the correct manner that is appropriate for there
 packages).
 
 Since the mailing list reaches the largest number of people, I thought I'd
 continue some of this discussion here.
 
 Yesterday some further discussion happened in #openstack-infra (on IRC),
 and the crux of the argument against Epochs seems to be that they make it
 hard to deal with archives on the command line, e.g., you'd have an
 archive generated that looks like:
 
 nova-1!12.0.0.tar.gz
 
 Perhaps I'm misunderstanding, but any relatively modern shell that allows
 for tab completion will properly tab-complete that when using the filename.
 
 Another argument is that this is something ugly that we'll have to live
 with for the rest of OpenStack's life. Without it, however, we'll have to
 live with 12.0.0  (the last four years of version numbers) as a sorting
 mechanism as far as Python packaging is concerned.
 
 There's also the argument that (paraphrasing) this isn't really a problem
 for people using pip because you can do `pip install -U nova==12.0.0` once
 and you're done. Except that if you have a local package index and you're
 support reproducible builds of multiple versions, say, Juno (2014.2.x),
 Kilo (2015.1.y), Liberty (your version number depends on project but is
 strictly less than both Juno and Kilo), and M. If you upgrade a project
 from Liberty to M, you have to still use `pip install -U nova==13.0.0`
 because `pip install -U nova` will install Kilo because neither Liberty
 nor M are using an epoch. We're effectively saying if you support more
 than one release at a time using the python packaging ecosystem, you're a
 second class citizen in OpenStack.
 
 In other words, this will be an ongoing problem. Epochs are clearly a
 necessity, otherwise our downstream distributors wouldn't be using them
 and the PEP 440 authors wouldn't have included them. Epochs were designed
 exactly for this situation, and while they're ugly, they're the absolutely
 correct approach here.
 
 As a sidenote, in case people are wondering how epochs even work with pip,
 2015.1.0 has an implicit epoch of 0, e.g., the version can be equivalently
 written as 0!2015.1.0. 1!12.0.0 would sort higher because 1 has a higher
 value than the implicit 0. 1!13.0.0 then defers to the rest of the version
 string because they belong to the same epoch.

Those are all only physical manifestations of the concern I shared, not
the concerns themselves.

Here are my actual thoughts and concerns:

pip is not a downstream distribution. It is not as rich as dpkg or rpm.
The issues that they solve by using epochs are not the same problem
space pip exists in.

In downstream distros, such as debian and fedora, the work of and
complexity of epochs are packager concerns. End users are not generally
exposed to them, because a release of a Linux distro has one version of
a given thing at any time. So the problem space as a user is I want to
install the version of the software that exists in the current release
of my distro contains In that problem space, epochs provide a tool when
an upstream (like us) does something that  conflicts with the version
sorting rules in the distro.

With pip/pypi, all of 

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

[Steven Dake (stdake)]

Well that is unanimous.  Welcome to the core team Paul!

Regards
-steve


From: Daneyon Hansen (danehans) 
daneh...@cisco.commailto:daneh...@cisco.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, July 14, 2015 at 8:56 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core


+1

From: Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, July 13, 2015 at 7:40 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

Hey folks,

I am proposing Paul Bourke for the Kolla core team.  He did a fantastic job 
getting Kolla into shape to support multiple distros and from source/from 
binary installation.  His statistics are fantastic including both code and 
reviews.  His reviews are not only voluminous, but consistently good.  Paul is 
helping on many fronts and I would feel make a fantastic addition to our core 
reviewer team.

Consider my proposal to count as one +1 vote.

Any Kolla core is free to vote +1, abstain, or vote –1.  A –1 vote is a veto 
for the candidate, so if you are on the fence, best to abstain :)  We require 3 
core reviewer votes to approve a candidate.  I will leave the voting open until 
July 20th  UTC.  If the vote is unanimous prior to that time or a veto vote 
is received, I’ll close voting and make appropriate adjustments to the gerrit 
groups.

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

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

[Paul Bourke]

Thanks very much all it's a privilege. Look forward to continuing to 
help out as much as possible; please feel free to drop me a line on IRC 
or email any time.


-Paul

On 14/07/15 17:01, Steven Dake (stdake) wrote:

Well that is unanimous.  Welcome to the core team Paul!

Regards
-steve


From: Daneyon Hansen (danehans) daneh...@cisco.com
mailto:daneh...@cisco.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.org
Date: Tuesday, July 14, 2015 at 8:56 AM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core


+1

From: Steven Dake (stdake) std...@cisco.com
mailto:std...@cisco.com
Reply-To: OpenStack Development Mailing List (not for usage
questions) openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.org
Date: Monday, July 13, 2015 at 7:40 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

Hey folks,

I am proposing Paul Bourke for the Kolla core team.  He did a
fantastic job getting Kolla into shape to support multiple
distros and from source/from binary installation.  His
statistics are fantastic including both code and reviews.  His
reviews are not only voluminous, but consistently good.  Paul is
helping on many fronts and I would feel make a fantastic
addition to our core reviewer team.

Consider my proposal to count as one +1 vote.

Any Kolla core is free to vote +1, abstain, or vote –1.  A –1
vote is a veto for the candidate, so if you are on the fence,
best to abstain :)  We require 3 core reviewer votes to approve
a candidate.  I will leave the voting open until July 20th 
UTC.  If the vote is unanimous prior to that time or a veto vote
is received, I’ll close voting and make appropriate adjustments
to the gerrit groups.

Regards
-steve



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

Re: [openstack-dev] [Cinder] Quobyte Cinder Driver revert?

[Silvan Kaiser]

Thanks for the hint, Ramy!
I did talk about this a longer time ago in the 3rdParty weekly but it was
hard to for people to help as it was an issue quite specific to our setup.
On other occasions, however, that meeting has been greatly helpful and I
recommend it, too!
Silvan


2015-07-07 6:01 GMT+02:00 Asselin, Ramy ramy.asse...@hp.com:

  HI Silvan,



 A great resource to resolve such issues is the third-party ci meetings
 [1]. It’s a dedicated time slot to ask questions and get help from other
 community members such as yourself. Oftentimes, someone else has run into
 the same issue and already as an answer.



 Ramy



 [1] https://wiki.openstack.org/wiki/Meetings/ThirdParty





 *From:* Silvan Kaiser [mailto:sil...@quobyte.com]
 *Sent:* Friday, July 03, 2015 9:06 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Cinder] Quobyte Cinder Driver revert?



 Hello again!

 Ok, now i did find the review [1], sorry i did not earlier.



 We will solve the CI issues asap in order to provide the requirements to
 recommit the Quobyte driver.

 We've been trying to solve the CIs networking issue i wrote about since
 then but were unable to nail it down completely as we're only a small
 company and restricted in resources.

 After the mail from Mike Perez regarding missing reports [2] i had brief
 contact with him directly via email [3] and once more on the third party
 mailing list [4].

 As i did not receive a message after the replies i did not expect there to
 be a defined deadline and I did not see information about the impending
 revert on gerrit, and thus was unable to comment on that.

 My apologies for that.

 We're focusing on this with all the team now.



 Silvan Kaiser





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

 [2]
 http://lists.openstack.org/pipermail/third-party-announce/2015-June/000200.html

 [3]
 http://lists.openstack.org/pipermail/third-party-announce/2015-June/000213.html

 [4]
 http://lists.openstack.org/pipermail/third-party-announce/2015-June/000214.html





 2015-07-03 16:31 GMT+02:00 Silvan Kaiser sil...@quobyte.com:

  Hello!

 I just found the following commit in the cinder log:



 commit a3f4eed52efce50c2eb1176725bc578272949d7b

 Merge: 6939b4a e896ae2

 Author: Jenkins jenk...@review.openstack.org

 Date:   Thu Jul 2 23:14:39 2015 +



 Merge Revert First version of Cinder driver for Quobyte





 Is this part of some restructuring work, etc. that i did miss?

 I could not find a gerrit review for this and had no prior information? I
 did not see any related information when i did my weekly checks of the
 cinder weekly meeting logs and am confused to find this commit.



 We're still working on the CI issues discussed on the CI mailing list and
 am fully aware that we've to get this stably reporting. This is not a
 removal because of the CI issues?

 Best regards

 Silvan Kaiser





 --

 Dr. Silvan Kaiser

 Quobyte GmbH
 Boyenstr. 41 - 10115 Berlin-Mitte - Germany
 +49-30-814 591 800 - www.quobyte.comhttp://www.quobyte.com/
 Amtsgericht Berlin-Charlottenburg, HRB 149012B
 Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender





 --

 Dr. Silvan Kaiser

 Quobyte GmbH
 Boyenstr. 41 - 10115 Berlin-Mitte - Germany
 +49-30-814 591 800 - www.quobyte.comhttp://www.quobyte.com/
 Amtsgericht Berlin-Charlottenburg, HRB 149012B
 Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender




 --

 *Quobyte* GmbH
 Hardenbergplatz 2 - 10623 Berlin - Germany
 +49-30-814 591 800 - www.quobyte.com

 Amtsgericht Berlin-Charlottenburg, HRB 149012B
 management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender

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




-- 
Dr. Silvan Kaiser
Quobyte GmbH
Boyenstr. 41 - 10115 Berlin-Mitte - Germany
+49-30-814 591 800 - www.quobyte.comhttp://www.quobyte.com/
Amtsgericht Berlin-Charlottenburg, HRB 149012B
Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender

-- 

--
*Quobyte* GmbH
Hardenbergplatz 2 - 10623 Berlin - Germany
+49-30-814 591 800 - www.quobyte.com
Amtsgericht Berlin-Charlottenburg, HRB 149012B
management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Cinder] FFE Request: Re-add Quobyte Cinder Driver

[Silvan Kaiser]

Hello Cinder Community!
I'd like to request a feature freeze exception for change [1], re-adding the 
Quobyte driver to Cinder.

The driver was removed in change [2] due to missing CI activity [3], it was 
originally added in the kilo release [4].
We've been able to remove the CI's issues and it has been reporting for a week 
now [5], stably testing and consistently showing two bugs (one in Nova and one 
in our driver/Cinder),
referenced on the CIs status page [6]. We're monitoring the CI results 
continuously and the detected bugs are beeing addressed.
The complete logs can be reviewed at [7].
CI status changes are published on the Quobyte CI Status page in the wiki [6], 
where there’s also our contact information.
Thanks a lot for considering and best regards
Silvan Kaiser
(kaisers/casusbelli in IRC)


[1] https://review.openstack.org/#/c/201507/
[2] https://review.openstack.org/#/c/191192/
[3] http://lists.openstack.org/pipermail/openstack-dev/2015-July/068609.html
[4] https://review.openstack.org/#/c/94186/
[5] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069183.html
[6] https://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI
[7] http://176.9.127.22:8081/?C=M;O=D


-- 

--
*Quobyte* GmbH
Hardenbergplatz 2 - 10623 Berlin - Germany
+49-30-814 591 800 - www.quobyte.com
Amtsgericht Berlin-Charlottenburg, HRB 149012B
management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender

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

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

[Emilien Macchi]

On 07/13/2015 09:23 AM, Emilien Macchi wrote:
 Hello Puppet masters!
 
 Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC
 in #openstack-meeting-4:
 
 https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150714
 
 Please add additional items you'd like to discuss.
 If our schedule allows it, we'll make bug triage during the meeting.
 
 See you there!
 

We did our meeting, you can read the notes here:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150714

Have a great day!

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

-- 
Emilien Macchi



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

Re: [openstack-dev] [puppet] First Sprint proposal

[Emilien Macchi]

We decided during our weekly meeting that the Sprint will happen
virtually on IRC on Wed 9/2 – Fri 9/4.

We will use #openstack-sprint (freenode) IRC channel and Google Hangout
/ Bluejeans if needed.

We made progress on defining an agenda:
https://etherpad.openstack.org/p/puppet-liberty-mid-cycle

Please have a look and feel free to add / complete the topics.

See you there,

On 07/13/2015 09:03 AM, Emilien Macchi wrote:
 I just closed the poll after one week.
 It will happen on Wed 9/2 – Fri 9/4.
 
 We'll work on the agenda during the following weeks.
 
 Best,
 
 On 07/06/2015 10:26 PM, Matt Fischer wrote:
 Operators mid-cycle is Aug 17-21 at a TBD location, I voted accordingly.
 Thanks.

 On Mon, Jul 6, 2015 at 12:09 PM, Emilien Macchi emil...@redhat.com
 mailto:emil...@redhat.com wrote:



 On 07/06/2015 02:05 PM, Matt Fischer wrote:
  I think this is a great idea. I'd like to get a firm date on the
  operators mid-cycle before I vote though.

 If it overlaps, we can add more slots. Feel free to ping me on IRC for
 that, I'll update the doodle.

 Thanks,

 
  On Mon, Jul 6, 2015 at 11:31 AM, Emilien Macchi emil...@redhat.com 
 mailto:emil...@redhat.com
  mailto:emil...@redhat.com mailto:emil...@redhat.com wrote:
 
  Hi,
 
  I would like to organize our first sprint for contributing to our 
 Puppet
  OpenStack modules. It will happen in Red Hat Montreal (Canada) 
 office,
  during 3 days.
 
  If you're interested to participate, please find the slots that 
 may work
  for you [1]. Any slot suggestion is welcome though.
  Also, please bring on the etherpad any topics we should work on 
 together
  [2].
  We will groom topics during a meeting and prepare the agenda 
 before the
  sprint.
 
  [1] http://doodle.com/xk2sfgu4xsi4y6n4r46t7u9k
  [2] https://etherpad.openstack.org/p/puppet-liberty-mid-cycle
 
  Regards,
  --
  Emilien Macchi
 
 
  
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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

 --
 Emilien Macchi


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




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

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

-- 
Emilien Macchi



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

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

[Jeff Peeler]

On Tue, Jul 14, 2015 at 01:56:16PM +0200, Harm Weites wrote:


no-brainer: +1

Op 14-07-15 om 13:19 schreef Ryan Hallisey:

+1 I echo all the prior comments.

-Ryan

- Original Message -
From: Steven Dake (stdake) std...@cisco.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Sent: Monday, July 13, 2015 10:40:11 PM
Subject: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

Hey folks,

I am proposing Paul Bourke for the Kolla core team. He did a fantastic 
job getting Kolla into shape to support multiple distros and from 
source/from binary installation. His statistics are fantastic 
including both code and reviews. His reviews are not only voluminous, 
but consistently good. Paul is helping on many fronts and I would feel 
make a fantastic addition to our core reviewer team.


Consider my proposal to count as one +1 vote.

Any Kolla core is free to vote +1, abstain, or vote –1. A –1 vote is a 
veto for the candidate, so if you are on the fence, best to abstain :) 
We require 3 core reviewer votes to approve a candidate. I will leave 
the voting open until July 20th  UTC. If the vote is unanimous 
prior to that time or a veto vote is received, I’ll close voting and 
make appropriate adjustments to the gerrit groups.


+1!

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

Re: [openstack-dev] [CI] How to set a proxy for zuul.

[Abhishek Shrivastava]

​Basically it is not required, and if you see /etc/jenkins_jobs/config
folder you will find one dsvm-cinder-tempest.yaml which is to be used
basically not examples.yaml. So its not an issue.​

On Tue, Jul 14, 2015 at 12:07 PM, Tang Chen tangc...@cn.fujitsu.com wrote:


 On 07/14/2015 01:46 PM, Abhishek Shrivastava wrote:

  Instead of it use reusable_node option.


 Thanks. Problem resolved. :)

 BTW, single_use_node is written in layout.yaml by default.
 If it doesn't exist anymore, do we need a patch to fix it ?

 For someone who uses CI for the first time, it is really a problem..

 And also, if I want to post patch for zuul, where should I post the patch ?

 Thanks.



 On Tue, Jul 14, 2015 at 9:12 AM, Tang Chen tangc...@cn.fujitsu.com
 wrote:

  Hi Abhishek, All,

 I found the problem.

 My /etc/zuul/layout/layout.yaml has the following config:

 jobs:
   - name: ^dsvm-tempest.*$
 parameter-function: single_use_node

 But in _parseConfig() in zuul/scheduler.py, it failed to find
 single_use_node().

 fname = config_job.get('parameter-function', None)
 if fname:
 func = config_env.get(fname, None)
 if not func:
 raise Exception(Unable to find function %s % fname)

 So projects section was not parsed.

 Does anyone know why ?

 Thanks.




 On 07/14/2015 10:54 AM, Tang Chen wrote:

 Hi Abhishek,

 I printed the self.layout.projects in zuul/scheduler.py, it is empty.
 So the project was not found.

 But I did do the jenkins-jobs --flush-cache update
 /etc/jenkins_jobs/config/
 And I did configure openstack-dev/sandbox in layout.yaml.

 Do you have any idea what's wrong here ?

 Thanks.


 On 07/13/2015 05:58 PM, Tang Chen wrote:


 On 07/13/2015 04:35 PM, Abhishek Shrivastava wrote:

  Updating jobs using sudo jenkins-jobs --flush-cache update
 /etc/jenkins_jobs/config/. Also update the myvendor in examples.yaml


 Sorry, I updated the jobs, restart the whole machine. But it still
 doesn't work.

 By the way, there is no vendor in examples.yaml.

 It is still this error: Project openstack-dev/sandbox not found

 Anything else should I pay attention to?

 Thanks.


 On Mon, Jul 13, 2015 at 1:45 PM, Tang Chen tangc...@cn.fujitsu.com
 wrote:


 On 07/13/2015 03:50 PM, Abhishek Shrivastava wrote:

  ​ Use tester or something, also are you updating the jobs or not?​


  I used tester as my vendor. It doesn't work.

 And what do you mean by updating the jobs ? I built the
 noop-check-cimmunitication
 job once in Jenkins UI. Does it matter ? All the others are not touched.

 And referring to the error, Project openstack-dev/sandbox not found,
 it seems like
 somewhere the project name was wrong.

 right ?


 Thanks.


 On Mon, Jul 13, 2015 at 1:16 PM, Tang Chen tangc...@cn.fujitsu.com
 wrote:

  Hi Abhishek,

 Thanks for the quick reply.

 On 07/13/2015 03:16 PM, Abhishek Shrivastava wrote:

  Also check that Gearman is connecting or not through Jenkins UI.

 On Mon, Jul 13, 2015 at 12:45 PM, Abhishek Shrivastava 
 abhis...@cloudbyte.com wrote:

  First of all, change the vendor to your vendor name in
 /etc/jenkins_jobs/config/projects.yaml file. Also, restart the zuul
 and zuul merger.


  I did the check. Gearman plugin works find. In Jenkins UI, I tested
 the connection, and it succeeded.

 And also, I restarted zuul and zuul merger every time I modified the
 yaml files.

 But it doesn't work.

 And the vendor, does that matter ?  And what vendor name should I
 provide ?
 I cannot find any vendor info in my Gerrit service account profile.
 For example, is XXX OK ?

 Thanks.




 On Mon, Jul 13, 2015 at 12:29 PM, Tang Chen tangc...@cn.fujitsu.com
 wrote:

 Hi all,

 I have constructed my CI system.
 When I tested it with sandbox project, I posted a patch to Gerrit.

 https://review.openstack.org/201002

 But I got this error in zuul scheduler:

 2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Run handler awake
 2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Fetching trigger event
 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Processing trigger
 event TriggerEvent comment-added openstack-dev/sandbox master 201002,1
 Verified:1
 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Project
 openstack-dev/sandbox not found
 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Run handler sleeping


 My /etc/zuul/layout/layout.yaml looks like this:

 projects:
   - name: openstack-dev/sandbox
 check:
   - noop-check-communication


 My /etc/jenkins_jobs/config/projects.yaml looks like this:

 - project:
 name: sandbox
 github-org: openstack-dev
 node: master
 vendor: myvendor

 jobs:
 - noop-check-communication
 - dsvm-tempest-full:
 node: 'devstack_slave || devstack-precise-check || d-p-c'


 And Jenkins master works fine.


 Does anyone know what is going on here ?


 Thanks.






 __
 OpenStack Development Mailing 

[openstack-dev] Hyper-V Meeting

[Peter Pouliot]

Hi All,

We still have a lack of quorum today do to summer holidays, so we're postponing 
until everyone is back.

p

Peter J. Pouliot CISSP
Microsoft Enterprise Cloud Solutions
C:\OpenStack
New England Research  Development Center
1 Memorial Drive
Cambridge, MA 02142
P: 1.(857).4536436
E: ppoul...@microsoft.commailto:ppoul...@microsoft.com

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

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

[Doug Wiegley]

I’d be good submitting it to the neutron-lbaas repo, under a horizon/ 
directory. We can iterate there, and talk with the Horizon team about how best 
to integrate. Would that work?

Thanks,
doug

 On Jul 13, 2015, at 3:05 PM, Jain, Vivek vivekj...@ebay.com wrote:
 
 Hi German,
 
 We integrated UI with LBaaS v2 GET APIs. We have created all panels for
 CREATE and UPDATE as well.
 Plan is to share our code with community on stackforge for more
 collaboration from the community.
 
 So far Ganesh from cisco has shown interest in helping with some work. It
 will be great if we can get more hands.
 
 Q: what is the process for hosting in-progress project on stackforge? Can
 someone help me here?
 
 Thanks,
 Vivek
 
 On 7/10/15, 11:40 AM, Eichberger, German german.eichber...@hp.com
 wrote:
 
 Hi Vivek,
 
 Hope things are well. With the Midccyle next week I am wondering if you
 made any progress and/or how we can best help with the panels.
 
 Thanks,
 German
 
 From: Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
 g
 Date: Wednesday, April 8, 2015 at 3:32 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
 g
 Cc: Balle Balle, Susanne
 susanne.ba...@hp.commailto:susanne.ba...@hp.com, Tonse, Milan
 mto...@ebay.commailto:mto...@ebay.com
 Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2
 
 Thanks German for the etherpad link. If you have any documentation for
 flows, please share those too.
 
 I will work with my team at ebay to publish wireframes for design we are
 working on. It will be mostly along the lines I demo’ed in Paris.
 
 Thanks,
 Vivek
 
 From: Eichberger, German
 german.eichber...@hp.commailto:german.eichber...@hp.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
 g
 Date: Wednesday, April 8, 2015 at 11:24 AM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
 g
 Cc: Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com
 Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2
 
 Hi,
 
 We briefly talked about it a few Neutron meetings back (LBaaS is now on
 demand) and created an etherpad to track things:
 https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases
 
 Susanne and I met with HP’s UX designer to work on the design for some
 flows for the Horizon panel (cc’d) but I am glad that Vivek is taking the
 lead. Please check that etherpad for more information and feel free to
 update as things happen…
 
 Thanks,
 German
 
 
 From: Jain, Vivek [mailto:vivekj...@ebay.com]
 Sent: Tuesday, April 07, 2015 9:01 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2
 
 Hi Evgeny,
 We have just started working on Horizon lbaasv2 support. I have to sync
 up with my team on the time-line but it is not targeted for Kilo release.
 Since it is a major effort, we will need more hands. Let me know if
 anyone is interested to contribute.
 
 On a related note, Do we have a sample code which uses neutronclient
 lbaas v2 methods? That will greatly speedup our horizon integration.
 
 Thanks,
 Vivek
 
 From: Phillip Toohill
 phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
 g
 Date: Tuesday, April 7, 2015 at 7:50 AM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
 g
 Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2
 
 
 ​Hey Evgeny,
 
 
 
 I believe Vivek is working on Horizon lbaasv2 support. We werent given a
 timeline or anything but sounds like its being actively worked on. I
 would reach out to him to get better timelines if concerned.
 
 
 Phillip V. Toohill III
 Software Developer
 [http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rack
 cdn.com/signatures/images/rackspace_logo.png]
 phone: 210-312-4366
 mobile: 210-440-8374
 
 
 From: Evgeny Fedoruk evge...@radware.commailto:evge...@radware.com
 Sent: Tuesday, April 7, 2015 5:50 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2
 
 Hi guys,
 
 LBaaS v2 has no horizon support as for now and I want to know if this
 work is planned to be done and , if yes, in what time frame.
 Is there a plan to develop it for Kilo or for L release?
 
 

Re: [openstack-dev] [oslo.messaging][zeromq] Next step

[Alec Hothan (ahothan)]

inline...


On 7/8/15, 8:23 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote:

 On 6/12/15, 3:55 PM, Clint Byrum cl...@fewbar.com wrote:
 
 
  
 
 I think you missed it is not tested in the gate as a root cause for
 some of the ambiguity. Anecdotes and bug reports are super important
for
 knowing where to invest next, but a test suite would at least
establish a
 base line and prevent the sort of thrashing and confusion that comes
from
 such a diverse community of users feeding bug reports into the system.
 
 I agree with you that zmq needs to pass whatever oslo messaging test is
 currently available however this won't remove all the
 semantical/behavioral ambiguities.
 This kind of ambiguities could be fixed by enhancing the API
documentation
 - always good to do even if a bit late - and by developing the
associated
 test cases (although they tend to be harder to write).
 Another (ugly) strategy could be to simply say that the intended
behavior
 is the one exposed by the rabbitMQ based implementation (by means of
 seniority and/or actual deployment mileage).
 
 For example, what happens if a recipient of a CALL or CAST message dies
 before the message is sent.
 Is the API supposed to return an error and if yes how quickly? RabbitMQ
 based implementation will
 likely return a success (since the message will sit in a queue in the
 broker until the consumer reconnects - which could be a long time)
while
 ZMQ based will depend on the type of pattern used. Which is the
behavior
 desired by apps and which is the behavior advertised by the oslo
 messaging API?
 
 Another example relates to flow control conditions (sender sends lots
of
 CAST, receiver very slow to consume). Should the sender
 - always receive success and all messages will be queued without limit,
 - always receive success and all messages will be queued up to a
certain
 point and new messages will be dropped silently
 - or receive an EAGAIN error (socket behavior)?
 
 In these unclear conditions, switching to a different transport driver
is
 going to be tricky because apps may have been written/patched to
assume a
 certain behavior and might no longer behave properly if the expected
 behavior changes (even if it is for the better) and may require
adjusting
 existing apps (to support a different behavior of the API).
 Note that switching to a different transport is not just about
testing
 it in devstack but also about deploying it at scale on real production
 environment and testing at scale.
 
 Alec, you bring up fantastic and importan points above.
 
 However, lets stay on track. We're not even testing to see if nova-api
 can talk to nova-conductor via the current zmq driver. It's entirely
 possible it simply does not work for any number of reasons.
 
 A devstack-gate job is the _minimum_ needed.

I believe the next steps can be summarized as the following:

1) Make existing zeromq driver tested in the gate in order to save it
from deprecation and removal.

I believe Oleksii is already working on it.



2) Think of the new driver architecture decisions more precisely, like:
- synchronous blocking REQ/REP or async DEALER/ROUTER for CALLs
- at-least-once delivery (confirms after processing) or at-most-once
(confirms before processing)
- do we want fault tolerant CALL and/or CAST, NOTIFY (AFAIK, zeromq
supports HA only for REQ/REP, ROUTER/DEALER)
- idempotent/commutative operations or ordered and non-idempotent

On all above I believe it is best to keep oslo messaging simple and
predictable, then have apps deal with any retry logic as it is really app
specific.
Auto retries in oslo messaging can cause confusion with possible
duplicates which could be really bad if the messages are not idempotent.
I think trying to make oslo messaging a complex communication API is not
realistic with the few resources available.
It is much better to have something simple that works well (even that is
not easy as we can see) than something complex that has lots of issues.


- event based notifications on changes in the numbers of clients and
servers (affects the discovery service very much)
- routing proxies and discovery service backends

Yes I'd like to help on that part.


3) Address all of the ambiguities of the API documentation in order to
keep messaging library developers and apps developers at the same
page. This is a vital step as the new driver -as well as the existing
ones- have to rely on well known and clearly described expectations and
behave appropriately.

I'm glad to see more people converging on this shortcoming and the need to
do something.

As I said above, I would keep the oslo messaging API straight and simple
and predictable.
The issue with that is it may make the AMQP driver non compliant as it may
be doing too much already but we can try to work it out.
We should avoid having app code having to behave differently (with if/else
based on the driver or driver specific plugins) but maybe that will not be
entirely unavoidable.

I'll give a short 

[openstack-dev] [Senlin] TOSCA Reference Material

[Julio E Ruano]

Hi All,

I just wanted to share where all of the TOSCA reference material is 
accessible. It is maintained through an OASIS TC here - 
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca 

The latest relevant spec is available here - 
https://www.oasis-open.org/committees/download.php/56070/TOSCA-Simple-Profile-YAML-v1.0-wd06-rev05.docx
 


Of immediate synergy with Senlin is probably the discussion around 
policies starting on page #240 of the spec. Much of this is still in the 
definition stage, so there is opportunity to have Senlin influence the 
spec as well as to allow Senlin to adopt some of the definitions within 
the spec.

Regards,

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

[openstack-dev] Meeting Thursday July 16th at 17:00UTC

[Christopher Aedo]

Hello! Our next OpenStack App Catalog meeting will take place this
Thursday July 16th at 17:00 UTC in #openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Please add agenda items if there's anything specific you would like to
discuss.  For this weeks meeting my primary intention is to discuss
the roadmap, everything we'd like to accomplish before the next
summit, and determine who all will be helping get it done.

Please join us if you can!

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

Re: [openstack-dev] [magnum] Magnum Midcycle Event Scheduling Doodle Poll closes July 7th

[Adrian Otto]

Team,

Thanks everyone for your feedback. The Magnum Midcycle for the Liberty release 
will be held on 2015-08-05 and 2015-08-06. I look forward to seeing you all 
there.

Regards,

Adrian Otto

On Jul 1, 2015, at 11:03 AM, Steven Dake (stdake) 
std...@cisco.commailto:std...@cisco.com wrote:

Apologies for double post – left off [magnum] prior by error.

Ton Ngo of IBM Silicon Valley Research has graciously offered to host the 2 day 
Magnum midcycle event at IBM’s facilities.

The sessions will run from 9AM – 5PM and catered lunch and refreshments 
(soda/water) will be provided.

The mid-cycle will be a standard mid-cycle with a 1 hour introduction followed 
by two days of design sessions.

Please cast your votes on any days you can make.

http://doodle.com/pinkuc5hw688zhxw

There are ~25 seats available.  Preference will be given to in-person core 
reviewers, followed by any folks that have made commits to the repository.  
After dates are settled, a separate eventbrite event will be setup to sort out 
the specifics such as  dietary needs, etc and confirm in-person seating if we 
are past capacity limits.

We will make remote participation available, but the experience will likely be 
less then optimal for remote participants.

Regards
-steve


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

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

[Doug Wiegley]

Can we setup a short IRC meeting to sync up on details?  1600utc on thursday, 
maybe? Other?

Thanks,
doug

 On Jul 13, 2015, at 4:02 PM, Praveen Yalagandula yprav...@avinetworks.com 
 wrote:
 
 Hi Vivek,
 
 I can help on this effort. Thanks for leading this!
 
 We had done some work to add Certificates support to the current 
 loadbalancer panel, which we put out for public access at 
 https://github.com/avinetworks/avi-horizon-dashboard 
 https://github.com/avinetworks/avi-horizon-dashboard. Essentially, this 
 adds a Certificates tab to manage SSL certificates (though currently the 
 code communicates with our controller, but could be changed to invoke 
 Barbican APIs), and also adds Associate Cert and Disassociate Cert to the 
 current pool drop down links (see the images below). Note that we did this 
 way as v1.0 APIs did not have support for certificates, and we implement 
 associate/disassociate by having Horizon talk directly to the our controller.
 
 Cheers,
 Praveen
 
 image.png
 image.png
 
 On Mon, Jul 13, 2015 at 2:05 PM, Jain, Vivek vivekj...@ebay.com 
 mailto:vivekj...@ebay.com wrote:
 Hi German,
 
 We integrated UI with LBaaS v2 GET APIs. We have created all panels for
 CREATE and UPDATE as well.
 Plan is to share our code with community on stackforge for more
 collaboration from the community.
 
 So far Ganesh from cisco has shown interest in helping with some work. It
 will be great if we can get more hands.
 
 Q: what is the process for hosting in-progress project on stackforge? Can
 someone help me here?
 
 Thanks,
 Vivek
 
 On 7/10/15, 11:40 AM, Eichberger, German german.eichber...@hp.com 
 mailto:german.eichber...@hp.com
 wrote:
 
 Hi Vivek,
 
 Hope things are well. With the Midccyle next week I am wondering if you
 made any progress and/or how we can best help with the panels.
 
 Thanks,
 German
 
 From: Jain, Vivek vivekj...@ebay.com 
 mailto:vivekj...@ebay.commailto:vivekj...@ebay.com 
 mailto:vivekj...@ebay.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org 
 mailto:openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
  mailto:openstack-...@lists.openstack.or
 g
 Date: Wednesday, April 8, 2015 at 3:32 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org 
 mailto:openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
  mailto:openstack-...@lists.openstack.or
 g
 Cc: Balle Balle, Susanne
 susanne.ba...@hp.com 
 mailto:susanne.ba...@hp.commailto:susanne.ba...@hp.com 
 mailto:susanne.ba...@hp.com, Tonse, Milan
 mto...@ebay.com mailto:mto...@ebay.commailto:mto...@ebay.com 
 mailto:mto...@ebay.com
 Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2
 
 Thanks German for the etherpad link. If you have any documentation for
 flows, please share those too.
 
 I will work with my team at ebay to publish wireframes for design we are
 working on. It will be mostly along the lines I demo’ed in Paris.
 
 Thanks,
 Vivek
 
 From: Eichberger, German
 german.eichber...@hp.com 
 mailto:german.eichber...@hp.commailto:german.eichber...@hp.com 
 mailto:german.eichber...@hp.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org 
 mailto:openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
  mailto:openstack-...@lists.openstack.or
 g
 Date: Wednesday, April 8, 2015 at 11:24 AM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org 
 mailto:openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
  mailto:openstack-...@lists.openstack.or
 g
 Cc: Balle, Susanne susanne.ba...@hp.com 
 mailto:susanne.ba...@hp.commailto:susanne.ba...@hp.com 
 mailto:susanne.ba...@hp.com
 Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2
 
 Hi,
 
 We briefly talked about it a few Neutron meetings back (LBaaS is now on
 demand) and created an etherpad to track things:
 https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases 
 https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases
 
 Susanne and I met with HP’s UX designer to work on the design for some
 flows for the Horizon panel (cc’d) but I am glad that Vivek is taking the
 lead. Please check that etherpad for more information and feel free to
 update as things happen…
 
 Thanks,
 German
 
 
 From: Jain, Vivek [mailto:vivekj...@ebay.com mailto:vivekj...@ebay.com]
 Sent: Tuesday, April 07, 2015 9:01 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2
 
 Hi Evgeny,
 We have just started working on Horizon lbaasv2 support. I have to sync
 up with my team on the time-line but it is not targeted for Kilo release.
 Since it is a major effort, we will need more hands. Let me know if
 anyone is interested to contribute.
 
 On a 

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

[Akihiro Motoki]

Another option is to create a project under openstack.
designate-dashboard project takes this approach,
and the core team of the project is both horizon-core and designate-core.
We can do the similar approach. Thought?

I have one question.
Do we have a separate place forever or do we want to merge horizon repo
once the implementation are available.
If we have a separate repo for LBaaS v2 panel, we need to release it
separately.

I am not sure I am available at LBaaS meeting, but I would like to help
this efforts as a core from horizon and neutron.

Akihiro


2015-07-15 1:52 GMT+09:00 Doug Wiegley doug...@parksidesoftware.com:

 I’d be good submitting it to the neutron-lbaas repo, under a horizon/
 directory. We can iterate there, and talk with the Horizon team about how
 best to integrate. Would that work?

 Thanks,
 doug

  On Jul 13, 2015, at 3:05 PM, Jain, Vivek vivekj...@ebay.com wrote:
 
  Hi German,
 
  We integrated UI with LBaaS v2 GET APIs. We have created all panels for
  CREATE and UPDATE as well.
  Plan is to share our code with community on stackforge for more
  collaboration from the community.
 
  So far Ganesh from cisco has shown interest in helping with some work. It
  will be great if we can get more hands.
 
  Q: what is the process for hosting in-progress project on stackforge? Can
  someone help me here?
 
  Thanks,
  Vivek
 
  On 7/10/15, 11:40 AM, Eichberger, German german.eichber...@hp.com
  wrote:
 
  Hi Vivek,
 
  Hope things are well. With the Midccyle next week I am wondering if you
  made any progress and/or how we can best help with the panels.
 
  Thanks,
  German
 
  From: Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com
  Reply-To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.orgmailto:
 openstack-...@lists.openstack.or
  g
  Date: Wednesday, April 8, 2015 at 3:32 PM
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.orgmailto:
 openstack-...@lists.openstack.or
  g
  Cc: Balle Balle, Susanne
  susanne.ba...@hp.commailto:susanne.ba...@hp.com, Tonse, Milan
  mto...@ebay.commailto:mto...@ebay.com
  Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
  neutron-lbaas v2
 
  Thanks German for the etherpad link. If you have any documentation for
  flows, please share those too.
 
  I will work with my team at ebay to publish wireframes for design we are
  working on. It will be mostly along the lines I demo’ed in Paris.
 
  Thanks,
  Vivek
 
  From: Eichberger, German
  german.eichber...@hp.commailto:german.eichber...@hp.com
  Reply-To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.orgmailto:
 openstack-...@lists.openstack.or
  g
  Date: Wednesday, April 8, 2015 at 11:24 AM
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.orgmailto:
 openstack-...@lists.openstack.or
  g
  Cc: Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com
 
  Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
  neutron-lbaas v2
 
  Hi,
 
  We briefly talked about it a few Neutron meetings back (LBaaS is now on
  demand) and created an etherpad to track things:
  https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases
 
  Susanne and I met with HP’s UX designer to work on the design for some
  flows for the Horizon panel (cc’d) but I am glad that Vivek is taking
 the
  lead. Please check that etherpad for more information and feel free to
  update as things happen…
 
  Thanks,
  German
 
 
  From: Jain, Vivek [mailto:vivekj...@ebay.com]
  Sent: Tuesday, April 07, 2015 9:01 AM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
  neutron-lbaas v2
 
  Hi Evgeny,
  We have just started working on Horizon lbaasv2 support. I have to sync
  up with my team on the time-line but it is not targeted for Kilo
 release.
  Since it is a major effort, we will need more hands. Let me know if
  anyone is interested to contribute.
 
  On a related note, Do we have a sample code which uses neutronclient
  lbaas v2 methods? That will greatly speedup our horizon integration.
 
  Thanks,
  Vivek
 
  From: Phillip Toohill
  phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com
  Reply-To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.orgmailto:
 openstack-...@lists.openstack.or
  g
  Date: Tuesday, April 7, 2015 at 7:50 AM
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.orgmailto:
 openstack-...@lists.openstack.or
  g
  Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
  neutron-lbaas v2
 
 
  ​Hey Evgeny,
 
 
 
  I believe Vivek is working on Horizon lbaasv2 support. We werent given a
  timeline or anything but sounds like its being actively worked on. I
  would reach out to him to get 

[openstack-dev] [app-catalog] IRC Meeting Thursday July 16th at 17:00UTC

[Christopher Aedo]

(Apologies for the re-send, missed the appropriate tag on the subject line!)

Hello! Our next OpenStack App Catalog meeting will take place this
Thursday July 16th at 17:00 UTC in #openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Please add agenda items if there's anything specific you would like to
discuss.  For this weeks meeting my primary intention is to discuss
the roadmap, everything we'd like to accomplish before the next
summit, and determine who all will be helping get it done.

Please join us if you can!

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

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

[Jain, Vivek]

1600utc on Thursday (9am PDT  Thursday) works for me. Can we use 
#openstack-lbaas channel ?

I have committed under development lbaas v2 horizon code to my public github 
and will move it to neutron-lbaas: https://github.com/openstack/neutron-lbaas

Thanks,
Vivek

From: Doug Wiegley 
doug...@parksidesoftware.commailto:doug...@parksidesoftware.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, July 14, 2015 at 9:53 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com, 
Tonse, Milan mto...@ebay.commailto:mto...@ebay.com
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

Can we setup a short IRC meeting to sync up on details?  1600utc on thursday, 
maybe? Other?

Thanks,
doug

On Jul 13, 2015, at 4:02 PM, Praveen Yalagandula 
yprav...@avinetworks.commailto:yprav...@avinetworks.com wrote:

Hi Vivek,

I can help on this effort. Thanks for leading this!

We had done some work to add Certificates support to the current loadbalancer 
panel, which we put out for public access at 
https://github.com/avinetworks/avi-horizon-dashboard. Essentially, this adds a 
Certificates tab to manage SSL certificates (though currently the code 
communicates with our controller, but could be changed to invoke Barbican 
APIs), and also adds Associate Cert and Disassociate Cert to the current 
pool drop down links (see the images below). Note that we did this way as v1.0 
APIs did not have support for certificates, and we implement 
associate/disassociate by having Horizon talk directly to the our controller.

Cheers,
Praveen

image.png
image.png

On Mon, Jul 13, 2015 at 2:05 PM, Jain, Vivek 
vivekj...@ebay.commailto:vivekj...@ebay.com wrote:
Hi German,

We integrated UI with LBaaS v2 GET APIs. We have created all panels for
CREATE and UPDATE as well.
Plan is to share our code with community on stackforge for more
collaboration from the community.

So far Ganesh from cisco has shown interest in helping with some work. It
will be great if we can get more hands.

Q: what is the process for hosting in-progress project on stackforge? Can
someone help me here?

Thanks,
Vivek

On 7/10/15, 11:40 AM, Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com
wrote:

Hi Vivek,

Hope things are well. With the Midccyle next week I am wondering if you
made any progress and/or how we can best help with the panels.

Thanks,
German

From: Jain, Vivek 
vivekj...@ebay.commailto:vivekj...@ebay.commailto:vivekj...@ebay.commailto:vivekj...@ebay.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.ormailto:openstack-...@lists.openstack.or
g
Date: Wednesday, April 8, 2015 at 3:32 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.ormailto:openstack-...@lists.openstack.or
g
Cc: Balle Balle, Susanne
susanne.ba...@hp.commailto:susanne.ba...@hp.commailto:susanne.ba...@hp.commailto:susanne.ba...@hp.com,
 Tonse, Milan
mto...@ebay.commailto:mto...@ebay.commailto:mto...@ebay.commailto:mto...@ebay.com
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
neutron-lbaas v2

Thanks German for the etherpad link. If you have any documentation for
flows, please share those too.

I will work with my team at ebay to publish wireframes for design we are
working on. It will be mostly along the lines I demo’ed in Paris.

Thanks,
Vivek

From: Eichberger, German
german.eichber...@hp.commailto:german.eichber...@hp.commailto:german.eichber...@hp.commailto:german.eichber...@hp.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.ormailto:openstack-...@lists.openstack.or
g
Date: Wednesday, April 8, 2015 at 11:24 AM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.ormailto:openstack-...@lists.openstack.or
g
Cc: Balle, Susanne 
susanne.ba...@hp.commailto:susanne.ba...@hp.commailto:susanne.ba...@hp.commailto:susanne.ba...@hp.com
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
neutron-lbaas v2

Hi,

We briefly talked about it a few Neutron meetings back (LBaaS is now on
demand) and created an etherpad to track things:
https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases

Susanne and I met with HP’s UX designer to work on the design for some
flows for the Horizon panel (cc’d) but I am glad that Vivek is taking the
lead. Please 

Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master

[Joshua Harlow]

Ihar Hrachyshka wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/14/2015 01:46 AM, Perry, Sean wrote:

-Original Message- From: Doug Hellmann
[mailto:d...@doughellmann.com] Sent: Monday, July 13, 2015 3:41
PM To: openstack-dev Subject: Re: [openstack-dev] [all] Time to
remove Python2.6 jobs from master

Excerpts from Robert Collins's message of 2015-07-14 09:05:43
+1200:

On 14 July 2015 at 02:10, Jeremy Stanleyfu...@yuggoth.org
wrote:

On 2015-07-13 09:39:36 -0400 (-0400), Doug Hellmann wrote:
[...]

On the other hand, how much longer will we be supporting
Juno? A matter of months, right?

The reason it's being brought up again at this point is to
ask whether it's more important that we keep master
clients/libs working with 2.6 for several more months, or be
able to push forward with our constraints overhaul between
now and then. I'll be hard to have the necessary tooling in
place before the liberty release if we can't actually use it
before then (since that's roughly when juno EOL is
scheduled).

Additional detail: - generating 2.6 pins for global
requirements requires access to 2.6 where the periodic job runs
*and where devs are generating updates*. - so that means docker
or lxc or something in both the CI system and widely available
for devs.

So its a non-trivial impact; we can do it to move things
forward, but it would be a lot cheaper not to.

I don't *want* to keep 2.6 support around, and I do understand
that the requirements work will be made easier.  I'm just trying
to understand what other impact dropping it will have.


It will break RHEL 5 (maybe early 6 too) and older RH systems.
Ubuntu older than 9 I think (which is beyond unsupported). Not sure
about other Linux dists.

Basically if RHEL 5 is no longer a valid target and we are sure all
of the 6s have updated then let's nuke it from orbit.



I don't believe there was any release of RHEL-OSP that targeted RHEL
5. As for RHEL 6, the last version that got support for it was OSP5
which is based on Icehouse.

Speaking of RDO, there were attempts to get nova pieces of Juno
backported to RHEL 6 (mostly for CERN). Other than that, I don't think
anyone considers to run anything Kilo+ on RHEL 6, and it will probably
fail to work properly since a lot of underlying platform components in
RHEL 6 would be not ready for new features. (RHEL-OSP could
potentially get all the needed pieces in place, but there was a
decision not to go this route and instead require RHEL 7 for anything
Juno+).



Just a side-note, people have gotten kilo+ to run on RHEL6.x using 
virtualenvs and SCL python2.7 using http://anvil.readthedocs.org/ so 
it's not out of the realm of possible ;)


Not everyone can upgrade to RHEL7.x 'in a jiffy' when u have a large 
cloud with a ton of RHEL6.x hypervisors that people rely on, eventually 
it will happen, but not always so quickly ;)



Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVpMlOAAoJEC5aWaUY1u57aqMH/jUqVjZeYTFGIG5ncxU62IuU
Jenu/c5GaGiwMdU4dDG4x25hH6NRN3vNmbXE6oF5HrkbCq7oqih7IjoTI/3Wfo6U
Pwk951VU986duN8syxH+dINWZiOrZ8UNDgO2VI3Tn15TUG/S3eZtMTuM9BHoLn2K
cQYlqZrKQnKVK+zNHdZI7X58P728BNeWONUl5ry7mwOZcWDs7PzvsGJ1t8zrDsE4
sGT3QT3x9VCi+tVD17DW7ZuBA+W1oVtNp3RdDkIN5fsaSE0WDZPr9PPW6jIxHNKo
BP+GS7GPvqZEOK2A4I1foZg6tpkDYlxQo1D5Pz7Ep/9LIDahvE5EUQHRQoUPVH8=
=CuFo
-END PGP SIGNATURE-

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


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

Re: [openstack-dev] [magnum] The way magnum-conductor communicates with k8s master

[Adrian Otto]

On Jul 13, 2015, at 8:40 PM, Steven Dake (stdake) 
std...@cisco.commailto:std...@cisco.com wrote:



From: OTSUKA, Motohiro yuany...@oeilvert.orgmailto:yuany...@oeilvert.org
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, July 13, 2015 at 8:11 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [magnum] The way magnum-conductor communicates 
with k8s master

Hi, Wanghua

  Currently magnum-conductor can communicates with k8s master which has a 
floating ip in all-in-one deployment. But if magnum-conductor is not deployed 
on the neutron network node which has the br-ex, how can magnum-conductor 
communicate with k8s master. The magnum-conductor node then has no access to 
the k8s master.
Currently this is a limitation of our architecture.


The floating IP is a public routed network, so it should be able to communicate 
in a properly setup cloud.

  Another question:
  Magnum-conductor only communicate with k8s master, why k8s minion has a 
floating ip too? What is the floating ip of k8s minion used for?

I think, there is no reason.
Historically, Our heat template come from larsks/heat-kubernetes [1] template.
larsks/heat-kubernetes provides floating ip to minion nodes, this is just a 
reason.

The minion floating ips are needed to access the micro-service front ends from 
the internet.

To be clear, the actual requirement is that the minion nodes must be able to 
make TCP connections to the master node. Depending on the routing setup on your 
nodes, and the arrangement of your network, that could be possible without a 
floating ip on the minion nodes. With that in mind, having a publicly routable 
address (floating ip) on your minion node is one way to produce such 
connectivity.

I’m sure we would be open to a proposal that eliminates our requirement for the 
floating ip on the minion nodes that would work properly in various network 
environments.

Adrian


Regards
-steve



[1]: https://github.com/larsks/heat-kubernetes

Thanks
-Yuanying

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

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

[openstack-dev] [Congress] New IRC meeting time

[Tim Hinrichs]

To better accommodate the active contributors, we're moving our IRC meeting
to

2300 UTC = 4p Pacific = 7p Eastern
#openstack-meeting-3

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

Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper

[Adrian Otto]

Peng,

On Jul 13, 2015, at 8:37 PM, Peng Zhao p...@hyper.shmailto:p...@hyper.sh 
wrote:

Thanks Adrian!

Hi, all,

Let me recap what is hyper and the idea of hyperstack.

Hyper is a single-host runtime engine. Technically,
Docker = LXC + AUFS
Hyper = Hypervisor + AUFS
where AUFS is the Docker image.

I do not understand the last line above. My understanding is that AUFS == 
UnionFS, which is used to implement a storage driver for Docker. Others exist 
for btrfs, and devicemapper. You select which one you want by setting an option 
like this:

DOCKEROPTS=-s devicemapper”

Are you trying to say that with Hyper, AUFS is used to provide layered Docker 
image capability that are shared by multiple hypervisor guests?

My guess is that you are trying to articulate that a host running Hyper is a 
1:1 substitute for a host running Docker, and will respond using the Docker 
remote API. This would result in containers running on the same host that have 
a superior security isolation than they would if LXC was used as the backend to 
Docker. Is this correct?

Due to the shared-kernel nature of LXC, Docker lacks of the necessary isolation 
in a multi-tenant CaaS platform, and this is what Hyper/hypervisor is good at.

And because of this, most CaaS today run on top of IaaS: 
https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/388x275/e286dea1266b46c1999d566b0f9e326b/iaas.png
Hyper enables the native, secure, bare-metal CaaS  
https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/395x244/828ad577dafb3f357e95899e962651b2/caas.png

From the tech stack perspective, Hyperstack turns Magnum o run in parallel with 
Nova, not running on atop.

For this to work, we’d expect to get a compute host from Heat, so if the bay 
type were set to “hyper”, we’d need to use a template that can produce a 
compute host running Hyper. How would that host be produced, if we do not get 
it from nova? Might it make more sense to make a dirt driver for nova that 
could produce a Hyper guest on a host already running the nova-compute agent? 
That way Magnum would not need to re-create any of Nova’s functionality in 
order to produce nova instances of type “hyper”.

Is Hyper compatible with libvirt?

Can Hyper support nested Docker containers within the Hyper guest?

Thanks,

Adrian Otto


Best,
Peng

-- Original --
From:  Adrian 
Ottoadrian.o...@rackspace.commailto:adrian.o...@rackspace.com;
Date:  Tue, Jul 14, 2015 07:18 AM
To:  OpenStack Development Mailing List (not for usage 
questions)openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org;
Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper

Team,

I woud like to ask for your input about adding support for Hyper in Magnum:

https://blueprints.launchpad.net/magnum/+spec/hyperstack

We touched on this in our last team meeting, and it was apparent that achieving 
a higher level of understanding of the technology before weighing in about the 
directional approval of this blueprint. Peng Zhao and Xu Wang have graciously 
agreed to respond to this thread to address questions about how the technology 
works, and how it could be integrated with Magnum.

Please take a moment to review the blueprint, and ask your questions here on 
this thread.

Thanks,

Adrian Otto

On Jul 2, 2015, at 8:48 PM, Peng Zhao p...@hyper.shmailto:p...@hyper.sh 
wrote:

Here is the bp of Magnum+Hyper+Metal integration: 
https://blueprints.launchpad.net/magnum/+spec/hyperstack

Wanted to hear more thoughts and kickstart some brainstorming.

Thanks,
Peng

-
Hyper - Make VM run like Container


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

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

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

[openstack-dev] [Heat] conditional resource exposure - second thoughts

[Pavlo Shchelokovskyy]

Hi Heaters,

currently we already expose to the user only resources for services
deployed in the cloud [1], and soon we will do the same based on whether
actual user roles allow creating specific resources [2]. Here I would like
to get your opinion on some of my thoughts regarding behavior of
resource-type-list, resource-type-show and template-validate with this new
features.

resource-type-list
We already (or soon will) hide unavailable in the cloud / for the user
resources from the listing. But what if we add an API flag e.g. --all to
show all registered in the engine resources? That would give any user a
glimpse of what their Orchestration service can manage in principle, so
they can nag the cloud operator to install additional OpenStack components
or give them required roles :)

resource-type-show
Right now the plan is to disable showing unavailable to the user
resources. But may be we should leave this as it is, for the same purpose
as above (or again add a --all flag or such)?

template-validate
Right now Heat is failing validation for templates containing resource
types not registered in the engine (e.g. typo). Should we also make this
call available services- and roles-sensitive? Or should we leave a way for
a user to check validity of any template with any in principle supported
resources?

The bottom line is we are good in making Heat service to be as much
self-documented via its own API as possible - let's keep doing that and
make any Heat deployment to be the Heat primer :)

Eager to hear your opinions.

[1]
http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-services.html

[2]
http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-roles.html

Best regards,
 --
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-announce] End of life for managed stable/icehouse branches

[Thomas Goirand]

On 07/14/2015 03:55 AM, Jeremy Stanley wrote:
 On 2015-07-14 00:33:52 +0200 (+0200), Thomas Goirand wrote:
 [...]
 I believe I asked you about 10 times to keep these branches alive, so
 that distributions could work together on a longer support, even without
 a CI behind it.
 
 And the project consensus has seemed to disagree with this after
 careful discussion, each time it's brought up. Distributions
 collaborating upstream on stable branch support would entail helping
 keep those branches tested upstream. As a project we've consistently
 stated that publishing updates to stable branches without sufficient
 testing is an affront to our quality assurance stance. The final
 state of the upstream stable/icehouse branch, as with each previous
 stable branch all the way back to stable/diablo, is tagged in the
 repository so that you can construct your own continuation of
 stable/icehouse from the same point as needed.
 
 I have also asked for a private gerrit for maintaining the Icehouse
 patches after EOL.
 [...]
 
 I do apologize for not setting up a separate private Gerrit instance
 for embargoed security fix code reviewing. It would be a help to me
 and the rest of the VMT to have it, I simply haven't had the
 available time I'd hoped to be able to work out remaining
 implementation details for deploying and maintaining it. That said,
 its priority has decreased as the VMT is trying to get a little more
 cautious about only embargoing vulnerability reports that actually
 benefit enough from a brief advance notice to downstream
 stakeholders to offset the significant cost in efficiency of the
 embargo process (only a small amount of which is due to the tools we
 end up using for private code review).
 
 However, as I explained to you at the Liberty Design Summit after
 discussion with members of the infrastructure team, we're also not
 comfortable maintaining stable branches of projects in a private
 Gerrit instance any longer than we do in the normal public one, and
 would want to remove inactive branches from it at the same time
 their public counterparts reach end of life.
 
 Since I feel like I'm starting to repeat myself at this point, I'll
 leave it to others to continue the thread this time. If you're
 interested in overhauling the stable branch EOL process (I didn't
 design and plan it, I merely pull the levers and push the buttons),
 that discussion should involve the stable branch release managers
 and the rest of the release team along with the quality assurance
 team.

Jeremy,

I'm very disappointed, because this isn't at all what I've been told
during each and every summit since the release of Icehouse.

The conversations we had during all summits were all about you (and
others) saying that it was really ok to not destroy the branches. Never
you raised your concern about any issue, and I was counting on this to
organize security support for Icehouse for embargoed issues.

While I do understand that you didn't have time for this private gerrit,
I don't get why it's not ok to just leave the branch open, without the
CI (you could rename the branch if you didn't want to show any blessing
from the project).

Now, since the upstream OpenStack doesn't offer any help for Icehouse
which absolutely *all* downstream distributions offer LTS support, we're
back to what I feared from the start: chaos and no serious coordination
possible between distros, unless we do absolutely everything by
ourselves (including the infrastructure to host a gerrit and share
patches). I will *not* have the time to do this.

I just hope individual project members will help doing some of the
backport work.

Cheers,

Thomas Goirand (zigo)


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

Re: [openstack-dev] [openstack-announce] End of life for managed stable/icehouse branches

[Thomas Goirand]

On 07/14/2015 10:29 AM, Ihar Hrachyshka wrote:
 On 07/14/2015 12:33 AM, Thomas Goirand wrote:
 I missed this announce...
 
 On 07/02/2015 05:32 AM, Jeremy Stanley wrote:
 Per the Icehouse EOL discussion[1] last month, now that the
 final 2014.1.5 release[2] is behind us I have followed our usual
 end of life steps for stable/icehouse branches on repos under the
 control of the OpenStack Release Cycle Management project-team. 
 Specifically, for any repos with the release:managed[3] tag, 
 icehouse-specific test jobs were removed from our CI system and
 all open change reviews were abandoned for stable/icehouse. Then
 the final states of the branches were tagged as icehouse-eol
 and the branches subsequently deleted.
 
 I believe I asked you about 10 times to keep these branches alive,
 so that distributions could work together on a longer support, even
 without a CI behind it.
 
 I have also asked for a private gerrit for maintaining the
 Icehouse patches after EOL.
 
 While I understand the later means some significant work, I don't 
 understand why you have deleted the Icehouse branches.
 
 Effectively, under these conditions, I am giving up doing any kind
 of coordination between distros for security patches of Icehouse.
 :(
 
 As far as I know, there was no real coordination on those patches
 before, neither I saw any real steps from any side to get it up.

Well... as far as I know, you were not there during the conversations we
had at the summits about this. Neither you are on my list of Icehouse
security persons. So I fail to see how you could be in the loop for this
indeed.

 That said, anyone can come up with an initiative to maintain those
 branches under some 3party roof (just push -eol tag into github and
 advertise), and if there is real (and not just anticipated)
 collaboration going on around it, then the project may reconsider
 getting it back in the big stadium.

I have a list of contacts for each and every downstream distributions.
All of them agreed to work under this coordinated Git repo, so that we
share the same patch. The only issue is that during embargo period, we
can't discuss this type of patches in public. Which is why a private
gerrit was the way to go. Though for not-embargoed stuff, we could well
have used the already existing Gerrit infrastructure, without a CI (as
all distro are running their own tests anyway).

 I am tired to say that again and again, but there should be some
 resource investment from interested parties, upfront, before infra
 takes part of the burden on their shoulders. Asking won't help.

How do you expect to see anything happening before Icehouse effectively
gets EOL? By the way, I haven't asked anything but *not* doing
something. I don't see how much burden I'm putting on infra here.

Cheers,

Thomas Goirand (zigo)

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

Re: [openstack-dev] [all][tests] Fix it friday! [mock failure in CI]

[Robert Collins]

On 13 July 2015 at 13:04, Dave McCowan (dmccowan) dmcco...@cisco.com wrote:
 Has anyone else seen this error with the new mock?

 'self' parameter lacking default value


 My function under test runs correctly, but then Mock throws this TypeError
 when comparing the parameters in assert_calls_with().

 I'm seeing this in Barbican.  More info below [1][2].

 --Dave

 [1] Complete backtrace
 ==
 FAIL:
 barbican.tests.plugin.test_kmip.WhenTestingKMIPSecretStore.test_store_passp
 hrase_secret_assert_called
 --
 _StringException: Traceback (most recent call last):
   File /Users/dmccowan/barbican/barbican/tests/plugin/test_kmip.py, line
 432, in test_store_passphrase_secret_assert_called
 credential=self.credential)
   File
 /Users/dmccowan/.pyenv/versions/barb278/lib/python2.7/site-packages/mock/m
 ock.py, line 941, in assert_called_once_with
 return self.assert_called_with(*args, **kwargs)
   File
 /Users/dmccowan/.pyenv/versions/barb278/lib/python2.7/site-packages/mock/m
 ock.py, line 930, in assert_called_with
 six.raise_from(AssertionError(_error_message(cause)), cause)
   File
 /Users/dmccowan/.pyenv/versions/barb278/lib/python2.7/site-packages/six.py
 , line 692, in raise_from
 raise value
 AssertionError: Expected call: mock(credential=Struct(),
 object_type=ObjectType.SECRET_DATA: 7, secret=ANY,
 template_attribute=ANY)
 Actual call: mock(credential=Struct(),
 object_type=ObjectType.SECRET_DATA: 7, secret=Struct(),
 template_attribute=Struct())
 'self' parameter lacking default value

Please see if this is a problem in python 3.5's unittest.mock. If it
is: file it in the Python bug tracker (and +nosy me there
[rbcollins]). If its not a problem in python 3.5's unittest.mock, then
file it in the mock bug tracker, and I'll figure out why its behaving
differently.

Cheers,
Rob



-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [Openstack] Rescinding the M name decision

[David Medberry]

Thanks Lauren. Mi taco es su taco.

On Tue, Jul 14, 2015 at 12:53 PM, Lauren Sell lau...@openstack.org wrote:

 Good news. After finalizing the trademark checks and giving the community
 time to weigh in, Mitaka will be the name of the M release.

 Thanks again for the great discussion around this topic, and for the
 willingness to be responsive to the concerns of fellow community members.


  On Jul 9, 2015, at 2:18 PM, Tim Bell tim.b...@cern.ch wrote:
 
  Feel free to give input on the Mitaka proposal.
 
  Tim
 
  -Original Message-
  From: Jonathan Bryce [mailto:jbr...@jbryce.com]
  Sent: 09 July 2015 20:52
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Openstack] Rescinding the M name decision
 
  On Jul 9, 2015, at 9:35 AM, Russell Bryant rbry...@redhat.com wrote:
 
  On 07/09/2015 09:19 AM, Neil Jerram wrote:
  In the hope of forestalling an unnecessary sub-thread...
 
  Mita was #1 in the vote, so has presumably already been ruled out by
  OpenStack's legal review.
 
  That is correct.
 
 
  Hi everyone,
 
  I’ve really loved seeing everyone’s understanding and engagement on this
  thread as we worked through the release cycle naming for ‘M’. This was
 the
  first attempt to follow a new process, so not surprisingly, we found
 some
  improvements in the algorithm for the future. Still it’s awesome to see
 how
  constructive and positive the whole conversation has been.
 
  I wanted to provide a quick update on the status of the Foundation’s
  reviews of the names. First, as Russell mentioned above, after the
 voting
  was completed, we asked our trademark counsel to do checks on the top 3
  names. The first two both had significant trademark issues with existing
  trademark holders in the same space that would have prevented us from
  using the names in most jurisdictions where we have our largest
  communities (US, Europe and Asia). The 3rd choice was relatively low
 risk
  and so we passed word back to Monty who announced it. Once we realized
  there were other issues with Meiji, we asked for an expedited check of
 the
  next 3 names: Mitaka, Musashi, and Meguro. The preliminary check shows
  that Mitaka and Meguro both present an acceptable level of risk, while
  Musashi is higher on the risk scale and would probably create problems
 for
  usage.
 
  At this time, we’re going to do a deeper check on Mitaka, which was the
 #4
  candidate in voting and would be next in line after Meiji. I know
 Itoh-san
  mentioned the Mitaka locale has the potential to be associated with
 certain
  corporations in Japan, but my personal feeling is that may not be
 significant
  enough to override it’s position in the voting and it’s availability
 for use.
 
  I’d encourage anyone with other concerns about Mitaka to post those
  within the next 24 hours so we can appropriately consider and discuss
  them. We should have results on the deeper trademark check by next week
  as well and can hopefully settle on a final name.
 
  Thanks again for all the discussion and participation and especially to
  Monty who’s been on the front lines of helping us navigate this. Feel
 free to
  let me know if you have any other questions,
 
  Jonathan
  210-317-2438
 
 
  __
  
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: OpenStack-dev-
  requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

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

Re: [openstack-dev] [Cinder] python-cinderclient functional tests

[Ivan Kolodyazhny]

I've added this topic to the meeting agenda [1]

[1] https://wiki.openstack.org/wiki/CinderMeetings#Next_meeting

Regards,
Ivan Kolodyazhny

On Mon, Jul 13, 2015 at 10:23 PM, Matthew Treinish mtrein...@kortar.org
wrote:

 On Mon, Jul 13, 2015 at 12:04:05PM -0700, Mike Perez wrote:
  On 16:28 Jul 10, Ivan Kolodyazhny wrote:
   Hi Mike,
  
   Unfortunately, we don't get a lot of stats [1] because we don't run it
   often. I've added 'check experimental' comment to latest
   python-cinderclient review request to get more stats.
  
   Review request to make this voting:
 https://review.openstack.org/#/c/200522/
  
   [1]
  
 http://graphite.openstack.org/render/?width=877height=548_salt=1436533755.887from=00%3A00_20150524until=23%3A59_20150710target=stats.zuul.pipeline.experimental.job.check-cinderclient-dsvm-functional.FAILUREtarget=stats.zuul.pipeline.experimental.job.check-cinderclient-dsvm-functional.SUCCESStarget=stats.zuul.pipeline.experimental.openstack.python-cinderclient.total_changestitle=check-cinderclient-dsvm-functional
 
  Add an agenda item to the next Cinder meeting. Sure there should be no
  objections.
 

 Just an FYI that these tests used to always be voting until they were
 removed
 from tempest. [1][2] Almost every other project that did the same client
 test
 migration from tempest just made the new client specific jobs voting from
 the
 start so there was no loss in coverage. I'm not entirely sure why
 cinderclient
 got stuck as experimental jobs, but it doesn't seem overly contentious to
 me
 to just flip the switch.

 -Matt Treinish

 [1] https://review.openstack.org/#/c/178757/
 [2]
 http://lists.openstack.org/pipermail/openstack-dev/2015-April/063018.html

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


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

[openstack-dev] [Openstack][nova]

[Cale Rath]

Hi,

I created a patch to fail on the proxy call to Neutron for used limits, found 
here: https://review.openstack.org/#/c/199604/

This patch was done because of this: 
http://docs.openstack.org/developer/nova/project_scope.html?highlight=proxy#no-more-api-proxies
 
http://docs.openstack.org/developer/nova/project_scope.html?highlight=proxy#no-more-api-proxies,
 where it’s stated that Nova shouldn’t be proxying API calls.

That said, Matt Riedemann brings up the point that this breaks the case where 
Neutron is installed and we want to be more graceful, rather than just raising 
an exception.  Here are some options:

1. fail - (the code in the patch above)
2. proxy to neutron for floating ips and security groups - that's what the 
original change was doing back in havana
3. return -1 or something for floatingips/security groups to indicate that we 
don't know, you have to get those from neutron

Does anybody have an opinion on which option we should do regarding API proxies 
in this case?

Thanks,

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

Re: [openstack-dev] [Heat] conditional resource exposure - second thoughts

[Zane Bitter]

On 14/07/15 14:34, Pavlo Shchelokovskyy wrote:

Hi Heaters,

currently we already expose to the user only resources for services
deployed in the cloud [1], and soon we will do the same based on whether
actual user roles allow creating specific resources [2]. Here I would
like to get your opinion on some of my thoughts regarding behavior of
resource-type-list, resource-type-show and template-validate with this
new features.

resource-type-list
We already (or soon will) hide unavailable in the cloud / for the user
resources from the listing. But what if we add an API flag e.g. --all to
show all registered in the engine resources? That would give any user a
glimpse of what their Orchestration service can manage in principle, so
they can nag the cloud operator to install additional OpenStack
components or give them required roles :)


I worry that this could result in leakage of potentially-sensitive 
information. e.g. once we have this feature implemented, an operator 
could deploy a plugin that is only for the use of one particular user, 
who has a custom role. I don't think it would be expected that other 
users (without that role) in other tenants could find out about that, 
even if all they can find out is the name of the resource type.


I definitely think that admins should have a way of getting a list of 
_all_ resource types (preferably annotated with the roles required to 
use them). Just not ordinary users.



resource-type-show
Right now the plan is to disable showing unavailable to the user
resources. But may be we should leave this as it is, for the same
purpose as above (or again add a --all flag or such)?


This is totally unnecessary IMHO for the reasons Clint mentioned. Again, 
I could imagine an exception for admins though, since I suspect that 
this API is the only way we can annotate resource types with the roles 
required without performing major surgery on resource-type-list.



template-validate
Right now Heat is failing validation for templates containing resource
types not registered in the engine (e.g. typo). Should we also make this
call available services- and roles-sensitive? Or should we leave a way
for a user to check validity of any template with any in principle
supported resources?


You call template-validate when you're about to launch the template and 
you want to know what parameters and stuff are required. If YOU cannot 
launch THIS template on THIS cloud right NOW it should fail, period.


cheers,
Zane.


The bottom line is we are good in making Heat service to be as much
self-documented via its own API as possible - let's keep doing that and
make any Heat deployment to be the Heat primer :)

Eager to hear your opinions.

[1]
http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-services.html

[2]
http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-roles.html

Best regards,

--
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com


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




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

Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure - second thoughts

[Fox, Kevin M]

We're kind of debating the same thing for the app catalog. Do we show templates 
that don't work on a given cloud since they wont work, potentially making 
useful tools hard to discover, or do we view it as an opportunity for users to 
complain to their admins that they need X feature in order to do what they need 
to do. Last time we talked about it, we were leaning towards the latter.

Maybe a happy middle ground is to have enough smarts in the system to show the 
templates, identify what parts won't work, gray out the template but provide a 
ui to notifify the admin of desire for X to work. That way users can easily 
feed back their desires.

Thanks,
Kevin

From: Pavlo Shchelokovskyy [pshchelokovs...@mirantis.com]
Sent: Tuesday, July 14, 2015 11:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Heat] conditional resource exposure - second thoughts


Hi Heaters,

currently we already expose to the user only resources for services deployed in 
the cloud [1], and soon we will do the same based on whether actual user roles 
allow creating specific resources [2]. Here I would like to get your opinion on 
some of my thoughts regarding behavior of resource-type-list, 
resource-type-show and template-validate with this new features.

resource-type-list
We already (or soon will) hide unavailable in the cloud / for the user 
resources from the listing. But what if we add an API flag e.g. --all to show 
all registered in the engine resources? That would give any user a glimpse of 
what their Orchestration service can manage in principle, so they can nag the 
cloud operator to install additional OpenStack components or give them required 
roles :)

resource-type-show
Right now the plan is to disable showing unavailable to the user resources. 
But may be we should leave this as it is, for the same purpose as above (or 
again add a --all flag or such)?

template-validate
Right now Heat is failing validation for templates containing resource types 
not registered in the engine (e.g. typo). Should we also make this call 
available services- and roles-sensitive? Or should we leave a way for a user to 
check validity of any template with any in principle supported resources?

The bottom line is we are good in making Heat service to be as much 
self-documented via its own API as possible - let's keep doing that and make 
any Heat deployment to be the Heat primer :)

Eager to hear your opinions.

[1] 
http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-services.html

[2] 
http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-roles.html

Best regards,

--
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tests] Fix it friday! [mock failure in CI]

[Robert Collins]

On 14 July 2015 at 22:41, Kevin Benton blak...@gmail.com wrote:
 Oh, no I didn't. By the time I got around to it I saw 264 and figured that
 would cover the issue.

Ok - could you check? 1.1.3 has issue 264 fixed, and I'd like to fix
this one too, if its still an issue. Bonus points for checking against
3.5's unittest,mock too.

-Rob



-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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

[openstack-dev] [qa] identity v3 issue causing non-admin job to fail

[David Kranz]

Now that the tempest periodic jobs are back (thanks infra!), I was 
looking into the real failures. It seems the main one is caused by the 
fact that the v3 check for primary creds fails if 'admin_domain_name' in 
the identity section is None, which it is when devstack configures 
tempest for non-admin.


The problem is with this code and there is even a comment related to 
this issue. There are various ways to fix this but I'm not sure what the 
value should be for the non-admin case. Andrea, any ideas?


 -David

def get_credentials(fill_in=True, identity_version=None, **kwargs):
params = dict(DEFAULT_PARAMS, **kwargs)
identity_version = identity_version or CONF.identity.auth_version
# In case of v3 add the domain from config if not specified
if identity_version == 'v3':
domain_fields = set(x for x in 
auth.KeystoneV3Credentials.ATTRIBUTES

if 'domain' in x)
if not domain_fields.intersection(kwargs.keys()):
# TODO(andreaf) It might be better here to use a dedicated 
config

# option such as CONF.auth.tenant_isolation_domain_name
params['user_domain_name'] = CONF.identity.admin_domain_name
auth_url = CONF.identity.uri_v3
else:
auth_url = CONF.identity.uri
return auth.get_credentials(auth_url,
fill_in=fill_in,
identity_version=identity_version,
**params)


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

Re: [openstack-dev] [Openstack][nova] proxy quota/limits info from neutron

[Matt Riedemann]

On 7/14/2015 3:43 PM, Cale Rath wrote:

Hi,

I created a patch to fail on the proxy call to Neutron for used limits,
found here: https://review.openstack.org/#/c/199604/

This patch was done because of this:
http://docs.openstack.org/developer/nova/project_scope.html?highlight=proxy#no-more-api-proxies,
where it’s stated that Nova shouldn’t be proxying API calls.

That said, Matt Riedemann brings up the point that this breaks the case
where Neutron is installed and we want to be more graceful, rather than
just raising an exception.  Here are some options:

1. fail - (the code in the patch above)
2. proxy to neutron for floating ips and security groups - that's what
the original change was doing back in havana
3. return -1 or something for floatingips/security groups to indicate
that we don't know, you have to get those from neutron

Does anybody have an opinion on which option we should do regarding API
proxies in this case?

Thanks,

Cale Rath


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



I prefer the proxy option, despite that we don't want to do more proxies 
to other services, it's the least of all evils here in my opinion.


I don't think we can do #1, that breaks anyone using those APIs and is 
using Neutron, so it's a non-starter.


#3 is an API change in semantics which would at least be a microversion 
and is kind of clunky.


For #2 we at least have the nova.network.base_api which we didn't have 
in Havana when I was originally working on this, that would abstract the 
neutron-specific cruft out of the nova-api code.  The calls to neutron 
were pretty simple from what I remember - we could just resurrect the 
old patch:


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

Another option is #4, we mark the bug as won't fix and we log a warning 
if neutron is configured saying some of the resources aren't going to be 
correct, use the neutron API to get information for quotas on security 
groups, floating IPs, etc.  That's also kind of gross IMO, but it's an 
option.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [magnum] Tom Cammann for core

[Adrian Otto]

Tom,

It is my pleasure to welcome you to the magnum-core group. We are happy to have 
you on the team.

Regards,

Adrian

 On Jul 9, 2015, at 7:20 PM, Adrian Otto adrian.o...@rackspace.com wrote:
 
 Team,
 
 Tom Cammann (tcammann) has become a valued Magnum contributor, and consistent 
 reviewer helping us to shape the direction and quality of our new 
 contributions. I nominate Tom to join the magnum-core team as our newest core 
 reviewer. Please respond with a +1 vote if you agree. Alternatively, vote -1 
 to disagree, and include your rationale for consideration.
 
 Thanks,
 
 Adrian


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

Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure - second thoughts

[Randall Burt]

Making users complain to admins that may have little to no control over what is 
and isn't available isn't a healthy strategy for user experience. Purposefully 
engineering hardship to try and influence operators to do the right thing in 
someone else's opinion sounds pretty counter productive to adoption as well.

FWIW, as a user, I don't want to see things I can't use because it just wastes 
my time. I agree that the docs are a good place to see all the things while 
querying the service should tell me what's available to me at the time.

On Jul 14, 2015, at 4:20 PM, Fox, Kevin M kevin@pnnl.gov
 wrote:

 We're kind of debating the same thing for the app catalog. Do we show 
 templates that don't work on a given cloud since they wont work, potentially 
 making useful tools hard to discover, or do we view it as an opportunity for 
 users to complain to their admins that they need X feature in order to do 
 what they need to do. Last time we talked about it, we were leaning towards 
 the latter.
 
 Maybe a happy middle ground is to have enough smarts in the system to show 
 the templates, identify what parts won't work, gray out the template but 
 provide a ui to notifify the admin of desire for X to work. That way users 
 can easily feed back their desires.
 
 Thanks,
 Kevin
 From: Pavlo Shchelokovskyy [pshchelokovs...@mirantis.com]
 Sent: Tuesday, July 14, 2015 11:34 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Heat] conditional resource exposure - second 
 thoughts
 
 Hi Heaters,
 currently we already expose to the user only resources for services deployed 
 in the cloud [1], and soon we will do the same based on whether actual user 
 roles allow creating specific resources [2]. Here I would like to get your 
 opinion on some of my thoughts regarding behavior of resource-type-list, 
 resource-type-show and template-validate with this new features.
 resource-type-list
 We already (or soon will) hide unavailable in the cloud / for the user 
 resources from the listing. But what if we add an API flag e.g. --all to show 
 all registered in the engine resources? That would give any user a glimpse of 
 what their Orchestration service can manage in principle, so they can nag the 
 cloud operator to install additional OpenStack components or give them 
 required roles :)
 resource-type-show
 Right now the plan is to disable showing unavailable to the user resources. 
 But may be we should leave this as it is, for the same purpose as above (or 
 again add a --all flag or such)?
 template-validate
 Right now Heat is failing validation for templates containing resource types 
 not registered in the engine (e.g. typo). Should we also make this call 
 available services- and roles-sensitive? Or should we leave a way for a user 
 to check validity of any template with any in principle supported resources?
 The bottom line is we are good in making Heat service to be as much 
 self-documented via its own API as possible - let's keep doing that and make 
 any Heat deployment to be the Heat primer :)
 Eager to hear your opinions.
 [1] 
 http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-services.html
 [2] 
 http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-roles.html
 Best regards,
 -- 
 Dr. Pavlo Shchelokovskyy
 Senior Software Engineer
 Mirantis Inc
 www.mirantis.com
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Cinder] FFE Request: Re-add Quobyte Cinder Driver

[Mike Perez]

On 17:44 Jul 14, Silvan Kaiser wrote:
 Hello Cinder Community!
 I'd like to request a feature freeze exception for change [1], re-adding the 
 Quobyte driver to Cinder.
 
 The driver was removed in change [2] due to missing CI activity [3], it was 
 originally added in the kilo release [4].
 We've been able to remove the CI's issues and it has been reporting for a 
 week now [5], stably testing and consistently showing two bugs (one in Nova 
 and one in our driver/Cinder),
 referenced on the CIs status page [6]. We're monitoring the CI results 
 continuously and the detected bugs are beeing addressed.
 The complete logs can be reviewed at [7].
 CI status changes are published on the Quobyte CI Status page in the wiki 
 [6], where there’s also our contact information.
 Thanks a lot for considering and best regards
 Silvan Kaiser
 (kaisers/casusbelli in IRC)
 
 
 [1] https://review.openstack.org/#/c/201507/
 [2] https://review.openstack.org/#/c/191192/
 [3] http://lists.openstack.org/pipermail/openstack-dev/2015-July/068609.html
 [4] https://review.openstack.org/#/c/94186/
 [5] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069183.html
 [6] https://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI
 [7] http://176.9.127.22:8081/?C=M;O=D

The last 120 jobs have failed. Here's a paste of the 60 of them:

http://paste.openstack.org/show/375484/

-- 
Mike Perez

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

Re: [openstack-dev] [Keystone] Symbol not found: _BIO_new_CMS

[Kirill Zaitsev]

Just for the sake of future googlers. I’ve encountered the same problem (with 
horizon actually) and managed to solve it.

1) install and link latest openssl from homebrew: brew update  brew install 
openssl  brew link --force openssl
2) run tox, it fails.
3) manually activate the environment you want: . .tox/venv/bin/activate
4) build cryptography package with brew ssl: 
LDFLAGS=-L/usr/local/opt/openssl/lib CPPFLAGS=-I/usr/local/opt/openssl/include 
pip install --force-reinstall --upgrade --no-binary cryptography cryptography
5) deactivate

that’s it — that should do the trick. Someone might be able to suggest a better 
way to do this, but this variant works for me. (As long as I do not rebuild 
venv too often =))

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Symbol not found: _BIO_new_CMS

[Dolph Mathews]

Also for the sake of future googlers: we gave up on supporting keystone
development in OS X a release or two ago due to the increasing number of
workarounds like this that we had to track (a few of which impacted the
code base itself, and were thus dropped).

On Tue, Jul 14, 2015 at 3:42 PM, Kirill Zaitsev kzait...@mirantis.com
wrote:

 Just for the sake of future googlers. I’ve encountered the same problem
 (with horizon actually) and managed to solve it.

 1) install and link latest openssl from homebrew: brew update  brew
 install openssl  brew link --force openssl
 2) run tox, it fails.
 3) manually activate the environment you want: . .tox/venv/bin/activate
 4) build cryptography package with brew
 ssl: LDFLAGS=-L/usr/local/opt/openssl/lib
 CPPFLAGS=-I/usr/local/opt/openssl/include pip install --force-reinstall
 --upgrade --no-binary cryptography cryptography
 5) deactivate

 that’s it — that should do the trick. Someone might be able to suggest a
 better way to do this, but this variant works for me. (As long as I do not
 rebuild venv too often =))

 --
 Kirill Zaitsev
 Murano team
 Software Engineer
 Mirantis, Inc

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


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

Re: [openstack-dev] Juno Compute RPC v3.33 Endpoint Error when the Controller is running rabbitMQ v3.4.2

[Gregg Marxer]

3rd posting

Hi Experts,

I have a three node Juno system running on Ubuntu 14.04. On the compute node I 
keep getting the following Endpoint does not support RPC version 3.33 to caller 
error when I launch a Nova instance. The Controller is running rabbitMQ v3.4.2. 
So I do not understand why the compute node thinks the endpoint does not 
support v3.33. I tried both rabbitMQ v3.3.3 and v3.5 on the compute node with 
the same result. Data below. Any suggestions?

https://ask.openstack.org/en/question/69203/juno-controller-rabbitmq-v342-but-compute-node-v333-rpc-error/

Regards,

Gregg Marxer | Field Systems Engineer
O 949.631.6733   M 732.713.1361
f5.comhttps://www.f5.com/ | synthesis.f5.comhttps://synthesis.f5.com/

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

Re: [openstack-dev] [nova] Reminder: July 16 is non-priority feature proposal freeze

[John Garbutt]

On 14 July 2015 at 18:40, Ed Leafe e...@leafe.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 On 07/14/2015 05:52 AM, John Garbutt wrote:

 Please note, the non-priority feature freeze is on: July 30

So technically both are correct, neither are complete, oops:
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule

July 16: non-priority feature proposal freeze
July 30: liberty-2 -- non-priority feature freeze

Thanks,
John

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

Re: [openstack-dev] [Horizon] Liberty Mid Cycle Meetup

[Tripp, Travis S]

Hello everybody,

Just a reminder about the mid-cycle next week.  If you haven’t already, please 
add your name to the list[0] of people coming so we have a final head count on 
ordering morning / afternoon snacks. If your name is on the list and you aren’t 
coming, please remove it or indicate that you’d try to attend remotely. We’ll 
try to have webex or something via a laptop, which hopefully will be better 
than nothing.

The mid-cycle is intended to be a lot of pairing up sessions on priorities 
established at the summit [2]. However, if you have specific topics to discuss, 
just add them somewhere on the agenda list[0] so they are tracked and we can 
cover them. The times for sessions on the agenda likely won’t be followed too 
closely as small group break outs happen.

For Tuesday evening, if anybody is interested we might do a short hike in the 
nearby foothills before dinner. If so, bring some comfortable walking shoes.

And a reminder that location info is at link [2] below.


[0] Agenda / Attendance List: 
https://docs.google.com/spreadsheets/d/1w0eI6SPCA2IrOyHiEYC2uDO3fbYGzahZRUQSva0UD3Y/edit#gid=1788841692

[1] Liberty Priorities:
https://etherpad.openstack.org/p/YVR-horizon-liberty-priorities

[2] Info on location is here:
https://etherpad.openstack.org/p/horizon-liberty-midcycle


Thanks,
Travis




On 6/19/15, 10:14 AM, Tripp, Travis S travis.tr...@hp.com wrote:

Hi everybody,

I got confirmation for hosting the mid cycle meetup at the HP Office in Fort 
Collins on July 21st - 23rd.  I’ve put details on the location with a couple 
nearby hotels on the following ether pad.  The room we have reserved can hold 
about 40 people, but I’ve requested for it to be setup so that we can have a 
couple different work areas in the room. There will be a u-shape configuration 
at the front of the room for 20 and another u-shape at the back of the room 
for 10 to be used for breakout discussions.

https://etherpad.openstack.org/p/horizon-liberty-midcycle

A question I have is whether we’ll want to have lunch catered or if we’ll want 
to let everybody out for an hour to get lunch from one of the nearby 
restaurants.  There is a cafeteria on site as well.  If we decide to have it 
catered, I’ll have to know of any special dietary requests.

Thanks,
Travis

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

[openstack-dev] [neutron] Service Chain project IRC meeting agenda

[Cathy Zhang]

Hi everyone,
Below are some items we plan to discuss in the next IRC meeting. Please add 
more topics you would like to discuss if any.
Thanks,
Cathy
* Spec update for addressing new comments, and review
* SFC CLI client and Horizon Client dependency on base Neutron CLI and 
Horizon code
* OVS Driver and OVS support for classifier and SFF. If we decide to go 
for no SFC header with chain ID, then the OVS has to build a forwarding table 
based on 5-tuple or n-tuple for flow identification.
*  ?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] New Criteria for UX bugs

[Mike Scherbakov]

Sounds good to start, we can always adjust later if needed. I actually
changed one doc bug priority already using this criteria.

On Fri, Jul 10, 2015 at 5:42 AM Jay Pipes jaypi...@gmail.com wrote:

 On 07/09/2015 06:14 PM, Andrew Woodward wrote:
  We often have bugs which create really poor User eXperience (UX) but our
  current bug priority criteria prevent nearly all of them from being
  higher than medium (as they nearly always have workarounds). We need to
  identify what should qualify as a critical, or high UX defect so that
  they can receive appropriate attention.
 
  We discussed what this may look like on the IRC meeting, the general
  idea here is that the complexity of effort to work around the UX issue
  should be related to the priority.
 
  Critical: requires massive effort to work around, including [un|under]
  documented commands and edits to config files
 
  High: requires modification of config files, interfaces that users
  aren't expected to use (ie the API when it's _intended_ to work in the
  CLI / UI (exclusive of interfaces that are intended to only be available
  via API) or requires custom node yaml (again except when it should
  exclusively be available)
 
  Medium: Straight forward commands in the CLI

 Above criteria look excellent to me, thanks Andrew!
 -jay


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

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

Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure - second thoughts

[Fox, Kevin M]

Yeah. Sounds reasonable. I just wanted to raise the discussion since one might 
affect the implementation of the other. 

In fact, thinking through it more, having the validate template api be 
restricted to just what the specific instance of heat can do actually might 
help play a part in the solution to the other issue.

If you go look at the template in the app catalog ui in horizon, it could call 
out to heat template validate at that point and let you know if its supported 
or not by your specific cloud. If it validated for all clouds, that wouldn't be 
an option.

Though there is another issue the catalog will eventually hit where we would 
like to have a repo of contributed templates that we can do some automated 
tests to ensure they either work or at least validate. The --all flag would 
probably help with that case. In the test environment, we might not be able to 
test against some advanced services but could at least tell if it was a valid 
template.

Thanks,
Kevin

From: Randall Burt [randall.b...@rackspace.com]
Sent: Tuesday, July 14, 2015 3:58 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure 
- secondthoughts

A feedback mechanism for users is obviously a good thing, but IMO, not 
germane to the threads original purpose of how and when to expose supported 
resources in Heat. I cannot imagine us implementing such a feature directly.

This may be a good discussion to have in the context of app catalog exclusively 
and not in the context of Heat since we seem to be discussing a generally 
available catalog vs Heat running in a specific environment. These two issues 
are quite different in terms of what's supported.

In the Heat case, the documentation in OpenStack is good enough IMO for what 
are all the things Heat can possibly let me do while the chosen endpoint is 
the place to answer what are the things *this* installation of Heat will let 
me do. If the answer to the latter is unsatisfactory, then the user should 
already have mechanisms to encourage the operator to provide what's missing.

On Jul 14, 2015, at 5:31 PM, Fox, Kevin M kevin@pnnl.gov
 wrote:

 Without a feedback loop of some kind, how does one solve issues like the 
 following:

 * Operator decides users don't need neutron NaaS because its too complicated 
 and users don't need it (Seen on the mailing list multiple times)
 * Software developer writes cloud templates that deploys software that needs 
 private networks to work (For example, ElasticSearch)
 * User wants to deploy said software but can't discover a working version.

 User is sad because they can't find a working template to do what they want. 
 They either reinvent the wheel, or give up and don't use the cloud for that 
 task.

 Being able to close the loop and let the operator easily know the users 
 actually need something they aren't providing gives them the opportunity to 
 fix the issue, benefiting all 3 parties.

 Thanks,
 Kevin

 
 From: Randall Burt [randall.b...@rackspace.com]
 Sent: Tuesday, July 14, 2015 2:40 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Heat] [app-catalog] conditional resource 
 exposure - secondthoughts

 Making users complain to admins that may have little to no control over what 
 is and isn't available isn't a healthy strategy for user experience. 
 Purposefully engineering hardship to try and influence operators to do the 
 right thing in someone else's opinion sounds pretty counter productive to 
 adoption as well.

 FWIW, as a user, I don't want to see things I can't use because it just 
 wastes my time. I agree that the docs are a good place to see all the 
 things while querying the service should tell me what's available to me at 
 the time.

 On Jul 14, 2015, at 4:20 PM, Fox, Kevin M kevin@pnnl.gov
 wrote:

 We're kind of debating the same thing for the app catalog. Do we show 
 templates that don't work on a given cloud since they wont work, potentially 
 making useful tools hard to discover, or do we view it as an opportunity for 
 users to complain to their admins that they need X feature in order to do 
 what they need to do. Last time we talked about it, we were leaning towards 
 the latter.

 Maybe a happy middle ground is to have enough smarts in the system to show 
 the templates, identify what parts won't work, gray out the template but 
 provide a ui to notifify the admin of desire for X to work. That way users 
 can easily feed back their desires.

 Thanks,
 Kevin
 From: Pavlo Shchelokovskyy [pshchelokovs...@mirantis.com]
 Sent: Tuesday, July 14, 2015 11:34 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Heat] conditional resource exposure - second 
 thoughts

 Hi Heaters,
 currently we already expose to the user 

Re: [openstack-dev] [Congress] New IRC meeting time

[Zhou, Zhenzan]

Glad to see this change.
Thanks for the supporting for developers in Asia☺

BR
Zhou Zhenzan

From: Tim Hinrichs [mailto:t...@styra.com]
Sent: Wednesday, July 15, 2015 02:14
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Congress] New IRC meeting time

To better accommodate the active contributors, we're moving our IRC meeting to

2300 UTC = 4p Pacific = 7p Eastern
#openstack-meeting-3

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

[openstack-dev] [Nova] Virtual device role tagging

[Artom Lifshitz]

Hello,

I'd like to get the conversation started around a spec that my colleague Dan
Berrange has proposed to the backlog.

The spec [1] solves the problem of passing information about virtual devices
into an instance.

For example, in an instance with multiple network interfaces, each connected to
profoundly different networks, software running inside the instance needs to
know each NIC's role. Similarly, in an instance with multiple disks, each
intended for different a usage, software inside the instance needs to know each
disk's role.

I feel like a lot of discussion will happen around this spec before it can
be merged - hopefully in the M cycle - so I'm requesting comments and
suggestions very early ;)

Thanks all!

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

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

[openstack-dev] 答复: [Heat] conditional resource exposure - second thoughts

[Huangtianhua]

-邮件原件-
发件人: Zane Bitter [mailto:zbit...@redhat.com] 
发送时间: 2015年7月15日 3:35
收件人: openstack-dev@lists.openstack.org
主题: Re: [openstack-dev] [Heat] conditional resource exposure - second thoughts

On 14/07/15 14:34, Pavlo Shchelokovskyy wrote:
 Hi Heaters,

 currently we already expose to the user only resources for services 
 deployed in the cloud [1], and soon we will do the same based on 
 whether actual user roles allow creating specific resources [2]. Here 
 I would like to get your opinion on some of my thoughts regarding 
 behavior of resource-type-list, resource-type-show and 
 template-validate with this new features.

 resource-type-list
 We already (or soon will) hide unavailable in the cloud / for the user 
 resources from the listing. But what if we add an API flag e.g. --all 
 to show all registered in the engine resources? That would give any 
 user a glimpse of what their Orchestration service can manage in 
 principle, so they can nag the cloud operator to install additional 
 OpenStack components or give them required roles :)

I'd agree with Zane. Only allow admins to getting all resource types not 
ordinary users.

 resource-type-show
 Right now the plan is to disable showing unavailable to the user 
 resources. But may be we should leave this as it is, for the same 
 purpose as above (or again add a --all flag or such)?

I'd prefer to allow admins to show all resource type. The behavior should be 
consistent, ordinary users can only show the resource type which they can list. 

 template-validate
 Right now Heat is failing validation for templates containing resource 
 types not registered in the engine (e.g. typo). Should we also make 
 this call available services- and roles-sensitive? Or should we leave 
 a way for a user to check validity of any template with any in 
 principle supported resources?

I'd agree with Zane. And I think if we can give the detail reasons(service 
unavailable or resources type is not supported) why the validation is failed 
will be good to users.

cheers,
Zane.

 The bottom line is we are good in making Heat service to be as much 
 self-documented via its own API as possible - let's keep doing that 
 and make any Heat deployment to be the Heat primer :)

 Eager to hear your opinions.

 [1]
 http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditio
 nal-resource-exposure-services.html

 [2]
 http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditio
 nal-resource-exposure-roles.html

 Best regards,

 --
 Dr. Pavlo Shchelokovskyy
 Senior Software Engineer
 Mirantis Inc
 www.mirantis.com


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



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

[openstack-dev] [cinder] Vedams' DotHill, Lenovo and HP MSA CIs are Unstable

[Mike Perez]

These three CIs are unstable and the drivers are in danger of being removed
from the Liberty release since the maintainer has not communicated any
maintenance happening.

http://paste.openstack.org/show/375584/
http://paste.openstack.org/show/375585/
http://paste.openstack.org/show/375586/

I will be requesting the HP MSA CI to be disabled in the third party list,
since it has failed the last 60 runs in the last 5 days.

This is unacceptable and we need Vedams to be more on top of this.

-- 
Mike Perez

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

[openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

[Kai Qiang Wu]

Hi Magnum Guys,


I want to raise this question through ML.


In this patch https://review.openstack.org/#/c/200401/


For some old history reason, we use platform to indicate 'vm' or
'baremetal'.
This seems not proper for that, @Adrian proposed nova_instance_type, and
someone prefer other names, let me summarize as below:


1. nova_instance_type  2 votes

2. instance_type 2 votes

3. others (1 vote, but not proposed any name)


Let's try to reach the agreement ASAP. I think count the final votes winner
as the proper name is the best solution(considering community diversity).


BTW, If you not proposed any better name, just vote to disagree all, I
think that vote is not valid and not helpful to solve the issue.


Please help to vote for that name.


Thanks




Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193

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

Re: [openstack-dev] [testing] moving testrepository *outside* the tox venv

[Robert Collins]

On 13 July 2015 at 06:19, Mike Bayer mba...@redhat.com wrote:


 On 7/11/15 6:04 AM, Robert Collins wrote:

 Wearing my upstream hat, testr is *still* intended to be used differently
 than OpenStack is doing. Running all the tests for all python versions at
 once in parallel is the sort of thing testr is aimed at, and thats fairly
 fundamentally incompatible with running from inside a venv. As is
 distributed testing across multiple machines. I haven't had time to help
 OpenStack mature its use of testr until recently, and fixing these issues
 that are and will have seems pretty important to me.


 this is totally a peanut gallery comment, as I haven't carefully read this
 whole thread, but doesn't this mean that the use of testr *and* tox at the
 same time is fundamentally wrong?   Because tox's main purpose is to
 facilitate running tests in multiple environments (though not simultaneously
 / distributed).  If testr already does that, why are we using tox?  (other
 than the IMO fairly obvious, it's used ubiquitously, is popular, and
 everyone knows how to use it argument).

It's a totally reasonable question and the answer is that they are
complementary.
tox is Python specific.

testr is not.

testr doesn't want to learn about making sdists, for instance :).

So use tox to setup a given virtualenv, and testr to run the tests
within that. I think that testr wants to orchestrate that, eventually.

For now, all we need to do (AFAICT) is:

a - get testr installed on the infra images
b - update the developer docs to also instruct folk to install testr
c - stop using the (ugh, it was a mistake) setup.py glue that runs testr
d - remove testrepository from everyone's test-requirements.txt

step c) is likely to uncover one or more missing integration points in
testr, which we'll fix promptly.

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [magnum] Tom Cammann for core

[Tom Cammann]

Thanks team, happy to be here :)

Tom
 On 14 Jul 2015, at 23:02, Adrian Otto adrian.o...@rackspace.com wrote:
 
 Tom,
 
 It is my pleasure to welcome you to the magnum-core group. We are happy to 
 have you on the team.
 
 Regards,
 
 Adrian
 
 On Jul 9, 2015, at 7:20 PM, Adrian Otto adrian.o...@rackspace.com wrote:
 
 Team,
 
 Tom Cammann (tcammann) has become a valued Magnum contributor, and 
 consistent reviewer helping us to shape the direction and quality of our new 
 contributions. I nominate Tom to join the magnum-core team as our newest 
 core reviewer. Please respond with a +1 vote if you agree. Alternatively, 
 vote -1 to disagree, and include your rationale for consideration.
 
 Thanks,
 
 Adrian
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Fuel] Separate repo for Fuel Agent

[Mike Scherbakov]

Thanks Vladimir. Let's ensure to get it done sooner than later (this might
require to be tested in custom ISO..) - we are approaching FF, and I expect
growing queues of patches to land...

On Tue, Jul 14, 2015 at 6:03 AM Vladimir Kozhukalov 
vkozhuka...@mirantis.com wrote:

 Dear colleagues,

 New repository [1] has been created. So, please port all your review
 requests to stackforge/fuel-web related to Fuel Agent to this new
 repository. Currently, I am testing these two patches
 https://review.openstack.org/#/c/200595
 https://review.openstack.org/#/c/200025. If they work, we need to merge
 them and that is it. Review is welcome.



 [1] https://github.com/stackforge/fuel-agent.git

 Vladimir Kozhukalov

 On Fri, Jul 10, 2015 at 8:14 PM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Ok, guys.

 Looks like there are no any objections. At the moment I need to create
 actual version of upstream repository which is going to be sucked in by
 OpenStack Infra. Please, be informed that all patches changing
 fuel-web/fuel_agent that will be merged after this moment will need to be
 ported into the new fuel-agent repository.


 Vladimir Kozhukalov

 On Fri, Jul 10, 2015 at 6:38 PM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Guys, we are next to moving fuel_agent directory into a separate
 repository. Action flow is going to be as follows:

 1) Create verify jobs on our CI https://review.fuel-infra.org/#/c/9186
 (DONE)
 2) Freeze fuel_agent directory in https://github.com/stackforge/fuel-web
 (will announce in a separate mail thread). That means we stop merging
 patches into master which change fuel_agent directory. Unfortunately, all
 review requests need to be re-sent, but it is not going to be very
 difficult.
 3) Create temporary upstream repository with fuel_agent/* as a content.
 I'm not planning to move 5.x and 6.x branches. Only master. So, all fixes
 for 5.x and 6.x will be living in fuel-web.
 4) This upstream repository is going to be sucked in by openstack-infra.
 Patch is here https://review.openstack.org/#/c/199178/ (review is
 welcome) I don't know how long it is going to take. Will try to poke infra
 people to do this today.
 5) Then we need to accept two patches into new fuel-agent repository:
  - rpm spec (extraction from fuel-web/specs/nailgun.spec) (ready, but
 there is no review request)
  - run_tests.sh (to run tests) (ready, but there is no review request)

 !!! By this moment there won't be any impact on ISO build process !!!

 6) Then we need to change two things at the same time (review is welcome)
   - fuel-web/specs/nailgun.spec in order to prevent fuel-agent package
 building  https://review.openstack.org/#/c/200595
   - fuel-main so as to introduce new fuel-agent repository into the
 build process https://review.openstack.org/#/c/200025

 And good luck to me -)


 Vladimir Kozhukalov

 On Wed, Jul 8, 2015 at 12:53 PM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 There were some questions from Alexandra Fedorova about independent
 release cycle.

 according to the configuration [1] Infra team won't be able to do
 branching or any kind of release management for new repository.

 Could you please clarify, do we plan to version new repository the
 same way as we do for main fuel repositories or there going to be
 separate releases as in python-fuelclient [2]? Who should drive the
 release process for this repo and how this change will affect Fuel ISO
 release?

 [1]
 https://review.openstack.org/#/c/199178/1/gerrit/acls/stackforge/fuel-agent.config,cm
 [2]
 http://lists.openstack.org/pipermail/openstack-dev/2015-July/068837.html

 IMO all Fuel components should be as much independent as possible with
 highly defined APIs used for their interaction, with their own teams, with
 their own independent release cycles. But we cannot switch to this model
 immediately. For the start, we can just move those components into separate
 repositories, leaving the same access rights and core team as we have for
 fuel-web.

 When Fuel Agent is a separate repository we discuss team. It looks like
 a team leader is the best person to manage releases for a particular
 component. This thread is totally about separation stuff and how to do this
 not breaking anything.



 Vladimir Kozhukalov

 On Wed, Jul 8, 2015 at 12:24 PM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Dear colleagues,

 I am going to move Fuel Agent into a separate git repository. The
 thing is that we have quite a few review requests to fuel-web with changes
 for Fuel Agent. The new repository is going to look like this
 https://github.com/kozhukalov/fuel-agent i.e. there is no additional
 sub-directory fuel_agent. In fact, I don't think it is a big deal to 
 update
 all fuel agent related review requests.

 Work items:
 0) request to openstack-infra
 https://review.openstack.org/#/c/199178/1
 0.1) upstream for this request with commit history
 https://github.com/kozhukalov/fuel-agent
 1) 

Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure - second thoughts

[Fox, Kevin M]

Without a feedback loop of some kind, how does one solve issues like the 
following:

* Operator decides users don't need neutron NaaS because its too complicated 
and users don't need it (Seen on the mailing list multiple times)
* Software developer writes cloud templates that deploys software that needs 
private networks to work (For example, ElasticSearch)
* User wants to deploy said software but can't discover a working version.

User is sad because they can't find a working template to do what they want. 
They either reinvent the wheel, or give up and don't use the cloud for that 
task.

Being able to close the loop and let the operator easily know the users 
actually need something they aren't providing gives them the opportunity to fix 
the issue, benefiting all 3 parties.

Thanks,
Kevin


From: Randall Burt [randall.b...@rackspace.com]
Sent: Tuesday, July 14, 2015 2:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure 
- secondthoughts

Making users complain to admins that may have little to no control over what is 
and isn't available isn't a healthy strategy for user experience. Purposefully 
engineering hardship to try and influence operators to do the right thing in 
someone else's opinion sounds pretty counter productive to adoption as well.

FWIW, as a user, I don't want to see things I can't use because it just wastes 
my time. I agree that the docs are a good place to see all the things while 
querying the service should tell me what's available to me at the time.

On Jul 14, 2015, at 4:20 PM, Fox, Kevin M kevin@pnnl.gov
 wrote:

 We're kind of debating the same thing for the app catalog. Do we show 
 templates that don't work on a given cloud since they wont work, potentially 
 making useful tools hard to discover, or do we view it as an opportunity for 
 users to complain to their admins that they need X feature in order to do 
 what they need to do. Last time we talked about it, we were leaning towards 
 the latter.

 Maybe a happy middle ground is to have enough smarts in the system to show 
 the templates, identify what parts won't work, gray out the template but 
 provide a ui to notifify the admin of desire for X to work. That way users 
 can easily feed back their desires.

 Thanks,
 Kevin
 From: Pavlo Shchelokovskyy [pshchelokovs...@mirantis.com]
 Sent: Tuesday, July 14, 2015 11:34 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Heat] conditional resource exposure - second 
 thoughts

 Hi Heaters,
 currently we already expose to the user only resources for services deployed 
 in the cloud [1], and soon we will do the same based on whether actual user 
 roles allow creating specific resources [2]. Here I would like to get your 
 opinion on some of my thoughts regarding behavior of resource-type-list, 
 resource-type-show and template-validate with this new features.
 resource-type-list
 We already (or soon will) hide unavailable in the cloud / for the user 
 resources from the listing. But what if we add an API flag e.g. --all to show 
 all registered in the engine resources? That would give any user a glimpse of 
 what their Orchestration service can manage in principle, so they can nag the 
 cloud operator to install additional OpenStack components or give them 
 required roles :)
 resource-type-show
 Right now the plan is to disable showing unavailable to the user resources. 
 But may be we should leave this as it is, for the same purpose as above (or 
 again add a --all flag or such)?
 template-validate
 Right now Heat is failing validation for templates containing resource types 
 not registered in the engine (e.g. typo). Should we also make this call 
 available services- and roles-sensitive? Or should we leave a way for a user 
 to check validity of any template with any in principle supported resources?
 The bottom line is we are good in making Heat service to be as much 
 self-documented via its own API as possible - let's keep doing that and make 
 any Heat deployment to be the Heat primer :)
 Eager to hear your opinions.
 [1] 
 http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-services.html
 [2] 
 http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-roles.html
 Best regards,
 --
 Dr. Pavlo Shchelokovskyy
 Senior Software Engineer
 Mirantis Inc
 www.mirantis.com
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure - second thoughts

[Randall Burt]

A feedback mechanism for users is obviously a good thing, but IMO, not 
germane to the threads original purpose of how and when to expose supported 
resources in Heat. I cannot imagine us implementing such a feature directly.

This may be a good discussion to have in the context of app catalog exclusively 
and not in the context of Heat since we seem to be discussing a generally 
available catalog vs Heat running in a specific environment. These two issues 
are quite different in terms of what's supported. 

In the Heat case, the documentation in OpenStack is good enough IMO for what 
are all the things Heat can possibly let me do while the chosen endpoint is 
the place to answer what are the things *this* installation of Heat will let 
me do. If the answer to the latter is unsatisfactory, then the user should 
already have mechanisms to encourage the operator to provide what's missing.

On Jul 14, 2015, at 5:31 PM, Fox, Kevin M kevin@pnnl.gov
 wrote:

 Without a feedback loop of some kind, how does one solve issues like the 
 following:
 
 * Operator decides users don't need neutron NaaS because its too complicated 
 and users don't need it (Seen on the mailing list multiple times)
 * Software developer writes cloud templates that deploys software that needs 
 private networks to work (For example, ElasticSearch)
 * User wants to deploy said software but can't discover a working version.
 
 User is sad because they can't find a working template to do what they want. 
 They either reinvent the wheel, or give up and don't use the cloud for that 
 task.
 
 Being able to close the loop and let the operator easily know the users 
 actually need something they aren't providing gives them the opportunity to 
 fix the issue, benefiting all 3 parties.
 
 Thanks,
 Kevin
 
 
 From: Randall Burt [randall.b...@rackspace.com]
 Sent: Tuesday, July 14, 2015 2:40 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Heat] [app-catalog] conditional resource 
 exposure - secondthoughts
 
 Making users complain to admins that may have little to no control over what 
 is and isn't available isn't a healthy strategy for user experience. 
 Purposefully engineering hardship to try and influence operators to do the 
 right thing in someone else's opinion sounds pretty counter productive to 
 adoption as well.
 
 FWIW, as a user, I don't want to see things I can't use because it just 
 wastes my time. I agree that the docs are a good place to see all the 
 things while querying the service should tell me what's available to me at 
 the time.
 
 On Jul 14, 2015, at 4:20 PM, Fox, Kevin M kevin@pnnl.gov
 wrote:
 
 We're kind of debating the same thing for the app catalog. Do we show 
 templates that don't work on a given cloud since they wont work, potentially 
 making useful tools hard to discover, or do we view it as an opportunity for 
 users to complain to their admins that they need X feature in order to do 
 what they need to do. Last time we talked about it, we were leaning towards 
 the latter.
 
 Maybe a happy middle ground is to have enough smarts in the system to show 
 the templates, identify what parts won't work, gray out the template but 
 provide a ui to notifify the admin of desire for X to work. That way users 
 can easily feed back their desires.
 
 Thanks,
 Kevin
 From: Pavlo Shchelokovskyy [pshchelokovs...@mirantis.com]
 Sent: Tuesday, July 14, 2015 11:34 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Heat] conditional resource exposure - second 
 thoughts
 
 Hi Heaters,
 currently we already expose to the user only resources for services deployed 
 in the cloud [1], and soon we will do the same based on whether actual user 
 roles allow creating specific resources [2]. Here I would like to get your 
 opinion on some of my thoughts regarding behavior of resource-type-list, 
 resource-type-show and template-validate with this new features.
 resource-type-list
 We already (or soon will) hide unavailable in the cloud / for the user 
 resources from the listing. But what if we add an API flag e.g. --all to 
 show all registered in the engine resources? That would give any user a 
 glimpse of what their Orchestration service can manage in principle, so they 
 can nag the cloud operator to install additional OpenStack components or 
 give them required roles :)
 resource-type-show
 Right now the plan is to disable showing unavailable to the user 
 resources. But may be we should leave this as it is, for the same purpose as 
 above (or again add a --all flag or such)?
 template-validate
 Right now Heat is failing validation for templates containing resource types 
 not registered in the engine (e.g. typo). Should we also make this call 
 available services- and roles-sensitive? Or should we leave a way for a user 
 to check validity of any template with any in principle 

Re: [openstack-dev] [Fuel] Being spammed by bugs when assigned to whole fuel team

[Mike Scherbakov]

Thank you. I think I resolved this with new filter matching exact You
received this bug notification because you are a member of. If I'm
subscribed directly to the bug, there is another message is used by LP like
You received this bug notification because you are subscribed to the bug
report.
*https://bugs https://bugs.*launchpad*.net/bugs/1474120*


On Tue, Jul 7, 2015 at 1:56 PM Aleksandra Fedorova afedor...@mirantis.com
wrote:

 Hi, Mike,

 let me post a quote from #launchpad IRC chat:

bookwar: hi all, is there any permission setting which forbids
 subscribing someone to the bug? As i see it, one can easily spam a
 group by subscribing it to a certain bug. How we can prevent this?
mgz: ban the person doing the spamming?
mgz: launchpad assumes its users are generally sane, but has
 recourse if that turns out to not be the case

 This quote is about 1.5 year old, but i guess the idea is still the same.


 As a possible workaround it should be possible to set main filters to
 filter out less common mail headers, for example:

X-Launchpad-Message-Rationale: Assignee @fuel-dev

 See [1] for details.

 [1] https://help.launchpad.net/Bugs/Subscriptions

 On Tue, Jul 7, 2015 at 11:27 PM, Mike Scherbakov
 mscherba...@mirantis.com wrote:
  Hi folks,
  DevOps guys - when someone assigns bug to Fuel for OpenStack, message
 is
  being sent to 120 people.
 
  Is there a way to restrict such assignment in Launchpad? I want to only
  allow fuel-python, and other subteams available. Or do something with LP
  groups.
 
  The problem is that I'm getting tired of many (not relevant to me) bugs
  flowing in my inbox, and stop paying attention. I'll have to create
 filter.
  And if someone needs my attention in particular bug, subscribes me to it
 -
  I'll miss it, as it will be filtered by the same way.
 
  Thank you,
  --
  Mike Scherbakov
  #mihgen
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 



 --
 Aleksandra Fedorova
 Fuel Devops Engineer
 bookwar

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

Re: [openstack-dev] [Congress] New IRC meeting time

[Masahito MUROI]

I'm happy to see that.

btw, is the day on Tuesday?

best regard,
masa

On 2015/07/15 9:52, Zhou, Zhenzan wrote:

Glad to see this change.
Thanks for the supporting for developers in Asia☺

BR
Zhou Zhenzan

From: Tim Hinrichs [mailto:t...@styra.com]
Sent: Wednesday, July 15, 2015 02:14
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Congress] New IRC meeting time

To better accommodate the active contributors, we're moving our IRC meeting to

2300 UTC = 4p Pacific = 7p Eastern
#openstack-meeting-3

Hope to see you there!
Tim



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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539，FAX: +81-422-59-2699


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

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

[Hongbin Lu]

I am going to propose a third option:

3. virt_type

I have concerns about option 1 and 2, because “instance_type” and flavor was 
used interchangeably before [1]. If we use “instance_type” to indicate “vm” or 
“baremetal”, it may cause confusions.

[1] https://blueprints.launchpad.net/nova/+spec/flavor-instance-type-dedup

Best regards,
Hongbin

From: Kai Qiang Wu [mailto:wk...@cn.ibm.com]
Sent: July-14-15 9:35 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [magnum] Magnum template manage use platform VS others 
as a type?


Hi Magnum Guys,


I want to raise this question through ML.


In this patch https://review.openstack.org/#/c/200401/


For some old history reason, we use platform to indicate 'vm' or 'baremetal'.
This seems not proper for that, @Adrian proposed nova_instance_type, and 
someone prefer other names, let me summarize as below:


1. nova_instance_type  2 votes

2. instance_type 2 votes

3. others (1 vote, but not proposed any name)


Let's try to reach the agreement ASAP. I think count the final votes winner as 
the proper name is the best solution(considering community diversity).


BTW, If you not proposed any better name, just vote to disagree all, I think 
that vote is not valid and not helpful to solve the issue.


Please help to vote for that name.


Thanks




Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.commailto:wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193

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

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

[Adrian Otto]

One drawback to virt_type if not seen in the context of the acceptable values, 
is that it should be set to values like libvirt, xen, ironic, etc. That might 
actually be good. Instead of using the values 'vm' or 'baremetal', we use the 
name of the nova virt driver, and interpret those to be vm or baremetal types. 
So if I set the value to 'xen', I know the nova instance type is a vm, and 
'ironic' means a baremetal nova instance.

Adrian


 Original message 
From: Hongbin Lu hongbin...@huawei.com
Date: 07/14/2015 7:20 PM (GMT-08:00)
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform VS 
others as a type?

I am going to propose a third option:

3. virt_type

I have concerns about option 1 and 2, because “instance_type” and flavor was 
used interchangeably before [1]. If we use “instance_type” to indicate “vm” or 
“baremetal”, it may cause confusions.

[1] https://blueprints.launchpad.net/nova/+spec/flavor-instance-type-dedup

Best regards,
Hongbin

From: Kai Qiang Wu [mailto:wk...@cn.ibm.com]
Sent: July-14-15 9:35 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [magnum] Magnum template manage use platform VS others 
as a type?


Hi Magnum Guys,


I want to raise this question through ML.


In this patch https://review.openstack.org/#/c/200401/


For some old history reason, we use platform to indicate 'vm' or 'baremetal'.
This seems not proper for that, @Adrian proposed nova_instance_type, and 
someone prefer other names, let me summarize as below:


1. nova_instance_type  2 votes

2. instance_type 2 votes

3. others (1 vote, but not proposed any name)


Let's try to reach the agreement ASAP. I think count the final votes winner as 
the proper name is the best solution(considering community diversity).


BTW, If you not proposed any better name, just vote to disagree all, I think 
that vote is not valid and not helpful to solve the issue.


Please help to vote for that name.


Thanks




Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.commailto:wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193

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

Re: [openstack-dev] [Heat] conditional resource exposure - second thoughts

[Manickam, Kanagaraj]

Like to share my opinions as below:

Resource-type-list/resource-type-show:
Once the role based resource exposure is enabled, based on the user's 
role, I believe, (s)he would expect to see those deployed resource-types, which 
are authorized. And wanted to know if that resource-type is available currently 
on that cloud. So by default, it will essentially filter out those 
un-authorized resource-types from the users, but it will provide the additional 
information, whether resource-type is currently available or not. (admin has 
access to all resource-types). And resource-type-list could be enhanced further 
with additional filtering flag like :

'---show-authorized': default behavior
'--show-unavailable': list those authorized un-available resource-types
 '--show-available': list those authorized available resource-types
'--show-unauthorized': This may be wrong one, I too believe. But like to get 
others opinion on it. It list all the deployed resource-types, which are 
un-authorized. It  becomes like live resource-type documents from running heat 
service. (other place user may want to know the same details from the public 
resource-type document available in the internet) . But here, operators may 
want to disable to report the un-authorized resource-types to those user, who 
does not have right roles. So we could provide config parameter for the same. 
I'm not sure on it though !

Template-validate:
As it really helps user to validate the template, before starting the 
stack creation, it would be better to validate complete template and report all 
the errors in the template, which includes the unavailability of the service in 
the service catalog, authorization check as well. Currently, template-validate 
exit on the occurrence of first error in the template. (I'm working on it)

Regards
Kanagaraj M


-Original Message-
From: Zane Bitter [mailto:zbit...@redhat.com] 
Sent: Wednesday, July 15, 2015 1:05 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Heat] conditional resource exposure - second 
thoughts

On 14/07/15 14:34, Pavlo Shchelokovskyy wrote:
 Hi Heaters,

 currently we already expose to the user only resources for services 
 deployed in the cloud [1], and soon we will do the same based on 
 whether actual user roles allow creating specific resources [2]. Here 
 I would like to get your opinion on some of my thoughts regarding 
 behavior of resource-type-list, resource-type-show and 
 template-validate with this new features.

 resource-type-list
 We already (or soon will) hide unavailable in the cloud / for the user 
 resources from the listing. But what if we add an API flag e.g. --all 
 to show all registered in the engine resources? That would give any 
 user a glimpse of what their Orchestration service can manage in 
 principle, so they can nag the cloud operator to install additional 
 OpenStack components or give them required roles :)

I worry that this could result in leakage of potentially-sensitive information. 
e.g. once we have this feature implemented, an operator could deploy a plugin 
that is only for the use of one particular user, who has a custom role. I don't 
think it would be expected that other users (without that role) in other 
tenants could find out about that, even if all they can find out is the name of 
the resource type.

I definitely think that admins should have a way of getting a list of _all_ 
resource types (preferably annotated with the roles required to use them). Just 
not ordinary users.

 resource-type-show
 Right now the plan is to disable showing unavailable to the user 
 resources. But may be we should leave this as it is, for the same 
 purpose as above (or again add a --all flag or such)?

This is totally unnecessary IMHO for the reasons Clint mentioned. Again, I 
could imagine an exception for admins though, since I suspect that this API is 
the only way we can annotate resource types with the roles required without 
performing major surgery on resource-type-list.

 template-validate
 Right now Heat is failing validation for templates containing resource 
 types not registered in the engine (e.g. typo). Should we also make 
 this call available services- and roles-sensitive? Or should we leave 
 a way for a user to check validity of any template with any in 
 principle supported resources?

You call template-validate when you're about to launch the template and you 
want to know what parameters and stuff are required. If YOU cannot launch THIS 
template on THIS cloud right NOW it should fail, period.

cheers,
Zane.

 The bottom line is we are good in making Heat service to be as much 
 self-documented via its own API as possible - let's keep doing that 
 and make any Heat deployment to be the Heat primer :)

 Eager to hear your opinions.

 [1]
 http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditio
 nal-resource-exposure-services.html

 [2]
 

Re: [openstack-dev] [magnum] The way magnum-conductor communicates with k8s master

[Steven Dake (stdake)]

From: Adrian Otto adrian.o...@rackspace.commailto:adrian.o...@rackspace.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, July 14, 2015 at 11:11 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [magnum] The way magnum-conductor communicates 
with k8s master


On Jul 13, 2015, at 8:40 PM, Steven Dake (stdake) 
std...@cisco.commailto:std...@cisco.com wrote:



From: OTSUKA, Motohiro yuany...@oeilvert.orgmailto:yuany...@oeilvert.org
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, July 13, 2015 at 8:11 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [magnum] The way magnum-conductor communicates 
with k8s master

Hi, Wanghua

  Currently magnum-conductor can communicates with k8s master which has a 
floating ip in all-in-one deployment. But if magnum-conductor is not deployed 
on the neutron network node which has the br-ex, how can magnum-conductor 
communicate with k8s master. The magnum-conductor node then has no access to 
the k8s master.
Currently this is a limitation of our architecture.


The floating IP is a public routed network, so it should be able to communicate 
in a properly setup cloud.

  Another question:
  Magnum-conductor only communicate with k8s master, why k8s minion has a 
floating ip too? What is the floating ip of k8s minion used for?

I think, there is no reason.
Historically, Our heat template come from larsks/heat-kubernetes [1] template.
larsks/heat-kubernetes provides floating ip to minion nodes, this is just a 
reason.

The minion floating ips are needed to access the micro-service front ends from 
the internet.

To be clear, the actual requirement is that the minion nodes must be able to 
make TCP connections to the master node. Depending on the routing setup on your 
nodes, and the arrangement of your network, that could be possible without a 
floating ip on the minion nodes. With that in mind, having a publicly routable 
address (floating ip) on your minion node is one way to produce such 
connectivity.

I’m sure we would be open to a proposal that eliminates our requirement for the 
floating ip on the minion nodes that would work properly in various network 
environments.

The minions need to be publically routed, but the master does not.  The reason 
minions need to be publically routed is because front end applications (such as 
chrome) access the microservices running in the k8s cluster via their 
publically routed ip address.

Regards
-steve


Adrian


Regards
-steve



[1]: https://github.com/larsks/heat-kubernetes

Thanks
-Yuanying

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

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

Re: [openstack-dev] [Heat] conditional resource exposure - second thoughts

[Clint Byrum]

Excerpts from Pavlo Shchelokovskyy's message of 2015-07-14 11:34:37 -0700:
 Hi Heaters,
 
 currently we already expose to the user only resources for services
 deployed in the cloud [1], and soon we will do the same based on whether
 actual user roles allow creating specific resources [2]. Here I would like
 to get your opinion on some of my thoughts regarding behavior of
 resource-type-list, resource-type-show and template-validate with this new
 features.
 
 resource-type-list
 We already (or soon will) hide unavailable in the cloud / for the user
 resources from the listing. But what if we add an API flag e.g. --all to
 show all registered in the engine resources? That would give any user a
 glimpse of what their Orchestration service can manage in principle, so
 they can nag the cloud operator to install additional OpenStack components
 or give them required roles :)
 

There are more variables that lead to a resource being hidden than
the catalog. The version of Heat, whether the plugin is available,
libraries installed on the server, etc. The canonical place for all
things possible, and the place that users should be encouraged to use,
is the documentation of Heat. These API's should only be for inspection
of what is available on the Heat service one is talking to.

 
 template-validate
 Right now Heat is failing validation for templates containing resource
 types not registered in the engine (e.g. typo). Should we also make this
 call available services- and roles-sensitive? Or should we leave a way for
 a user to check validity of any template with any in principle supported
 resources?
 

I believe the current behavior is correct. The idea is to be able to
edit a template, and then validate it on all the clouds you want to push
it to.

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

[openstack-dev] OpenStack Mitaka (三鷹) - Our next release name has been selected

[Monty Taylor]

Hi everybody!

Ok. There is nothing more actually useful I can say that isn't in the
subject line. As I mentioned previously, the preliminary results from
our name election are here:

http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4983776e190c8dbc

As you are all probably aware by now, as a follow on step, the OpenStack
Foundation staff assessed the names chosen for legal risk in the order
we ranked them. The first two had significant identified problems so we
skipped them. The third had no legal problems, but after announcing it
as the choice, it came to light that there were significant social
issues surrounding the name.

The fourth on the list, Mitaka (三鷹) is clear.

So please join me in welcoming the latest name to our family ... and if
you, like me, are not a native Japanese speaker, in learning two (more)
new characters.

I'd also like to thank everyone in our community for understanding. As
we try our best to be an inclusive worldwide community, the
opportunities for unwitting missteps are vast and ultimately probably
unavoidable. Being able to recognize and deal with them and learn from
them as they occur makes me proud of who we are and what we've become.

Thanks!
Monty

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

Re: [openstack-dev] OpenStack Mitaka (三鷹) - Our next release name has been selected

[Ian Cordasco]

On 7/14/15, 13:47, Monty Taylor mord...@inaugust.com wrote:

Hi everybody!

Ok. There is nothing more actually useful I can say that isn't in the
subject line. As I mentioned previously, the preliminary results from
our name election are here:

http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4983776e190c8dbc

As you are all probably aware by now, as a follow on step, the OpenStack
Foundation staff assessed the names chosen for legal risk in the order
we ranked them. The first two had significant identified problems so we
skipped them. The third had no legal problems, but after announcing it
as the choice, it came to light that there were significant social
issues surrounding the name.

The fourth on the list, Mitaka (三鷹) is clear.

So please join me in welcoming the latest name to our family ... and if
you, like me, are not a native Japanese speaker, in learning two (more)
new characters.

I'd also like to thank everyone in our community for understanding. As
we try our best to be an inclusive worldwide community, the
opportunities for unwitting missteps are vast and ultimately probably
unavoidable. Being able to recognize and deal with them and learn from
them as they occur makes me proud of who we are and what we've become.

I agree. It's really encouraging to see a community as large as OpenStack
embrace inclusivity and empathy around social issues.

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