[openstack-dev] [all] Announcing Project: Senlin - Clustering/Collection Service for OpenStack

[Qiming Teng]

Hello, Stackers,

I'm pleased to share with you the progress we have made on the Senlin
project, which aims to be a flexible clustering/collection service for
OpenStack clouds. The project is now hosted on stackforge, with its
server code base[1] and a CLI client tool [2].


What Is Senlin
--

Senlin was designed to be a generic clustering/collection service to
manage collections of homogeneous objects exposed from other OpenStack
services. It was deeply rooted from Heat, which has already provided
certain level of support to the notions of resource groups and even
resource groups that can be auto-scaled. One of Senlin's design goals
is to complement Heat's orchestration service by offloading the auto-
scaling functionality from Heat so that Heat can be more focused on
orchestration itself while diverting feature requests/improvements to a
dedicated 'ASS-NG' (Auto-Scaling-Service Next-Generation), :)

Although the initial intent of Senlin was merely about an auto-scaling
service, we soon realized that what is really needed is about the
management of collections of homogenous objects. The auto-scaling, load-
balancing, placement, removal and even health checking are all policies
that users may and may not want to attach to such collections. These
policies would be customized for different cloud applications running on
an OpenStack cloud. Users may want their own policy implementations
easily incorporated and effected.

Further more, users may want to manage many groups of cloud objects, i.e.
build pools of such objects and manage them collectively. For example,
in the case of auto-scaling, it would be convenient to have a 'standby'
group to back a 'working' group so that when requests surge, objects can
be migrated from the 'standby' group to the 'working' group
instantenously.

Simply put, Senlin aims to provide an 'array' data type for programming
your OpenStack cloud. 





Senlin Concepts
---

There are some core concepts in Senlin's design which are created to
facilitate a flexible clustering service.

* Cluster
  A collection (group) of homogeneous objects (aka. Nodes).

* Node
  An object that can be a member of at most one cluster at any time.
  There can be 'orphan' nodes. Nodes are created by instantiating
  profiles.

* Profile
  A specification about the real resource to be managed. Senlin use this
  concept to make clusters agnostic to the varying nature of resources
  managed. A profile can be a Heat stack, a Nova server, a floating-IP
  and so on.

* Action
  Operations that can be performed on a cluster, a node, a profile or
  a policy. Actions are mostly executed in asynchronous manner. Senlin
  provides builtin actions, but there are possibilities to expose
  actions to users as customizable scripts that could be SSH executed
  on VM-style nodes.

* Policy
  A collection of rules to be enforced before and/or after an action is
  performed.

* Event
  Event records capture interesting activities happened as results of
  engine operations, policy checkings/violations etc. Senlin hopes that
  the event history will save users from digging into log files.

Note that although we only have one profile and a few policies in current
code base, we designed Senlin to be extendable in terms of profiles and
policies. We don't want the core 'cluster' and 'node' concept hijacked
by any particular profile and/or policy.


Current Status
--

After more than three months' work, Senlin is now taking shape -- surely 
not an ideal shape yet depending on the angle from which you are judging
it. With some basic functionalities in place, it is ready for a try-out.


How to Try It
-

Step 0: Clone and install the server and the client as you do with other
OpenStack services.

Step 1: Write a profile spec. Some examples are provided in the code
base. The only supported profile type is 'os.heat.stack' at present.

Step 2: Create a profile

  # senlin profile-create -t os.heat.stack -s mystack.spec myprofile

Step 3: Create a node or a cluster using the profile

  # senlin cluster-create -p myprofile -n 3 my-cluster

  # senlin node-create -p myprofile my-node

  # senlin node-create -p myprofile -c my-cluster another-node

Step 4+: Play with the profile, the cluster, the node

  # senlin profile-list
  # senlin profile-show myprofile |  | 

  # senlin cluster-list
  # senlin cluster-show my-cluster |  | 

  # senlin node-list
  # senlin node-show my-node |  | 
  # senlin node-join -c my-cluster my-node
  # senlin node-leave my-node

  # senlin cluster-scale-out -n 1 my-cluster
  # senlin cluster-scale-in -n 1 my-cluster

  # senlin cluster-nodes-add -n my-node my-cluster
  # senlin cluster-nodes-del -n my-node my-cluster

Step n: create a policy and attach it to a cluster

  # senlin policy-create -t ScalingPolicy -s scale-policy sp01

  # senlin policy-list
  # senlin policy-show sp01 |  | 

  # senlin cluster-policy-attach -p sp01 my-cluster

  # senlin cluster-poli

[openstack-dev] [Neutron] [ML2] using binding:tun_ip instead of agent_ip for l2pop to support agentless backend

[henry hly]

Hi ML2er,

Today we use agent_ip in L2pop to store endpoints for ports on a
tunnel type network, such as vxlan or gre. However this has some
drawbacks:

1) It can only work with backends with agents;
2) Only one fixed ip is supported per-each agent;
3) Difficult to interact with other backend and world outside of Openstack.

L2pop is already widely accepted and deployed in host based overlay,
however because it use agent_ip to populate tunnel endpoint, it's very
hard to co-exist and inter-operating with other vxlan backend,
especially agentless MD.

A small change is suggested that the tunnel endpoint should not be the
attribute of *agent*, but be the attribute of *port*, so if we store
it in something like *binding:tun_ip*, it is much easier for different
backend to co-exists. Existing ovs agent and bridge need a small
patch, to put the local agent_ip into the port context binding fields
when doing port_up rpc.

Several extra benefits may also be obtained by this way:

1) we can easily and naturally create *external vxlan/gre port* which
is not attached by an Nova booted VM, with the binding:tun_ip set when
creating;
2) we can develop some *proxy agent* which manage a bunch of remote
external backend, without restriction of its agent_ip.

Best Regards,
Henry

__
OpenStack Development Mailing 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] [glance] image-create failed vcender backend

[Sabari Murugesan]

Hi Sergiy

I have commented on the bug, please take a look.

Thanks
Sabari

On Wed, Mar 25, 2015 at 1:58 PM, Sergiy Lystopad 
wrote:

> Hi,colleagues.
>
> I've faced with an issue https://bugs.launchpad.net/glance/+bug/1436034
> during mos 6.0 with vcenter deployment for customer.
>
> could you help me  do debug and fix issue.
>
> Thanks
>
> --
> Sergiy Lystopad
>
> __
> OpenStack Development Mailing 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] a question regarding the current status of image "community" visibility support

[Su Zhang]

I figured out that after I cherry picked the code at
https://review.openstack.org/#/c/136374/, I will encounter a 500 error
while using glance api 2.0.
Could anyone possibly let me know how to get this error around?
Here is my log:

2015-03-25 22:04:54.088 WARNING oslo_config.cfg
[req-d197339f-dd73-4ad4-88b4-3194d0e23570 8e50cb1c63294e528502abcbdeed8b50
87ab685d55af4882b9af51e3d28

6ab0b] Option "sql_connection" from group "DEFAULT" is deprecated. Use
option "connection" from group "database".

2015-03-25 22:04:54.104 DEBUG oslo_db.sqlalchemy.session
[req-d197339f-dd73-4ad4-88b4-3194d0e23570 8e50cb1c63294e528502abcbdeed8b50
87ab685d55af4882b9

af51e3d286ab0b] MySQL server mode set to
STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_

AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION from (pid=63674)
_check_effective_sql_mode
/usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/session.p

y:513

2015-03-25 22:04:54.156 INFO eventlet.wsgi.server
[req-d197339f-dd73-4ad4-88b4-3194d0e23570 8e50cb1c63294e528502abcbdeed8b50
87ab685d55af4882b9af51e3d

286ab0b] Traceback (most recent call last):

  File "/usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py", line 427,
in handle_one_response

result = self.application(self.environ, start_response)

  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in
__call__

resp = self.call_func(req, *args, **self.kwargs)

  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in
call_func

return self.func(req, *args, **kwargs)

  File "/opt/stack/glance/glance/common/wsgi.py", line 486, in __call__

response = req.get_response(self.application)

  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line
1320, in send

application, catch_exc_info=False)

  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line
1284, in call_application

app_iter = application(self.environ, start_response)

  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in
__call__

resp = self.call_func(req, *args, **self.kwargs)

  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in
call_func

return self.func(req, *args, **kwargs)

  File "/usr/local/lib/python2.7/dist-packages/osprofiler/web.py", line 99,
in __call__

return request.get_response(self.application)

  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line
1320, in send

application, catch_exc_info=False)

  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line
1284, in call_application

app_iter = application(self.environ, start_response)

  File
"/usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py",
line 634, in __call__

return self._call_app(env, start_response)

  File
"/usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py",
line 554, in _call_app

return self._app(env, _fake_start_response)

  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in
__call__

resp = self.call_func(req, *args, **self.kwargs)

  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in
call_func

return self.func(req, *args, **kwargs)

 File "/opt/stack/glance/glance/common/wsgi.py", line 486, in __call__

response = req.get_response(self.application)

  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line
1320, in send

application, catch_exc_info=False)

  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line
1284, in call_application

app_iter = application(self.environ, start_response)

  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in
__call__

resp = self.call_func(req, *args, **self.kwargs)

  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in
call_func

return self.func(req, *args, **kwargs)

  File "/opt/stack/glance/glance/common/wsgi.py", line 486, in __call__

response = req.get_response(self.application)

  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line
1320, in send

application, catch_exc_info=False)

  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line
1284, in call_application

app_iter = application(self.environ, start_response)

  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in
__call__

resp = self.call_func(req, *args, **self.kwargs)

  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in
call_func

return self.func(req, *args, **kwargs)

  File "/opt/stack/glance/glance/common/wsgi.py", line 486, in __call__

response = req.get_response(self.application)

  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line
1320, in send

application, catch_exc_info=False)

  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line
1284, in call_application

app_iter = appli

[openstack-dev] [swift] swift memory usage in centos7 devstack jobs

[Ian Wienand]

Hi,

We've been having an issue with Centos 7 jobs and the host running
out of memory.  After some investigation; one likely angle seems to be
the memory usage by swift.

See [1] for some more details; but the short story is that the various
swift processes -- even just sitting around freshly installed from
devstack before anything happens -- take up twice as much space on
centos as ubuntu

--- swift (% total system memory) ---
ubuntu  6.6%
centos  12%

In general memory usage is higher on centos, but this one is an
outlier.  Unfortunately, the main difference between the two appears
to be heap allocations (see comments in [1]) which doesn't give a lot
of clues.

The end result is that the host ends up just plain running out of
memory; the OOM killer kicks in and then everything starts
collapsing. I had the host sending me telemetry while it was running;
the last entry before things fell over was [2] and we can see that
it's not just one thing that comes along and sucks up memory, but
death by a thousand cuts.  I think the Centos 7 job is struggling to
fit into the 8gb available so we're susceptible to finding memory
issues first.

Any swift people have some ideas on this?

Thanks

-i

[1] https://etherpad.openstack.org/p/oom-in-rax-centos7-CI-job
[2] http://paste.openstack.org/show/196769/

__
OpenStack Development Mailing 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] [libvirt] The risk of hanging when shutdown instance.

[Rui Chen]

Hi all:

I found a discuss about the libvirt shutdown API maybe hang when
shutdown instance in libvirt community,
https://www.redhat.com/archives/libvir-list/2015-March/msg01121.html

I'm not sure that whether there are some risks when we shutdown
instance in nova.

Three questions:
1. Whether acpi is the default shutdown mode in QEMU/KVM hypervisor
when we shutdown instance using libvirt?
2. Whether acpi is asynchronous mode, and qemu-agent is synchronous
mode when we shutdown instance?
3. If the hypervisor use qemu-agent as default shutdown mode, how we
can deal the hanging issue?

Best Regards.
__
OpenStack Development Mailing 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] request for SFE

[Itsuro ODA]

Neutron cores,

I request SFE for the fix:
https://review.openstack.org/147032/
https://bugs.launchpad.net/neutron/+bug/1408488

I believe there is consensus that this change is valuable
through the discussion on the thread [1].

This change adds a configuration option to keep backward
compatibility. (note that the opinion for the implementation
was divided among reviewers. it is latest conclusion.)

A string for translation is a help text of the configuration
option.

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-March/059714.html

PS.
I am not familiar with SFE procedure. 
Should I raise this to openstack-i18n mailing-list ?

Thanks.
-- 
Itsuro ODA 


__
OpenStack Development Mailing 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] Nominate Irina Povolotskaya for fuel-docs core

[Sergii Golovatiuk]

+1



Best Regards,
Sergii Golovatiuk

> On 25 Mar 2015, at 12:10, Dmitry Borodaenko  wrote:
> 
> Fuelers,
> 
> I'd like to nominate Irina Povolotskaya for the fuel-docs-core team.
> She has contributed thousands of lines of documentation to Fuel over
> the past several months, and has been a diligent reviewer:
> 
> http://stackalytics.com/?user_id=ipovolotskaya&release=all&project_type=all&module=fuel-docs
> 
> I believe it's time to grant her core reviewer rights in the fuel-docs
> repository.
> 
> Core reviewer approval process definition:
> https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> 
> -- 
> Dmitry Borodaenko
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

[Ken'ichi Ohmichi]

2015-03-24 23:20 GMT+09:00 Joe Gordon :
> On Tue, Mar 24, 2015 at 7:10 AM, Jay Pipes  wrote:
>> On Tue, Mar 24, 2015 at 01:04:46PM +, Jeremy Stanley wrote:
>> > On 2015-03-23 21:31:30 -0400 (-0400), Jay Pipes wrote:
>> > > On Mon, Mar 23, 2015 at 09:35:50PM +, Jeremy Stanley wrote:
>> > > > On 2015-03-23 15:15:18 -0400 (-0400), Jay Pipes wrote:
>> > > > [...]
>> > > > > I don't want it suppressed. I want the use of API extensions and
>> > > > > the
>> > > > > extension framework(s) to be completely dropped for all future
>> > > > > API-affecting work.
>> > > > [...]
>> > > >
>> > > > Perhaps controversial, but would it be worthwhile to propose to the
>> > > > Defcore working group that future compliance requirements include
>> > > > the absence of extensions to officially covered APIs?
>> > >
>> > > I don't understand what you're getting at, Jeremy. Could you
>> > > elaborate?
>> > >
>> > > What do extensions have to do with future compliance requirements?
>> >
>> > Defcore's focus is on establishing interoperability standards for
>> > OpenStack deployments, to ease the end-user experience. Right now
>> > its model depends on a whitelist of API features. As discussed many
>> > times before and brought up again in this thread, when providers or
>> > distributors "augment" OpenStack APIs to add their own special
>> > features without implementing them upstream, this necessarily
>> > creates interoperability issues.
>>
>> Defcore's focus is on determining what "is OpenStack", w.r.t. what is
>> brandable as OpenStack. It's focus is not on establishing interoperability
>> standards.
>>
>
> I am not sure how you got to that conclusion, yes the defcore process has
> been very confusing and I am still not really sure what it was, but some
> part of it it *is* about interoperability/
>
> Although our wiki does get out of date very easily, I think this still holds
> true:
>
> DefCore sets base requirements by defining 1) capabilities, 2) code and 3)
> must-pass tests for all OpenStack products. This definition uses community
> resources and involvement to drive interoperability by creating the minimum
> standards for products labeled "OpenStack."
>
> https://wiki.openstack.org/wiki/Governance/DefCoreCommittee

Related to this topic, Nova v2.1 API defines core APIs by itself[1],
but I feel now it is better to remove the definition from Nova.
On current implementation, the boot of nova-api fails if the above
core APIs are not loaded.
but that behavior seems conflict to Defcore process, and it would be
nice to concentrate on Defcore to define what are core APIs.

Thanks
Ken Ohmichi
---
[1]: 
https://github.com/openstack/nova/blob/master/nova/api/openstack/__init__.py#L66

__
OpenStack Development Mailing 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] [glance] a question regarding the current status of image "community" visibility support

[Brian Rosmaita]

Su,

The patch you are referring to is a work-in-progress patch.  It only partially 
implements the feature, and as one of the comments in the patch indicates, it's 
defining an Integer column in the database that might be replaced by an enum.  
So even if it were a full implementation, it would be dangerous to apply it to 
your local glance (unless you just wanted to use it in devstack or something).

Since you're interested in the feature, it would be helpful if you'd put a 
comment on the spec [1] to register your interest.  It's been talked about for 
a long time and could use a groundswell of support to land it in the Liberty 
release.

cheers,
brian

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

On 3/25/15, 9:07 PM, "Su Zhang" 
mailto:westlif...@gmail.com>> wrote:

Ian,

Thanks for your response!
I understand the situation that this specification is not accepted as of now.
However, given the fact that someone has already implemented this feature, 
could you possibly let me know if there is a way for me to apply such feature 
locally?

Thanks,

Su


On Wed, Mar 25, 2015 at 6:02 PM, Ian Cordasco 
mailto:ian.corda...@rackspace.com>> wrote:
That specification wasn’t accepted for Kilo. This discussion should be
taken to the mailing list anyway (openstack-dev).

On 3/25/15, 19:32, "Su Zhang" 
mailto:westlif...@gmail.com>> wrote:

>
>
>Thanks for your response Fei Long!
>
>
>I switched my environment to glance v2.
>However, I am encountering anther error saying that "community" is not
>one of the valid visibility values.
>Here is the running script in debug mode:
>
>
>su@ubuntu:/opt/stack/glance/glance$ glance --debug image-update
>--visibility community 4adda55e-fa6e-4605-aa42-aa5faabc04b8
>curl -g -i -X GET -H 'User-Agent: python-glanceclient' -H 'Content-Type:
>application/octet-stream' -H 'Accept-Encoding: gzip, deflate, compress'
>-H 'Accept: */*' -H 'X-Auth-Token:
>{SHA1}6ebf15bd27a056d97e4b66d5e6f1a4f27305b7b3'
>http://172.16.152.171:9292/v2/schemas/image
>
>
>HTTP/1.1 200 OK
>date: Thu, 26 Mar 2015 00:21:17 GMT
>content-length: 3867
>content-type: application/json; charset=UTF-8
>x-openstack-request-id: req-req-44ea8ad6-12e9-4a0b-9d93-2127b9f4b4f8
>
>
>{"additionalProperties": {"type": "string"}, "name": "image", "links":
>[{"href": "{self}", "rel": "self"}, {"href": "{file}", "rel":
>"enclosure"}, {"href": "{schema}", "rel": "describedby"}], "properties":
>{"status": {"enum": ["queued", "saving", "active",
> "killed", "deleted", "pending_delete"], "type": "string", "description":
>"Status of the image (READ-ONLY)"}, "tags": {"items": {"type": "string",
>"maxLength": 255}, "type": "array", "description": "List of strings
>related to the image"}, "kernel_id": {"pattern":
>
>"^([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-
>9a-fA-F]){12}$", "type": "string", "description": "ID of image stored in
>Glance that should be used as the kernel when booting an AMI-style
>image.", "is_base": false}, "container_format":
> {"enum": [null, "ami", "ari", "aki", "bare", "ovf", "ova"], "type":
>["null", "string"], "description": "Format of the container"}, "min_ram":
>{"type": "integer", "description": "Amount of ram (in MB) required to
>boot image."}, "ramdisk_id": {"pattern":
>"^([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-
>9a-fA-F]){12}$",
> "type": "string", "description": "ID of image stored in Glance that
>should be used as the ramdisk when booting an AMI-style image.",
>"is_base": false}, "locations": {"items": {"required": ["url",
>"metadata"], "type": "object", "properties": {"url": {"type":
> "string", "maxLength": 255}, "metadata": {"type": "object"}}}, "type":
>"array", "description": "A set of URLs to access the image file kept in
>external store"}, "visibility": {"enum": ["public", "private"], "type":
>"string", "description": "Scope of image
> accessibility"}, "updated_at": {"type": "string", "description": "Date
>and time of the last image modification (READ-ONLY)"}, "owner": {"type":
>["null", "string"], "description": "Owner of the image", "maxLength":
>255}, "file": {"type": "string", "description":
> "(READ-ONLY)"}, "min_disk": {"type": "integer", "description": "Amount
>of disk space (in GB) required to boot image."}, "virtual_size": {"type":
>["null", "integer"], "description": "Virtual size of image in bytes
>(READ-ONLY)"}, "id": {"pattern":
>"^([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-
>9a-fA-F]){12}$",
> "type": "string", "description": "An identifier for the image"}, "size":
>{"type": ["null", "integer"], "description": "Size of image file in bytes
>(READ-ONLY)"}, "instance_uuid": {"type": "string", "description": "ID of
>instance used to create this image.",
> "is_base": false}, "os_distro": {"type": "string", "description":
>"Common name of operating system distribution as specified in
>
>http://docs.openstack.org/trunk/openstack-compute/admin/content/adding-ima
>ges.html
>

[openstack-dev] [cinder] FCoE support in openstack

[Guo, Ruijing]

Hi,

I saw openstack cinder already supported iscsi & FC and didn’t support FCoE. 
Any plan to support it?

Is there any BP to cover it? If not, I may draft for it.

Thanks,
-Ruijing
__
OpenStack Development Mailing 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] a question regarding the current status of image "community" visibility support

[Su Zhang]

Ian,

Thanks for your response!
I understand the situation that this specification is not accepted as of
now.
However, given the fact that someone has already implemented this feature,
could you possibly let me know if there is a way for me to apply such
feature locally?

Thanks,

Su


On Wed, Mar 25, 2015 at 6:02 PM, Ian Cordasco 
wrote:

> That specification wasn’t accepted for Kilo. This discussion should be
> taken to the mailing list anyway (openstack-dev).
>
> On 3/25/15, 19:32, "Su Zhang"  wrote:
>
> >
> >
> >Thanks for your response Fei Long!
> >
> >
> >I switched my environment to glance v2.
> >However, I am encountering anther error saying that "community" is not
> >one of the valid visibility values.
> >Here is the running script in debug mode:
> >
> >
> >su@ubuntu:/opt/stack/glance/glance$ glance --debug image-update
> >--visibility community 4adda55e-fa6e-4605-aa42-aa5faabc04b8
> >curl -g -i -X GET -H 'User-Agent: python-glanceclient' -H 'Content-Type:
> >application/octet-stream' -H 'Accept-Encoding: gzip, deflate, compress'
> >-H 'Accept: */*' -H 'X-Auth-Token:
> >{SHA1}6ebf15bd27a056d97e4b66d5e6f1a4f27305b7b3'
> >http://172.16.152.171:9292/v2/schemas/image
> >
> >
> >HTTP/1.1 200 OK
> >date: Thu, 26 Mar 2015 00:21:17 GMT
> >content-length: 3867
> >content-type: application/json; charset=UTF-8
> >x-openstack-request-id: req-req-44ea8ad6-12e9-4a0b-9d93-2127b9f4b4f8
> >
> >
> >{"additionalProperties": {"type": "string"}, "name": "image", "links":
> >[{"href": "{self}", "rel": "self"}, {"href": "{file}", "rel":
> >"enclosure"}, {"href": "{schema}", "rel": "describedby"}], "properties":
> >{"status": {"enum": ["queued", "saving", "active",
> > "killed", "deleted", "pending_delete"], "type": "string", "description":
> >"Status of the image (READ-ONLY)"}, "tags": {"items": {"type": "string",
> >"maxLength": 255}, "type": "array", "description": "List of strings
> >related to the image"}, "kernel_id": {"pattern":
> >
> >"^([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-
> >9a-fA-F]){12}$", "type": "string", "description": "ID of image stored in
> >Glance that should be used as the kernel when booting an AMI-style
> >image.", "is_base": false}, "container_format":
> > {"enum": [null, "ami", "ari", "aki", "bare", "ovf", "ova"], "type":
> >["null", "string"], "description": "Format of the container"}, "min_ram":
> >{"type": "integer", "description": "Amount of ram (in MB) required to
> >boot image."}, "ramdisk_id": {"pattern":
> >"^([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-
> >9a-fA-F]){12}$",
> > "type": "string", "description": "ID of image stored in Glance that
> >should be used as the ramdisk when booting an AMI-style image.",
> >"is_base": false}, "locations": {"items": {"required": ["url",
> >"metadata"], "type": "object", "properties": {"url": {"type":
> > "string", "maxLength": 255}, "metadata": {"type": "object"}}}, "type":
> >"array", "description": "A set of URLs to access the image file kept in
> >external store"}, "visibility": {"enum": ["public", "private"], "type":
> >"string", "description": "Scope of image
> > accessibility"}, "updated_at": {"type": "string", "description": "Date
> >and time of the last image modification (READ-ONLY)"}, "owner": {"type":
> >["null", "string"], "description": "Owner of the image", "maxLength":
> >255}, "file": {"type": "string", "description":
> > "(READ-ONLY)"}, "min_disk": {"type": "integer", "description": "Amount
> >of disk space (in GB) required to boot image."}, "virtual_size": {"type":
> >["null", "integer"], "description": "Virtual size of image in bytes
> >(READ-ONLY)"}, "id": {"pattern":
> >"^([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-
> >9a-fA-F]){12}$",
> > "type": "string", "description": "An identifier for the image"}, "size":
> >{"type": ["null", "integer"], "description": "Size of image file in bytes
> >(READ-ONLY)"}, "instance_uuid": {"type": "string", "description": "ID of
> >instance used to create this image.",
> > "is_base": false}, "os_distro": {"type": "string", "description":
> >"Common name of operating system distribution as specified in
> >
> >
> http://docs.openstack.org/trunk/openstack-compute/admin/content/adding-ima
> >ges.html
> ><
> http://docs.openstack.org/trunk/openstack-compute/admin/content/adding-im
> >ages.html>", "is_base": false}, "name": {"type": ["null", "string"],
> >"description": "Descriptive name for the image", "maxLength": 255},
> >"checksum": {"type": ["null", "string"], "description":
> > "md5 hash of image contents. (READ-ONLY)", "maxLength": 32},
> >"created_at": {"type": "string", "description": "Date and time of image
> >registration (READ-ONLY)"}, "disk_format": {"enum": [null, "ami", "ari",
> >"aki", "vhd", "vmdk", "raw", "qcow2", "vdi", "iso"],
> > "type": ["null", "string"], "description": "Format of the disk"},
> >"os_version": {"type": "string", "description": "Operating system version
> >as specified by the d

[openstack-dev] [magnum] Re: Gerrit downtime Friday March 27 22:00 UTC

[Steven Dake (stdake)]

On 3/25/15, 4:56 PM, "Jeremy Stanley"  wrote:

>On Friday, March 27 at 22:00 UTC Gerrit will be unavailable for
>about 30 minutes while we rename some projects. Existing reviews,
>project watches, etc, should all be carried over. Currently, we plan
>on renaming the following 10 projects:
>
>stackforge/bindep -> openstack-infra/bindep
>stackforge/cookbook-monasca-agent ->
>stackforge-attic/cookbook-monasca-agent
>stackforge/cookbook-monasca-api ->
>stackforge-attic/cookbook-monasca-api
>stackforge/cookbook-monasca-notification ->
>stackforge-attic/cookbook-monasca-notification
>stackforge/cookbook-monasca-persister ->
>stackforge-attic/cookbook-monasca-persister
>stackforge/cookbook-monasca-schema ->
>stackforge-attic/cookbook-monasca-schema
>stackforge/cookbook-monasca-thresh ->
>stackforge-attic/cookbook-monasca-thresh
>stackforge/fuel-tasks-validator -> stackforge/fuel-tasklib
>stackforge/gnocchi -> openstack/gnocchi
>stackforge/xstatic-angular-irdragndrop ->
>stackforge/xstatic-angular-lrdragndrop
>
>These 8 pending renames do not yet have project-config changes
>proposed but may be performed during the maintenance if they're
>ready within the next 24-48 hours:
>
>stackforge/magnum -> openstack/magnum

https://review.openstack.org/167848

>stackforge/murano -> openstack/murano
>stackforge/murano-agent -> openstack/murano-agent
>stackforge/murano-apps -> openstack/murano-apps
>stackforge/murano-dashboard -> openstack/murano-dashboard
>stackforge/murano-specs -> openstack/murano-specs
>stackforge/python-magnumclient -> openstack/python-magnumclient

Same review

Thanks for the heads up about the deadline Jeremy.

Regards
-steve

>stackforge/python-muranoclient -> openstack/python-muranoclient
>
>-- 
>Jeremy Stanley


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

Re: [openstack-dev] Cinder Review Inbox Was RE: Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

[Arkady_Kanevsky]

Dell - Internal Use - Confidential
Thanks Mike.
Does work now.
Love the characterization it provides.

-Original Message-
From: Mike Perez [mailto:thin...@gmail.com]
Sent: Tuesday, March 24, 2015 4:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Cinder Review Inbox Was RE: Cinder Third-Party CI: 
what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers 
(no voting CI))

On 15:59 Tue 24 Mar , arkady_kanev...@dell.com wrote:
> Dell - Internal Use - Confidential
> The link from cinder page to Cinder review inbox
> (https://review.openstack.org/#/dashboard/) from
> https://wiki.openstack.org/wiki/Cinder#Resources is empty.
>
> Link to bugs does work.

I'm using the dashboard right now and it's working fine for me. Make sure 
you're logged into Gerrit before visiting.

--
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 Development Mailing 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] Gerrit downtime Friday March 27 22:00 UTC

[Jeremy Stanley]

On Friday, March 27 at 22:00 UTC Gerrit will be unavailable for
about 30 minutes while we rename some projects. Existing reviews,
project watches, etc, should all be carried over. Currently, we plan
on renaming the following 10 projects:

stackforge/bindep -> openstack-infra/bindep
stackforge/cookbook-monasca-agent ->
stackforge-attic/cookbook-monasca-agent
stackforge/cookbook-monasca-api ->
stackforge-attic/cookbook-monasca-api
stackforge/cookbook-monasca-notification ->
stackforge-attic/cookbook-monasca-notification
stackforge/cookbook-monasca-persister ->
stackforge-attic/cookbook-monasca-persister
stackforge/cookbook-monasca-schema ->
stackforge-attic/cookbook-monasca-schema
stackforge/cookbook-monasca-thresh ->
stackforge-attic/cookbook-monasca-thresh
stackforge/fuel-tasks-validator -> stackforge/fuel-tasklib
stackforge/gnocchi -> openstack/gnocchi
stackforge/xstatic-angular-irdragndrop ->
stackforge/xstatic-angular-lrdragndrop

These 8 pending renames do not yet have project-config changes
proposed but may be performed during the maintenance if they're
ready within the next 24-48 hours:

stackforge/magnum -> openstack/magnum
stackforge/murano -> openstack/murano
stackforge/murano-agent -> openstack/murano-agent
stackforge/murano-apps -> openstack/murano-apps
stackforge/murano-dashboard -> openstack/murano-dashboard
stackforge/murano-specs -> openstack/murano-specs
stackforge/python-magnumclient -> openstack/python-magnumclient
stackforge/python-muranoclient -> openstack/python-muranoclient

-- 
Jeremy Stanley


signature.asc
Description: 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] [Manila] Nominate Igor Malinovskiy for core team

[Li, Chen]

+1

-Original Message-
From: Thomas Bechtold [mailto:thomasbecht...@jpberlin.de] 
Sent: Thursday, March 26, 2015 4:44 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Manila] Nominate Igor Malinovskiy for core team

On 18.03.2015 20:04, Ben Swartzlander wrote:
> Igor (u_glide on IRC) joined the Manila team back in December and has 
> done a consistent amount of reviews and contributed significant new 
> core features in the last 2-3 months. I would like to nominate him to 
> join the Manila core reviewer team.

+1

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

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

Re: [openstack-dev] [infra] What do people think of YAPF (like gofmt, for python)?

[Monty Taylor]

On 03/25/2015 05:50 PM, Maru Newby wrote:
> I am excited by the release of YAPF [1], a gofmt-like too for python.
> I think it has the potential to simplify style enforcement, and as
> much as I appreciate our current hacking checks, I’d be much happier
> not requiring developers to manually conform to them.  Maybe we can
> consider automation in a manner similar to that employed by the go
> codereview tool [2]?

I played with it for a few minutes and although it's configurable, it's
still pretty limited in terms of expressiveness.

That said - although I do appreciate the theory of auto-formatting
(seriously, one less thing, right?) I think it would be problematic for
us. You can't ship git hooks in a git repo, so we can't help our users
know to run it before pushing. In a world where getting set up in
openstack is already non-trivial, I think requiring 2500 developers to
add a new git hook to every repo that they do something with would be a
bit of a disaster. When you combine that with the people who won't know,
will make a patch, send it up, and have it rejected --- oy. Chaos.

git review is used by a ton of people who write in non-python. I think
adding openstack-specific style enforcement to it would make it way less
generally useful.

In general, if you find it interesting, there's certainly nothing wrong
with tracking it and poking at it from time to time. But I honestly
think that the logistical issue is pretty large, and one that the payoff
from solving would not be worth the effort.

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] Fwd: a question regarding the current status of image "community" visibility support on glance

[Fei Long Wang]

visibility is an attribute of glance v2, so please try: glance 
--os-image-api-version 2 image-update --visibility private 
4adda55e-fa6e-4605-aa42-aa5faabc04b8


On 26/03/15 11:50, Su Zhang wrote:


Hello everyone

I recently came across one glance related pending blueprint 
(https://review.openstack.org/#/c/124050/). It raised our interest as 
we also want to implement this community visibility for images through 
glance. However, after cherry picking the code change 
(https://review.openstack.org/#/c/136374/), I was not able to get the 
expected result. Instead, I got the following error:



su@ubuntu:/opt/stack/glance/glance/db/sqlalchemy/migrate_repo/versions$ glance 
image-update --visibility private 4adda55e-fa6e-4605-aa42-aa5faabc04b8

usage: glance [--version] [-d] [-v] [--get-schema] [--timeout TIMEOUT]
[--no-ssl-compression] [-f] [--os-image-url OS_IMAGE_URL]
[--os-image-api-version OS_IMAGE_API_VERSION]
[--profile HMAC_KEY] [-k] [--os-cert OS_CERT]
[--cert-file OS_CERT] [--os-key OS_KEY] [--key-file OS_KEY]
[--os-cacert ] [--ca-file OS_CACERT]
[--os-username OS_USERNAME] [--os-user-id OS_USER_ID]
[--os-user-domain-id OS_USER_DOMAIN_ID]
[--os-user-domain-name OS_USER_DOMAIN_NAME]
[--os-project-id OS_PROJECT_ID]
[--os-project-name OS_PROJECT_NAME]
[--os-project-domain-id OS_PROJECT_DOMAIN_ID]
[--os-project-domain-name OS_PROJECT_DOMAIN_NAME]
[--os-password OS_PASSWORD] [--os-tenant-id OS_TENANT_ID]
[--os-tenant-name OS_TENANT_NAME] [--os-auth-url OS_AUTH_URL]
[--os-region-name OS_REGION_NAME]
[--os-auth-token OS_AUTH_TOKEN]
[--os-service-type OS_SERVICE_TYPE]
[--os-endpoint-type OS_ENDPOINT_TYPE]
 ...
glance: error: unrecognized arguments: --visibility 
4adda55e-fa6e-4605-aa42-aa5faabc04b8




Could any of you kindly give me some hints regarding how to get the 
issue fixed (if it is fixable)? Or anywhere I can change to code to 
enable the function mentioned in the blueprint?


Any response will be highly appreciated!

--
Su Zhang



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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
OpenStack Development Mailing 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] Fwd: a question regarding the current status of image "community" visibility support on glance

[Su Zhang]

Hello everyone

I recently came across one glance related pending blueprint (
https://review.openstack.org/#/c/124050/). It raised our interest as we
also want to implement this community visibility for images through glance.
However, after cherry picking the code change (
https://review.openstack.org/#/c/136374/), I was not able to get the
expected result. Instead, I got the following error:


su@ubuntu:/opt/stack/glance/glance/db/sqlalchemy/migrate_repo/versions$
glance image-update --visibility private
4adda55e-fa6e-4605-aa42-aa5faabc04b8
usage: glance [--version] [-d] [-v] [--get-schema] [--timeout TIMEOUT]
[--no-ssl-compression] [-f] [--os-image-url OS_IMAGE_URL]
[--os-image-api-version OS_IMAGE_API_VERSION]
[--profile HMAC_KEY] [-k] [--os-cert OS_CERT]
[--cert-file OS_CERT] [--os-key OS_KEY] [--key-file OS_KEY]
[--os-cacert ] [--ca-file OS_CACERT]
[--os-username OS_USERNAME] [--os-user-id OS_USER_ID]
[--os-user-domain-id OS_USER_DOMAIN_ID]
[--os-user-domain-name OS_USER_DOMAIN_NAME]
[--os-project-id OS_PROJECT_ID]
[--os-project-name OS_PROJECT_NAME]
[--os-project-domain-id OS_PROJECT_DOMAIN_ID]
[--os-project-domain-name OS_PROJECT_DOMAIN_NAME]
[--os-password OS_PASSWORD] [--os-tenant-id OS_TENANT_ID]
[--os-tenant-name OS_TENANT_NAME] [--os-auth-url OS_AUTH_URL]
[--os-region-name OS_REGION_NAME]
[--os-auth-token OS_AUTH_TOKEN]
[--os-service-type OS_SERVICE_TYPE]
[--os-endpoint-type OS_ENDPOINT_TYPE]
 ...
glance: error: unrecognized arguments: --visibility
4adda55e-fa6e-4605-aa42-aa5faabc04b8



Could any of you kindly give me some hints regarding how to get the issue
fixed (if it is fixable)? Or anywhere I can change to code to enable the
function mentioned in the blueprint?

Any response will be highly appreciated!

-- 
Su Zhang
__
OpenStack Development Mailing 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] Barbican : Unable to install Barbican on CentOS due to Import Error

[Asha Seshagiri]

Hi John,

Thanks a lot for your response :)
I followed the instructions from
https://github.com/cloudkeep/barbican/wiki/Barbican-Quick-Start-Guide

There were few packages that were missing .Please find the Additional steps
below :

   - pip install pecan - will install pecan
   - pip install alembic - will install alembic
   - yum install openldap-devel
   - pip install python-ldap

Thanks and Regards,
Asha Seshagiri

On Wed, Mar 25, 2015 at 5:17 PM, John Wood  wrote:

>  Hello Asha,
>
>  It seems like your installer script might be crashing for some reason.
> You might need to execute the steps in the installer script manually to
> stand things up, such as the pip install step here:
> https://github.com/openstack/barbican/blob/master/bin/barbican.sh#L87
>
>  Please let us know if that helps.
>
>  Thanks,
> John
>
>   From: Asha Seshagiri 
> Date: Wednesday, March 25, 2015 at 2:24 PM
> To: openstack-dev 
> Cc: John Wood , Douglas Mendizabal <
> douglas.mendiza...@rackspace.com>, "Reller, Nathan S." <
> nathan.rel...@jhuapl.edu>
> Subject: Barbican : Unable to install Barbican on CentOS due to Import
> Error
>
>   Hi  ,
>
>  When I tried installing barbican using the command  bin/barbican.sh
> install , I got the following error  :
>
>  *ImportError: No module named pecan*
> Traceback (most recent call last):
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
> line 247, in loadapp
> return loadobj(APP, uri, name=name, **kw)
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
> line 272, in loadobj
> return context.create()
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
> line 710, in create
> return self.object_type.invoke(self)
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
> line 144, in invoke
> **context.local_conf)
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/util.py",
> line 55, in fix_call
> val = callable(*args, **kw)
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/urlmap.py",
> line 25, in urlmap_factory
> app = loader.get_app(app_name, global_conf=global_conf)
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
> line 350, in get_app
> name=name, global_conf=global_conf).create()
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
> line 362, in app_context
> APP, name=name, global_conf=global_conf)
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
> line 450, in get_context
> global_additions=global_additions)
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
> line 559, in _pipeline_app_context
> APP, pipeline[-1], global_conf)
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
> line 458, in get_context
> section)
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
> line 517, in _context_from_explicit
> value = import_string(found_expr)
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
> line 22, in import_string
> return pkg_resources.EntryPoint.parse("x=" + s).load(False)
>   File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line
> 2320, in load
>   File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line
> 2326, in resolve
>   File "/root/barbican/barbican/api/__init__.py", line 22, in 
> import pecan
> ImportError: No module named pecan
> OOPS ! failed loading app in worker 1 (pid 27606) :( trying again...
> worker respawning too fast !!! i have to sleep a bit (2 seconds)...
> OOPS ! failed loading app in worker 1 (pid 27607) :( trying again...
> worker respawning too fast !!! i have to sleep a bit (2 seconds)...
> Respawned uWSGI worker 1 (new pid: 27608)
> Respawned uWSGI worker 1 (new pid: 27609)
> Loading paste environment: config:/etc/barbican/barbican-api-paste.ini
> Loading paste environment: config:/etc/barbican/barbican-admin-paste.ini
> Traceback (most recent call last):
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
> line 247, in loadapp
> return loadobj(APP, uri, name=name, **kw)
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
> line 271, in loadobj
> global_conf=global_conf)
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
> line 296, in loadcontext
> global_conf=global_conf)
>   File
> "/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
> line 320, in _loadconfig
> return loader.get_

Re: [openstack-dev] [infra] What do people think of YAPF (like gofmt, for python)?

[Joshua Harlow]

Unsure, I've always been iff on auto-tools like that.

Especially with things like: https://github.com/google/yapf/issues/10

But maybe in time...

IMHO the hacking rules aren't that much to learn and are good to know 
anyway.


-Josh

Maru Newby wrote:

I am excited by the release of YAPF [1], a gofmt-like too for python.  I think 
it has the potential to simplify style enforcement, and as much as I appreciate 
our current hacking checks, I’d be much happier not requiring developers to 
manually conform to them.  Maybe we can consider automation in a manner similar 
to that employed by the go codereview tool [2]?

Cheers,


Maru

1: https://github.com/google/yapf
2: https://godoc.org/golang.org/x/review/git-codereview#hdr-Gofmt
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [release] taskflow 0.8.0

[Joshua Harlow]

We are stoked to announce the release of:

taskflow 0.8.0: Taskflow structured state management library.

For more details, please see the git log history below and:

http://launchpad.net/taskflow/+milestone/0.8.0

Please report issues through launchpad:

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

Notable changes


* The default engine storage is now always using a in-memory backend
  instead of just using local objects and caching results and data
  in those. This will help make the engine storage backend more
  uniform and require less customizations to use.
* Large refactoring of backend path 'like' implementations (zookeeper,
  directory/file based and the in-memory backend).
* New ``EventTimeListener`` that records when state changes
  happen (useful for gathering data about how long your workflows
  take, and how long the tasks in them take).
* Support for python 3.3 has been removed (as it is no longer tested and
  3.4 is the stable 3.x release that is being tested against).
* Jobboards now have a trash() method that can be used
  to 'trash' jobs that should not be operated on (and can be
  used to look at for later analysis or for deleting).
* Conductors now have entrypoints that should be used for
  loading (instead of accessing the direct conductor
  classes). The fetch() method of ``taskflow.conductors.backends``
  should be used to retrieve your desired conductor object.
* A new map/reduce functor task which has many potential uses.
* Removal of ``taskflow.types.timing.StopWatch`` (it has now been
  moved to the oslo.utils library where it can be shared to a
  larger audience); a proxy object will still exist in
  ``taskflow.types.timing`` but using the new location in
  ``oslo.utils.timeutils`` should be preferred instead.
* Usage of new debtcollector library functions.
* Better WBE send/receive data validation (using jsonschema).
* Atom provides/requires/optional/save_as now use an ordered dict or
  ordered set by default so that any specified ordering is capable of
  being maintained.

Changes in taskflow 0.7.1..0.8.0


NOTE: Skipping requirement commits...

cdcb248 Adding test to improve CaptureListener coverage
cd54139 Prefer posixpath to os.path
f815480 By default use a in memory backend (when none is provided)
dc2fdaf Allow using shallow copy instead of deep copy
7d79e52 Move to the newer debtcollector provided functions
6723a18 Move to using the oslo.utils stop watch
579500d Ensure thread-safety of persistence dir backend
658d1f9 Ensure we are really setup before being connected
765037d Ensure docstring on storage properties
f7b3c23 Expose the storage backend being used
da73113 Use iteration instead of list(s) when extracting scopes
dd33ec7 Use binary/encode decode helper routines in dir backend
6db6363 Rename memory backend filesystem -> fake filesystem
3579410 Always return scope walker instances from `fetch_scopes_for`
374d91d Give the GC a break
6671ce4 Use the class name instead of the TYPE property in __str__
ebe3d6d Just use the class name instead of TYPE constant
5d2fb53 Attempt to extract traceback from exception
ac2b1be Use compatible map and update map/reduce task docs
d1742b1 Update engine docs with new validation stage
a1f9321 Ensure we register & deregister conductor listeners
87d6f58 Rename attribute '_graph' to '_execution_graph'
7e052e0 Add a log statement pre-validation that dumps graph info
5209961 Have this example exit non-zero if incorrect results
bf5164e Use a collections.namedtuple for the request work unit
0e952e6 Some small wbe engine doc tweaks
c1f0200 Add newline to avoid sphinx warning
526f287 Allow passing 'many_handler' to fetch_all function
12c28bb Ensure event time listener is in listeners docs
8602118 Add a in-memory backend dumping example
0a2928f Added a map and a reduce task
6529c1e Restructure the in-memory node usage
f6e2074 Switch to non-namespaced module imports
5996c8f Allow the storage unit to use the right scoping strategy
94eb978 Just use the local conf variable
844c2c6 Put underscore in-front of alchemist helper
9f64c47 lazy loading for logbooks and flowdetails
646ca59 Allow backend connection config (via fetch) to be a string
ad133ad Add + use failure json schema validation
67f0f51 Use ordered[set/dict] to retain ordering
f0de22c Allow injected atom args to be persisted
8e62483 add _listeners_from_job method to Conductor base
b9b6576 update uses of TimingListener to DurationListener
7d3ae77 Added EventTimeListner to record when events occur
8c08869 added update_flow_metadata method to Storage class
1478f52 Retain nested causes where/when we can
1f4e596 Denote issue 17911 has been merged/accepted
3e8eb91 Persistence backend refactor
c22c62d Remove support for 3.3
00ab628 Writers can now claim a read lock in ReaderWriterLock
47c0269 Add another probabilistic rw-lock test
20fdbba Add + use read/write lock decorators
89087fd Add no double writers thread test
d302b52 Use condition context manage

Re: [openstack-dev] Barbican : Unable to install Barbican on CentOS due to Import Error

[John Wood]

Hello Asha,

It seems like your installer script might be crashing for some reason. You 
might need to execute the steps in the installer script manually to stand 
things up, such as the pip install step here: 
https://github.com/openstack/barbican/blob/master/bin/barbican.sh#L87

Please let us know if that helps.

Thanks,
John

From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Date: Wednesday, March 25, 2015 at 2:24 PM
To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Cc: John Wood mailto:john.w...@rackspace.com>>, 
Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>, 
"Reller, Nathan S." mailto:nathan.rel...@jhuapl.edu>>
Subject: Barbican : Unable to install Barbican on CentOS due to Import Error

Hi  ,

When I tried installing barbican using the command  bin/barbican.sh install , I 
got the following error  :

ImportError: No module named pecan
Traceback (most recent call last):
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 247, in loadapp
return loadobj(APP, uri, name=name, **kw)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 272, in loadobj
return context.create()
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 710, in create
return self.object_type.invoke(self)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 144, in invoke
**context.local_conf)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/util.py",
 line 55, in fix_call
val = callable(*args, **kw)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/urlmap.py", 
line 25, in urlmap_factory
app = loader.get_app(app_name, global_conf=global_conf)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 350, in get_app
name=name, global_conf=global_conf).create()
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 362, in app_context
APP, name=name, global_conf=global_conf)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 450, in get_context
global_additions=global_additions)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 559, in _pipeline_app_context
APP, pipeline[-1], global_conf)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 458, in get_context
section)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 517, in _context_from_explicit
value = import_string(found_expr)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 22, in import_string
return pkg_resources.EntryPoint.parse("x=" + s).load(False)
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2320, in 
load
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2326, in 
resolve
  File "/root/barbican/barbican/api/__init__.py", line 22, in 
import pecan
ImportError: No module named pecan
OOPS ! failed loading app in worker 1 (pid 27606) :( trying again...
worker respawning too fast !!! i have to sleep a bit (2 seconds)...
OOPS ! failed loading app in worker 1 (pid 27607) :( trying again...
worker respawning too fast !!! i have to sleep a bit (2 seconds)...
Respawned uWSGI worker 1 (new pid: 27608)
Respawned uWSGI worker 1 (new pid: 27609)
Loading paste environment: config:/etc/barbican/barbican-api-paste.ini
Loading paste environment: config:/etc/barbican/barbican-admin-paste.ini
Traceback (most recent call last):
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 247, in loadapp
return loadobj(APP, uri, name=name, **kw)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 271, in loadobj
global_conf=global_conf)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 296, in loadcontext
global_conf=global_conf)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 320, in _loadconfig
return loader.get_context(object_type, name, global_conf)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 450, in get_context
global_additions=global_additions)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 559, in _pipeline_app_context
APP, pipeline[-1], global_conf)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 458, in get_context
section)
  File 
"/root/.pyenv/versions/bar

[openstack-dev] [infra] What do people think of YAPF (like gofmt, for python)?

[Maru Newby]

I am excited by the release of YAPF [1], a gofmt-like too for python.  I think 
it has the potential to simplify style enforcement, and as much as I appreciate 
our current hacking checks, I’d be much happier not requiring developers to 
manually conform to them.  Maybe we can consider automation in a manner similar 
to that employed by the go codereview tool [2]?

Cheers,


Maru

1: https://github.com/google/yapf
2: https://godoc.org/golang.org/x/review/git-codereview#hdr-Gofmt
__
OpenStack Development Mailing 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] [glance] image-create failed vcender backend

[Sergiy Lystopad]

Hi,colleagues.

I've faced with an issue https://bugs.launchpad.net/glance/+bug/1436034
during mos 6.0 with vcenter deployment for customer.

could you help me  do debug and fix issue.

Thanks

-- 
Sergiy Lystopad
__
OpenStack Development Mailing 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] [Manila] Nominate Igor Malinovskiy for core team

[Thomas Bechtold]

On 18.03.2015 20:04, Ben Swartzlander wrote:
> Igor (u_glide on IRC) joined the Manila team back in December and has
> done a consistent amount of reviews and contributed significant new core
> features in the last 2-3 months. I would like to nominate him to join
> the Manila core reviewer team.

+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] [nova]Reviews for #164308 - Expand valid server group name character set

[Matt Riedemann]

On 3/25/2015 3:01 PM, Jennifer Mulsow wrote:

Would anyone be willing to review
https://review.openstack.org/#/c/164308/ (Expand valid server group name
character set)? It has a few +1s, but there hasn't been any activity on
it in a couple days.

Thank you,
Jennifer Mulsow
Cloud Systems Software Development
IBM Systems & Technology Group


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



The mailing list is not a place for requesting reviews, so please don't 
do it.


There are many changes out there [1] so be patient.

[1] http://russellbryant.net/openstack-stats/nova-openreviews.html

--

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] [Fuel] Nominate Irina Povolotskaya for fuel-docs core

[Tomasz Napierala]

+1 definately

> On 25 Mar 2015, at 20:10, Dmitry Borodaenko  wrote:
> 
> Fuelers,
> 
> I'd like to nominate Irina Povolotskaya for the fuel-docs-core team.
> She has contributed thousands of lines of documentation to Fuel over
> the past several months, and has been a diligent reviewer:
> 
> http://stackalytics.com/?user_id=ipovolotskaya&release=all&project_type=all&module=fuel-docs
> 
> I believe it's time to grant her core reviewer rights in the fuel-docs
> repository.
> 
> Core reviewer approval process definition:
> https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> 
> -- 
> Dmitry Borodaenko
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







__
OpenStack Development Mailing 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] [Murano] Announcing Bug-Scrub Day on March 27

[Serg Melikyan]

Hi folks,

As we agreed on last community meeting we announce this Friday (March
27) as Bug-Scrub Day. This day would be dedicated for cleaning-up our
bugs in launchpad [1]. By cleaning-up we mean triaging bugs and
assigning them on the next milestone - kilo-rc1.

We encourage you to join us in order to take and fix some bugs in
Murano, help to identify & verify issues, and correctly assign
priorities.

P.S. Bug-Scrub Day is 24h event, in order to span across the globe
with all our contributors, but we expect to have most of the
contributors in #murano channel on FreeNode starting from 9 am UTC.

References:
[1] https://bugs.launchpad.net/murano

-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

+7 (495) 640-4904, 0261
+7 (903) 156-0836

__
OpenStack Development Mailing 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] Nominate Irina Povolotskaya for fuel-docs core

[Lukasz Oles]

+1

On Wed, Mar 25, 2015 at 8:10 PM, Dmitry Borodaenko
 wrote:
> Fuelers,
>
> I'd like to nominate Irina Povolotskaya for the fuel-docs-core team.
> She has contributed thousands of lines of documentation to Fuel over
> the past several months, and has been a diligent reviewer:
>
> http://stackalytics.com/?user_id=ipovolotskaya&release=all&project_type=all&module=fuel-docs
>
> I believe it's time to grant her core reviewer rights in the fuel-docs
> repository.
>
> Core reviewer approval process definition:
> https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>
> --
> Dmitry Borodaenko
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Łukasz Oleś

__
OpenStack Development Mailing 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] Nominate Irina Povolotskaya for fuel-docs core

[Evgeniy L]

+1 from me

On Wed, Mar 25, 2015 at 12:35 PM, Mike Scherbakov 
wrote:

> +1
>
> On Wed, Mar 25, 2015 at 12:17 PM, Christopher Aedo 
> wrote:
>
>> +1 from me, this is a great suggestion.
>>
>> -Christopher
>>
>> On Wed, Mar 25, 2015 at 12:10 PM, Dmitry Borodaenko
>>  wrote:
>> > Fuelers,
>> >
>> > I'd like to nominate Irina Povolotskaya for the fuel-docs-core team.
>> > She has contributed thousands of lines of documentation to Fuel over
>> > the past several months, and has been a diligent reviewer:
>> >
>> >
>> http://stackalytics.com/?user_id=ipovolotskaya&release=all&project_type=all&module=fuel-docs
>> >
>> > I believe it's time to grant her core reviewer rights in the fuel-docs
>> > repository.
>> >
>> > Core reviewer approval process definition:
>> > https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>> >
>> > --
>> > Dmitry Borodaenko
>> >
>> >
>> __
>> > OpenStack Development Mailing 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
>>
>
>
>
> --
> 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
>
>
__
OpenStack Development Mailing 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]Reviews for #164308 - Expand valid server group name character set

[Jennifer Mulsow]

Would anyone be willing to review https://review.openstack.org/#/c/164308/
(Expand valid server group name character set)? It has a few +1s, but there
hasn't been any activity on it in a couple days.

Thank you,
Jennifer Mulsow
Cloud Systems Software Development
IBM Systems & Technology Group__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] stable-maint for oslo.vmware

[Doug Hellmann]

Excerpts from Vipin Balachandran's message of 2015-03-25 10:50:17 +:
> Doug,
> 
> Please add me to the stable maintenance team for oslo.vmware.

fungi created the oslo-vmware-stable-maint group (thanks!) and I've
added oslo-stable-maint and Vipin to it so we can manage stable
backports for oslo.vmware.

Doug

> 
> Thanks,
> Vipin
> 
> -Original Message-
> From: Doug Hellmann [mailto:d...@doughellmann.com] 
> Sent: Tuesday, March 24, 2015 2:08 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [oslo] stable-maint for oslo.vmware
> 
> Gary pinged me on IRC earlier today and I missed him, so I’m sending this to 
> the list in case someone else wants to volunteer.
> 
> It sounds like there are some stable branch changes for oslo.vmware that need 
> attention. Does someone on the oslo.vmware team want to volunteer to be on a 
> stable-maintenance team for the library?
> 
> Doug
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Fuel] Nominate Irina Povolotskaya for fuel-docs core

[Mike Scherbakov]

+1

On Wed, Mar 25, 2015 at 12:17 PM, Christopher Aedo 
wrote:

> +1 from me, this is a great suggestion.
>
> -Christopher
>
> On Wed, Mar 25, 2015 at 12:10 PM, Dmitry Borodaenko
>  wrote:
> > Fuelers,
> >
> > I'd like to nominate Irina Povolotskaya for the fuel-docs-core team.
> > She has contributed thousands of lines of documentation to Fuel over
> > the past several months, and has been a diligent reviewer:
> >
> >
> http://stackalytics.com/?user_id=ipovolotskaya&release=all&project_type=all&module=fuel-docs
> >
> > I believe it's time to grant her core reviewer rights in the fuel-docs
> > repository.
> >
> > Core reviewer approval process definition:
> > https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> >
> > --
> > Dmitry Borodaenko
> >
> >
> __
> > OpenStack Development Mailing 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
>



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

[openstack-dev] Barbican : Unable to install Barbican on CentOS due to Import Error

[Asha Seshagiri]

Hi  ,

When I tried installing barbican using the command  bin/barbican.sh install
, I got the following error  :

*ImportError: No module named pecan*
Traceback (most recent call last):
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 247, in loadapp
return loadobj(APP, uri, name=name, **kw)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 272, in loadobj
return context.create()
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 710, in create
return self.object_type.invoke(self)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 144, in invoke
**context.local_conf)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/util.py",
line 55, in fix_call
val = callable(*args, **kw)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/urlmap.py",
line 25, in urlmap_factory
app = loader.get_app(app_name, global_conf=global_conf)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 350, in get_app
name=name, global_conf=global_conf).create()
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 362, in app_context
APP, name=name, global_conf=global_conf)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 450, in get_context
global_additions=global_additions)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 559, in _pipeline_app_context
APP, pipeline[-1], global_conf)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 458, in get_context
section)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 517, in _context_from_explicit
value = import_string(found_expr)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 22, in import_string
return pkg_resources.EntryPoint.parse("x=" + s).load(False)
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2320,
in load
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2326,
in resolve
  File "/root/barbican/barbican/api/__init__.py", line 22, in 
import pecan
ImportError: No module named pecan
OOPS ! failed loading app in worker 1 (pid 27606) :( trying again...
worker respawning too fast !!! i have to sleep a bit (2 seconds)...
OOPS ! failed loading app in worker 1 (pid 27607) :( trying again...
worker respawning too fast !!! i have to sleep a bit (2 seconds)...
Respawned uWSGI worker 1 (new pid: 27608)
Respawned uWSGI worker 1 (new pid: 27609)
Loading paste environment: config:/etc/barbican/barbican-api-paste.ini
Loading paste environment: config:/etc/barbican/barbican-admin-paste.ini
Traceback (most recent call last):
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 247, in loadapp
return loadobj(APP, uri, name=name, **kw)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 271, in loadobj
global_conf=global_conf)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 296, in loadcontext
global_conf=global_conf)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 320, in _loadconfig
return loader.get_context(object_type, name, global_conf)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 450, in get_context
global_additions=global_additions)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 559, in _pipeline_app_context
APP, pipeline[-1], global_conf)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 458, in get_context
section)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 517, in _context_from_explicit
value = import_string(found_expr)
  File
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
line 22, in import_string
return pkg_resources.EntryPoint.parse("x=" + s).load(False)

Any help would be appreciated!
Thanks in advance !

-- 
*Thanks and Regards,*
*Asha Seshagiri*
__
OpenStack Development Mailing 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] [Murano] python-muranoclient 0.5.6 released

[Serg Melikyan]

Today we released python-muranoclient 0.5.6 [1], this release includes
fixes for 8 bugs, including 5 high bugs. This version also includes
support for number of a new features introduced in Kilo:

* Murano Repository (blueprint [2], spec [3])
* Environment Template Catalog (blueprint [4], spec [5])
* Category Management (blueprint [4], spec [5])

Changes to increase number of python-muranoclient in requirements.txt
are proposed:

* murano: https://review.openstack.org/167583
* murano-dashboard: https://review.openstack.org/167580

Unfortunately not all PyPI mirrors on OpenStack infrastructure are
synced with official PyPI mirrors, once they will be synced jobs will
become green and change-requests ready to merge.

References:
[1] https://launchpad.net/python-muranoclient/kilo/0.5.6
[2] 
https://blueprints.launchpad.net/murano/+spec/muranoclient-marketplace-support
[3] https://review.openstack.org/161471
[4] https://blueprints.launchpad.net/murano/+spec/environment-template
[5] 
http://murano-specs.readthedocs.org/en/latest/specs/kilo/blueprint-template.html
[6] https://blueprints.launchpad.net/murano/+spec/enable-category-management
[7] https://review.openstack.org/139630
-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@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] [Fuel] Nominate Irina Povolotskaya for fuel-docs core

[Christopher Aedo]

+1 from me, this is a great suggestion.

-Christopher

On Wed, Mar 25, 2015 at 12:10 PM, Dmitry Borodaenko
 wrote:
> Fuelers,
>
> I'd like to nominate Irina Povolotskaya for the fuel-docs-core team.
> She has contributed thousands of lines of documentation to Fuel over
> the past several months, and has been a diligent reviewer:
>
> http://stackalytics.com/?user_id=ipovolotskaya&release=all&project_type=all&module=fuel-docs
>
> I believe it's time to grant her core reviewer rights in the fuel-docs
> repository.
>
> Core reviewer approval process definition:
> https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>
> --
> Dmitry Borodaenko
>
> __
> OpenStack Development Mailing 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] [Fuel] Nominate Irina Povolotskaya for fuel-docs core

[Dmitry Borodaenko]

Fuelers,

I'd like to nominate Irina Povolotskaya for the fuel-docs-core team.
She has contributed thousands of lines of documentation to Fuel over
the past several months, and has been a diligent reviewer:

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

I believe it's time to grant her core reviewer rights in the fuel-docs
repository.

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

-- 
Dmitry Borodaenko

__
OpenStack Development Mailing 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] Cinder-service connectivity issues

[Vishvananda Ishaya]

Based on the checkin times in your post, it looks like time is out of sync 
between your nodes. The one reporting down is reporting time in the future. I 
would install ntp and make sure the clocks are in sync.

Vish

On Mar 25, 2015, at 2:33 AM, Kamsali, RaghavendraChari (Artesyn) 
 wrote:

>  
> Please find attachment log (c-api) , when I execute command cinder create 1.
>  
>  
> From: Kamsali, RaghavendraChari (Artesyn) 
> [mailto:raghavendrachari.kams...@artesyn.com] 
> Sent: Wednesday, March 25, 2015 1:39 PM
> To: Ritesh Nanda
> Cc: openstack-dev@lists.openstack.org; openst...@lists.openstack.org
> Subject: Re: [Openstack] Cinder-service connectivity issues
>  
> FYI,
>  
> From: Ritesh Nanda [mailto:riteshnand...@gmail.com] 
> Sent: Wednesday, March 25, 2015 1:09 PM
> To: Kamsali, RaghavendraChari [ENGINEERING/IN]
> Cc: openst...@lists.openstack.org; openstack-dev@lists.openstack.org
> Subject: Re: [Openstack] Cinder-service connectivity issues
>  
> Can you run cinder-scheduler , volume service in debug mode and paste the 
> logs.
>  
> Regards,
> Ritesh 
>  
> On Wed, Mar 25, 2015 at 12:10 AM, Kamsali, RaghavendraChari (Artesyn) 
>  wrote:
> Hi,
>  
> My setup is shown below having  three networks (management, storage, 
> data/virtual) .
>  
>  
> 
>  
> Am facing issue when I bring up the setup as shown above scenario , could 
> anyone help me to figure out did I configured incorrectly or doing anything 
> wrong .
>  
> On Controller Node
>  
> SERVICES ENABLED: (c-sch,c-api)
> Management-> 192.168.21.108
> Storage-> 10.130.98.97
>  
> Cinder_configarations :
>  
> my_ip : 10.130.98.97 (also tried 19.2168.21.108)
> glance_host:10.130.98.97 (also tried 192.168.21.108)
> iscsi_ip_address: 10.130.98.97 (also tried 192.168.21.108)
>  
> 
>  
>  
> 
>  
> On Storage Node
>  
> SERVICES ENABLED: (c-vol)
> Management -> 192.1689.21.107
> Stroage -> 10.130.98.136
>  
> my_ip : 10.130.98.97 (also tried 19.2168.21.108)
> glance_host:10.130.98.97 (also tried 192.168.21.108)
> iscsi_ip_address: 10.130.98.97 (also tried 192.168.21.108)
> lvmdriver-1.iscsi_ip_address   : 10.130.98.136 (also tried 192.168.21.107)
>  
>  
> 
>  
>  
> Thanks and Regards,
> Raghavendrachari kamsali | Software Engineer II  | Embedded Computing
> Artesyn Embedded Technologies | 5th Floor, Capella Block, The V, Madhapur| 
> Hyderabad, AP 500081 India
>  
> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> 
> 
>  
> --
>  With Regards 
>  Ritesh Nanda
> __
> OpenStack Development Mailing 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] [Openstack-operators] [Neutron] allow_overlapping_ips (was: Deprecating the use_namespaces option ...)

[Mohammad Banikazemi]

The allow_overlapping_ips configuration option in it's current form was
mainly used to cover older distros that did not support namespaces as you
have mentioned. That's why in its current form this option operates across
all networks of all tenants. That is, if the option is set to false,
overlapping IPs are not allowed even across tenants.
If the option is to be redefined/reimplemented/interpreted as allowing or
disallowing overlapping IPs within the scope of a single tenant, then I
think that would be useful to some.

Mohammad




From:   Carl Baldwin 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   03/25/2015 11:37 AM
Subject:[openstack-dev] [Openstack-operators] [Neutron]
allow_overlapping_ips (was: Deprecating the use_namespaces
option ...)



Yesterday, I got looking at another option that I had completely
forgotten about.  It is "allow_overlapping_ips", set in neutron.conf
and defaults to False.  It appears that when it is False, Neutron
doesn't allow any overlapping IPs throughout the deployment, across
all networks.  My guess is that the vast majority of deployments will
set this to True as a matter of course.

My suspicion is that this option is related to the use_namespaces
option because if namespaces are not used, then isolating routing
domains would not be possible on the network node.  However, there may
be other reasons for needing this option.

I'm not yet proposing this option be deprecated.  I'm asking for
feedback from operators and others who might be using the default
value of False.

Carl

On Tue, Mar 24, 2015 at 1:21 PM, Assaf Muller  wrote:
> Note that https://review.openstack.org/#/c/166888/ has been merged.
> This means that the option has been deprecated for K and will be
> removed in L. Anyone using the non-default value of False will be looking
> at errors in his logs.
>
> - Original Message -
>>
>>
>> On 3/23/2015 3:56 AM, Miguel Ángel Ajo wrote:
>> > I see you point Van,
>> >
>> > In the other hand, removing it, cleans up lot of conditional code
parts
>> > (moving parts at the other side),
>> > and also the non-netns case is not tested by upstream CI, AFAIK, so it
>> > could be broken anytime
>> > and we would not notice it.
>> >
>> >
>> >
>> > Miguel Ángel Ajo
>> >
>> > On Monday, 23 de March de 2015 at 9:25, Van Leeuwen, Robert wrote:
>> >
>> >>> I think there are valid reasons to not use namespaces:
>> >>>
>> >>>   * Fewer moving parts == less can potentialy fail
>> >>>   * Troubleshooting is easier due to less places to look / need no
>> >>> familiarity with namespaces & tools
>> >>>   * If I remember correctly setting up a namespace can get really
>> >>> slow when you have a lot of them on a single machine
>> >>>
>> >>
>> >> > IMHO, those shouldn’t be valid reasons anymore, since they were due
>> >> > iproute, or sudo issues
>> >> > that have been corrected long ago, and all distros installing
neutron
>> >> > are supporting netns at this
>> >>
>> >> Well, you exactly made my point:
>> >> There is lots that can and will go wrong with more moving parts.
>> >> That they are fixed at the moment does not mean that there will not
be
>> >> a new bug in the future…
>> >>
>> >> Cheers,
>> >> Robert van Leeuwen
>> >> ___
>> >> OpenStack-operators mailing list
>> >> openstack-operat...@lists.openstack.org
>> >> 
>> >>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> >
>> >
>> >
>> >
__
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> FWIW we were doing CI without namespaces before Kilo simply due to RHEL
>> 6.5 not having the support w/o a kernel patch.
>>
>> Since Kilo dropped py26 support we moved to RHEL 7* for py27 and that
>> has namespace support so it's no longer an issue for us.
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>>
__
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Openstack-operators] [Neutron] allow_overlapping_ips

[Kevin Benton]

Yes, sorry I should have specified that. Salvatore is right that this
depends on the quota mechanism to prevent them from exhausting the entire
pool.

On Wed, Mar 25, 2015 at 10:09 AM, Neil Jerram 
wrote:

> Salvatore Orlando  writes:
>
> > On 25 March 2015 at 17:36, Neil Jerram 
> > wrote:
> >
> > Kevin Benton  writes:
> >
> > > This is a nice option for smaller deployments that didn't need
> > the
> > > complexity of NAT. From a custom L3 plugin perspective, it also
> > > eliminated any single points of failure pretty easily since no
> > NAT
> > > state had to be distributed.
> > >
> > > However, it was difficult to use with tenant self-service since
> > one
> > > tenant could create a subnet that ate up the whole routing
> > space. It
> > > basically required that the networking was done by an admin or
> > that
> > > the entire deployment was shared by a group of users trusted to
> > do the
> > > right thing.
> > >
> > > My main interest in the IPAM work was to support fully routable
> > > deployments like this. Once IPAM has a workflow that covers
> > tenant
> > > subnet allocation from a subnet pool shared by the whole
> > deployment, I
> > > think deprecation of the "allow_overlapping_ips" option makes
> > perfect
> > > sense since the operator can just create a single global subnet
> > pool
> > > to simulate it.
> >
> > I'm not defending allow_overlapping_ips, but I'm afraid I don't
> > understand your point. In the future where "IPAM has a workflow
> > that
> > covers tenant subnet allocation from a subnet pool shared by the
> > whole
> > deployment" and "the operator [creates] a single global subnet
> > pool",
> > what will prevent a tenant from allocating a very large subnet of
> > that
> > address space?
> >
> >
> >
> > For this specific item - shared subnet pools come with a quota
> > mechanism, which ensure each tenant won't get more than a given share
> > of the pool.
> > This mechanism is still under review [1], we hope to be able to
> > complete the review for the Kilo release.
> >
> > [1] https://review.openstack.org/#/c/165264/
>
> Ah, so the new allocation_quota is an important factor here too.  Many
> thanks for explaining that!
>
> Neil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
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] [cinder]Driver broken

[Eduard Matei]

Thanks,

Indeed, our CI doesn't test this code path, we focused mainly on our
internal functionality tests (which don't test for this), and the tempest
tests are not running.
This will be fixed asap.

Thanks everyone,
Eduard
__
OpenStack Development Mailing 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] Info on Currently Supported Data Drivers

[Janet Yu]

Hi Dani, the Horizon integration is pretty simple to set up manually for
the standalone install. You'd need to copy some files from your congress
directory to your horizon one. Set these two environment variables:

$ CONGRESS_HORIZON_DIR=/path/to/congress/contrib/horizon

$ HORIZON_DIR=/path/to/horizon



Then run the "cp" commands from function _congress_setup_horizon on lines
271 through 276 here, inclusive:

https://github.com/stackforge/congress/blob/master/contrib/devstack/lib/con
gress#L271

And then restart the Apache server. You should now see a Policy section
under the Admin dashboard. As Tim mentioned, the data is currently
view-only in Horizon. I'll be in the Congress IRC channel (#congress)
later if you have questions.

-Original Message-
From: Tim Hinrichs 
Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Date: Wednesday, March 25, 2015 at 8:08 AM
To: "OpenStack Development Mailing List (not for usage questions)"

Subject: Re: [openstack-dev] [Congress] Info on Currently
Supported   DataDrivers

>
>
>
>Hi Dani,
>
>
>We do have an interface in Horizon that you¹ll get if you install via
>devstack (except that you can¹t create rules quite yet‹that¹s under
>active development). If you install it standalone, you won¹t get the
>Horizon interface, but you can still
> use the CLI or the restful API.
>
>
>Let us know if you want help getting it setup.  And if you hit any bumps,
>we¹d love to hear about them so we can smooth them out.
>
>
>Tim
>
>
>
>
>On Mar 25, 2015, at 3:28 AM, Daniel Comnea  wrote:
>
>This project looks very interesting and i might give it a go by
>installing standalone. I have a question though: are there any plans to
>expose the current output as part of Horizon or any other UI ?
>
>
>Thx,
>
>Dani
>
>
>On Wed, Mar 25, 2015 at 5:15 AM, Zhou, Zhenzan
> wrote:
>
>Just found it has been supported, e.g.
> 
>openstack  congress driver schema show ceilometer
> 
>So here is the way to check data source drivers:
> 
>For supported data source drivers:
>1.  
>openstack  congress driver list
>2.  
>openstack  congress driver schema show 
> 
>For enabled data source drivers:
>1.  
>openstack congress datasource list
>2.  
>openstack congress datasource schema show 
> 
>BR
>Zhou Zhenzan
> 
>From: Zhou, Zhenzan [mailto:zhenzan.z...@intel.com]
>
>Sent: Wednesday, March 25, 2015 12:24 PM
>
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data
>Drivers
>
>
>
>
>
> 
>Hi,
> 
>The Œdriver list¹ sub command could provide supported data source
>drivers, but we cannot show its schema if it¹s NOT LOADED. So we still
>have to check
> the code for the schema. My point is that we could support show schemas
>for any supported data source drivers, even it¹s not loaded.
> 
>zhenzan@zhenzan-openstack:~$ openstack congress driver list
>++
>--+
>| id | description
>  |
>++
>--+
>| ceilometer | Datasource driver that interfaces with ceilometer.
>  |
>| plexxi | Datasource driver that interfaces with PlexxiCore.
>  |
>| swift  | Datasource driver that interfaces with swift.
>  |
>| neutronv2  | Datasource driver that interfaces with OpenStack
>Networking aka Neutron. |
>| nova   | Datasource driver that interfaces with OpenStack
>Compute aka nova.   |
>| murano | Datasource driver that interfaces with murano
>  |
>| keystone   | Datasource driver that interfaces with keystone.
>  |
>| cloudfoundryv2 | Datasource driver that interfaces with cloudfoundry
>  |
>| ironic | Datasource driver that interfaces with OpenStack bare
>metal aka ironic.  |
>| cinder | Datasource driver that interfaces with OpenStack
>cinder. |
>| vcenter| Datasource driver that interfaces with vcenter
>  |
>| glancev2   | Datasource driver that interfaces with OpenStack
>Images aka Glance.  |
>++
>--+
>zhenzan@zhenzan-openstack:~$ openstack congress datasource schema show
>ceilometer
>ERROR: openstack Resource ceilometer not found (HTTP 404)
> 
> 
>BR
>Zhou Zhenzan
>From: Pierre-Emmanuel Ettori [mailto:pe.ett...@gmail.com]
>
>Sent: Wednesday, March 25, 2015 11:54 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data
>Drivers
> 
>Hi Zhenzan,
>Actually I believe the command that Tim is looking for is:
>openstack congress datasource list
>
>Please let us know if you are running into any issue.
>
>Thanks
>Pierre
>
> 
>On Tue, Mar 2

Re: [openstack-dev] [Openstack-operators] [Neutron] allow_overlapping_ips

[Neil Jerram]

Salvatore Orlando  writes:

> On 25 March 2015 at 17:36, Neil Jerram 
> wrote:
>
> Kevin Benton  writes:
> 
> > This is a nice option for smaller deployments that didn't need
> the
> > complexity of NAT. From a custom L3 plugin perspective, it also
> > eliminated any single points of failure pretty easily since no
> NAT
> > state had to be distributed.
> >
> > However, it was difficult to use with tenant self-service since
> one
> > tenant could create a subnet that ate up the whole routing
> space. It
> > basically required that the networking was done by an admin or
> that
> > the entire deployment was shared by a group of users trusted to
> do the
> > right thing.
> >
> > My main interest in the IPAM work was to support fully routable
> > deployments like this. Once IPAM has a workflow that covers
> tenant
> > subnet allocation from a subnet pool shared by the whole
> deployment, I
> > think deprecation of the "allow_overlapping_ips" option makes
> perfect
> > sense since the operator can just create a single global subnet
> pool
> > to simulate it.
> 
> I'm not defending allow_overlapping_ips, but I'm afraid I don't
> understand your point. In the future where "IPAM has a workflow
> that
> covers tenant subnet allocation from a subnet pool shared by the
> whole
> deployment" and "the operator [creates] a single global subnet
> pool",
> what will prevent a tenant from allocating a very large subnet of
> that
> address space?
> 
> 
>
> For this specific item - shared subnet pools come with a quota
> mechanism, which ensure each tenant won't get more than a given share
> of the pool.
> This mechanism is still under review [1], we hope to be able to
> complete the review for the Kilo release.
>
> [1] https://review.openstack.org/#/c/165264/

Ah, so the new allocation_quota is an important factor here too.  Many
thanks for explaining that!

Neil


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

Re: [openstack-dev] [Openstack-operators] [Neutron] allow_overlapping_ips (was: Deprecating the use_namespaces option ...)

[Carl Baldwin]

Kevin,

Thank you for your valuable insight here.  Comments inline...

On Wed, Mar 25, 2015 at 10:09 AM, Kevin Benton  wrote:
> This is a nice option for smaller deployments that didn't need the
> complexity of NAT. From a custom L3 plugin perspective, it also eliminated
> any single points of failure pretty easily since no NAT state had to be
> distributed.

Good to know.

> However, it was difficult to use with tenant self-service since one tenant
> could create a subnet that ate up the whole routing space. It basically
> required that the networking was done by an admin or that the entire
> deployment was shared by a group of users trusted to do the right thing.

Sounds like subnet allocation with the associated quota mechanism
would fit the bill here.  In fact, subnet pools were designed with
exactly this kind deployment in mind.  Especially for ipv6.

> My main interest in the IPAM work was to support fully routable deployments
> like this. Once IPAM has a workflow that covers tenant subnet allocation
> from a subnet pool shared by the whole deployment, I think deprecation of
> the "allow_overlapping_ips" option makes perfect sense since the operator
> can just create a single global subnet pool to simulate it.

This is exactly where I was thinking of going with this.  I think Ryan
is going to -- or has already -- made subnet pools mutually exclusive
with the allow_overlapping_ips=False because I didn't even want to
think about making the two modes interoperable.  It sounds like that
might be an acceptable thing to do given this feedback.

Carl

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

Re: [openstack-dev] [tc] Group Based Policy project proposal

[Sumit Naiksatam]

Hi All,

The GBP PTL elections [1] were completed earlier, hence we have
removed the GBP project proposal [2] from WIP (originally posted on
March 5th).

We would request the TC to take note and consider this proposal during
the next meeting. The team will be happy to answer questions and
provide more information via ML, and/or IRC on the #openstack-gbp
channel.

Thanks,
~Sumit, IRC: SumitNaiksatam
(on behalf of GBP-team).

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-March/059317.html
[2] https://review.openstack.org/#/c/161902

On Thu, Mar 5, 2015 at 11:11 PM, Sumit Naiksatam
 wrote:
> Hi All,
>
> The OpenStack Group Based Policy team of contributors has submitted a
> proposal [1] to add “Group Based Policy” as a project in the OpenStack
> namespace in accordance with the new governance changes [2]. We would
> request the TC to take note and consider this proposal during the next
> meeting. The team will be happy to answer questions and provide more
> information via ML, and/or IRC on the #openstack-gbp channel.
>
> Thanks,
> ~Sumit, IRC: SumitNaiksatam
> (on behalf of GBP-team).
>
> [1] https://review.openstack.org/#/c/161902
> [2] http://governance.openstack.org/reference/new-projects-requirements.html

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

Re: [openstack-dev] [Openstack-operators] [Neutron] allow_overlapping_ips

[Salvatore Orlando]

On 25 March 2015 at 17:36, Neil Jerram  wrote:

> Kevin Benton  writes:
>
> > This is a nice option for smaller deployments that didn't need the
> > complexity of NAT. From a custom L3 plugin perspective, it also
> > eliminated any single points of failure pretty easily since no NAT
> > state had to be distributed.
> >
> > However, it was difficult to use with tenant self-service since one
> > tenant could create a subnet that ate up the whole routing space. It
> > basically required that the networking was done by an admin or that
> > the entire deployment was shared by a group of users trusted to do the
> > right thing.
> >
> > My main interest in the IPAM work was to support fully routable
> > deployments like this. Once IPAM has a workflow that covers tenant
> > subnet allocation from a subnet pool shared by the whole deployment, I
> > think deprecation of the "allow_overlapping_ips" option makes perfect
> > sense since the operator can just create a single global subnet pool
> > to simulate it.
>
> I'm not defending allow_overlapping_ips, but I'm afraid I don't
> understand your point.  In the future where "IPAM has a workflow that
> covers tenant subnet allocation from a subnet pool shared by the whole
> deployment" and "the operator [creates] a single global subnet pool",
> what will prevent a tenant from allocating a very large subnet of that
> address space?
>
>
For this specific item - shared subnet pools come with a quota mechanism,
which ensure each tenant won't get more than a given share of the pool.
This mechanism is still under review [1], we hope to be able to complete
the review for the Kilo release.

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


> Thanks,
> Neil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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]Driver broken

[Walter A. Boring IV]

This is a real defect related to the multiattach patch that I worked 
on.   I have posted a fix for your driver.


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

Walt

Hi,

Just reported an issue: https://bugs.launchpad.net/cinder/+bug/1436367
Seems to be related to https://review.openstack.org/#/c/85847/ which 
introduced another parameter to be passed to the driver, but our 
driver didn't get updated so detach_volume fails for us.


How can we get this fixed asap?

Thanks,
Eduard



__
OpenStack Development Mailing 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][Mistral] DSL improvements - certain and incubating

[Dmitri Zimine]

Folks, 

we are discussing DSL improvements, based on Mistral field use and lessons 
learned.

Please join: comment on the document welcome, extra ideas, preferably based on 
your experience writing Mistral workflows. 

The summary is in the doc, it contains two sections:

1) certain improvements, which we have complete clarity, agreed, and just need 
to do
2) incubating: ideas with more or less clear use case, where we however do not 
have a certain, agreed solution.

https://docs.google.com/a/stackstorm.com/document/d/1Gy6V9YBt8W4llyErO_itHetkF1oNYv4ka-_5LdFKA18/edit


Regards, 
Dmitri. __
OpenStack Development Mailing 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-operators] [Neutron] allow_overlapping_ips

[Neil Jerram]

Kevin Benton  writes:

> This is a nice option for smaller deployments that didn't need the
> complexity of NAT. From a custom L3 plugin perspective, it also
> eliminated any single points of failure pretty easily since no NAT
> state had to be distributed. 
>
> However, it was difficult to use with tenant self-service since one
> tenant could create a subnet that ate up the whole routing space. It
> basically required that the networking was done by an admin or that
> the entire deployment was shared by a group of users trusted to do the
> right thing.
>
> My main interest in the IPAM work was to support fully routable
> deployments like this. Once IPAM has a workflow that covers tenant
> subnet allocation from a subnet pool shared by the whole deployment, I
> think deprecation of the "allow_overlapping_ips" option makes perfect
> sense since the operator can just create a single global subnet pool
> to simulate it.

I'm not defending allow_overlapping_ips, but I'm afraid I don't
understand your point.  In the future where "IPAM has a workflow that
covers tenant subnet allocation from a subnet pool shared by the whole
deployment" and "the operator [creates] a single global subnet pool",
what will prevent a tenant from allocating a very large subnet of that
address space?

Thanks,
Neil


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

Re: [openstack-dev] Beyond IRC (was Re: Cinder Third-Party CI: what next?)

[Anita Kuno]

On 03/25/2015 12:14 PM, Kevin L. Mitchell wrote:
> On Tue, 2015-03-24 at 21:21 -0400, Doug Hellmann wrote:
 ·A separate mailing list for project review requests
>>>
>>> I'm skeptical about this being effective: just another source of
>>> incoming email that needs to be filtered out (at which point a mailman
>>> topic would have the same effect).
>>
>> Yes, email notifications scale poorly for really active reviewers.
>> Between gerrit and launchpad, there is already a lot of notification
>> email being filtered out of inboxes.
> 
> I actually do rely on email notifications for review duties.  I use
> filtering that moves the messages into dedicated folders per repository,
> and I use threading in those folders.  When I see a review merge (or
> when I see it abandoned), I select the whole thread and delete it;
> otherwise I follow changes made to a review and determine whether I need
> to re-review it based on whether votes to that point have been +'s or
> -'s.  I even subscribe to a couple of projects and check out new reviews
> submitted there.  This is actually partly to blame for me being such a
> prolific reviewer in nova and novaclient :)
> 
One thing I have learned from my experiences at many mid-cycles is there
is no one size fits all review workflow. I'm glad email works for you.
Others don't read a single email gerrit emits. So advising someone that
their review would get more attention by using email is not necessarily
true. I would get attention from a portion of reviewers and would be
totally ignored by others.

Projects are all different in their workflows and this includes their
review workflows. To understand how any given project prioritizes
reviews one must attend the project weekly meeting, participate in
discussions, ask questions, listen and follow advice given. All projects
genuinely want to help developers succeed. Folks pay more attention to
those wanting to participate when they take the trouble to find out what
currently exists.

Thanks Kevin,
Anita.

__
OpenStack Development Mailing 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] Beyond IRC (was Re: Cinder Third-Party CI: what next?)

[Kevin L. Mitchell]

On Tue, 2015-03-24 at 21:21 -0400, Doug Hellmann wrote:
> > > ·A separate mailing list for project review requests
> > 
> > I'm skeptical about this being effective: just another source of
> > incoming email that needs to be filtered out (at which point a mailman
> > topic would have the same effect).
> 
> Yes, email notifications scale poorly for really active reviewers.
> Between gerrit and launchpad, there is already a lot of notification
> email being filtered out of inboxes.

I actually do rely on email notifications for review duties.  I use
filtering that moves the messages into dedicated folders per repository,
and I use threading in those folders.  When I see a review merge (or
when I see it abandoned), I select the whole thread and delete it;
otherwise I follow changes made to a review and determine whether I need
to re-review it based on whether votes to that point have been +'s or
-'s.  I even subscribe to a couple of projects and check out new reviews
submitted there.  This is actually partly to blame for me being such a
prolific reviewer in nova and novaclient :)
-- 
Kevin L. Mitchell 
Rackspace


__
OpenStack Development Mailing 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]Driver broken

[Eduard Matei]

Hi,

Indeed our CI runs, and it reported SUCCESS, but it didn't run the tempest
tests, only the openvstorage tests (my bad, looking into it as we speak).

Meanwhile i'll create a patch to fix this.

Thanks,
Eduard
__
OpenStack Development Mailing 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-operators] [Neutron] allow_overlapping_ips (was: Deprecating the use_namespaces option ...)

[Kevin Benton]

This is a nice option for smaller deployments that didn't need the
complexity of NAT. From a custom L3 plugin perspective, it also eliminated
any single points of failure pretty easily since no NAT state had to be
distributed.

However, it was difficult to use with tenant self-service since one tenant
could create a subnet that ate up the whole routing space. It basically
required that the networking was done by an admin or that the entire
deployment was shared by a group of users trusted to do the right thing.

My main interest in the IPAM work was to support fully routable deployments
like this. Once IPAM has a workflow that covers tenant subnet allocation
from a subnet pool shared by the whole deployment, I think deprecation of
the "allow_overlapping_ips" option makes perfect sense since the operator
can just create a single global subnet pool to simulate it.

On Wed, Mar 25, 2015 at 8:29 AM, Carl Baldwin  wrote:

> Yesterday, I got looking at another option that I had completely
> forgotten about.  It is "allow_overlapping_ips", set in neutron.conf
> and defaults to False.  It appears that when it is False, Neutron
> doesn't allow any overlapping IPs throughout the deployment, across
> all networks.  My guess is that the vast majority of deployments will
> set this to True as a matter of course.
>
> My suspicion is that this option is related to the use_namespaces
> option because if namespaces are not used, then isolating routing
> domains would not be possible on the network node.  However, there may
> be other reasons for needing this option.
>
> I'm not yet proposing this option be deprecated.  I'm asking for
> feedback from operators and others who might be using the default
> value of False.
>
> Carl
>
> On Tue, Mar 24, 2015 at 1:21 PM, Assaf Muller  wrote:
> > Note that https://review.openstack.org/#/c/166888/ has been merged.
> > This means that the option has been deprecated for K and will be
> > removed in L. Anyone using the non-default value of False will be looking
> > at errors in his logs.
> >
> > - Original Message -
> >>
> >>
> >> On 3/23/2015 3:56 AM, Miguel Ángel Ajo wrote:
> >> > I see you point Van,
> >> >
> >> > In the other hand, removing it, cleans up lot of conditional code
> parts
> >> > (moving parts at the other side),
> >> > and also the non-netns case is not tested by upstream CI, AFAIK, so it
> >> > could be broken anytime
> >> > and we would not notice it.
> >> >
> >> >
> >> >
> >> > Miguel Ángel Ajo
> >> >
> >> > On Monday, 23 de March de 2015 at 9:25, Van Leeuwen, Robert wrote:
> >> >
> >> >>> I think there are valid reasons to not use namespaces:
> >> >>>
> >> >>>   * Fewer moving parts == less can potentialy fail
> >> >>>   * Troubleshooting is easier due to less places to look / need no
> >> >>> familiarity with namespaces & tools
> >> >>>   * If I remember correctly setting up a namespace can get really
> >> >>> slow when you have a lot of them on a single machine
> >> >>>
> >> >>
> >> >> > IMHO, those shouldn’t be valid reasons anymore, since they were due
> >> >> > iproute, or sudo issues
> >> >> > that have been corrected long ago, and all distros installing
> neutron
> >> >> > are supporting netns at this
> >> >>
> >> >> Well, you exactly made my point:
> >> >> There is lots that can and will go wrong with more moving parts.
> >> >> That they are fixed at the moment does not mean that there will not
> be
> >> >> a new bug in the future…
> >> >>
> >> >> Cheers,
> >> >> Robert van Leeuwen
> >> >> ___
> >> >> OpenStack-operators mailing list
> >> >> openstack-operat...@lists.openstack.org
> >> >> 
> >> >>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >> >
> >> >
> >> >
> >> >
> __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >> FWIW we were doing CI without namespaces before Kilo simply due to RHEL
> >> 6.5 not having the support w/o a kernel patch.
> >>
> >> Since Kilo dropped py26 support we moved to RHEL 7* for py27 and that
> >> has namespace support so it's no longer an issue for us.
> >>
> >> --
> >>
> >> Thanks,
> >>
> >> Matt Riedemann
> >>
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject

Re: [openstack-dev] [cinder]Driver broken

[Anita Kuno]

On 03/25/2015 11:44 AM, Jordan Pittier wrote:
> Hey,
> 
> From
> http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9/console.html
> :
> "Running ` python setup.py testr --testr-args='--subunit --concurrency 1
>  test_openvstorage'`"
> 
> ==
> Totals
> ==
> Ran: 10 tests in 2. sec.
>  - Passed: 10
>  - Skipped: 0
>  - Expected Fail: 0
>  - Unexpected Success: 0
>  - Failed: 0
> Sum of execute time for each test: 0.4477 sec.
> 
> 
> So his CI did run :)
> 
> Jordan
Part of the process of running a CI is to be able to answer questions
about your own system.

As a operator of a system maintaining a driver, Eduard, the solution for
fixing your driver is to offer a patch to fix it.

Thanks,
Anita.
> 
> 
> On Wed, Mar 25, 2015 at 4:31 PM, Asselin, Ramy  wrote:
> 
>>  Hi Eduard,
>>
>>
>>
>> Your third party ci reported success on that patch. The tempest volume
>> tests include attached & detaches. Seems your CI is not running them?
>>
>>
>> http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9/console.html
>>
>>
>>
>> *CloudFounders OpenvStorage CI check*
>>
>> *Mar 10, 2015 9:14 AM*
>>
>> openvstorage-cinder-functionality
>> 
>>
>> SUCCESS in 37m 16s
>>
>>
>>
>> Ramy
>>
>>
>>
>> *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
>> *Sent:* Wednesday, March 25, 2015 8:05 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* [openstack-dev] [cinder]Driver broken
>>
>>
>>
>> Hi,
>>
>>
>>
>> Just reported an issue: https://bugs.launchpad.net/cinder/+bug/1436367
>>
>> Seems to be related to https://review.openstack.org/#/c/85847/ which
>> introduced another parameter to be passed to the driver, but our driver
>> didn't get updated so detach_volume fails for us.
>>
>>
>>
>> How can we get this fixed asap?
>>
>>
>>
>> Thanks,
>>
>> Eduard
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware )

[Anita Kuno]

On 03/25/2015 11:18 AM, Jordan Pittier wrote:
> On Wed, Mar 25, 2015 at 2:44 PM, Salvatore Orlando 
> wrote:
> 
>>
>>
>> On 25 March 2015 at 14:21, Sean Dague  wrote:
>>
>>> On 03/25/2015 09:03 AM, Gary Kotton wrote:

 From: Jordan Pittier >>> >
 Reply-To: OpenStack List >>> >
 Date: Wednesday, March 25, 2015 at 1:47 PM
 To: OpenStack List >>> >
 Subject: Re: [openstack-dev] [nova] CI report formatting (citrix /
 hyperv / vmware )

 Hi
 On Wed, Mar 25, 2015 at 12:39 PM, Sean Dague >>> > wrote:

 Currently Citrix, HyperV, and VMWare CI systems reporting on Nova
 patches have a different formatting than the standard that Jenkins
>>> and
 other systems are using:

 * test-name-no-spaces http://link.to/result
 <
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__link.to_result&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiE&s=5SS-txUrD3o8KS3QIaCL3XMBbeCYK5CjmzmuxDda7Oc&e=

 : [SUCCESS|FAILURE] some
 comment about the test

 I don't want to talk for Citrix, HyperV or VMWare but the "standard"
 only work if you use Zuul in your CI. I am using a setup based on a
 Jenkins plugin called gerrit-trigger and there's no way to format the
 message the way it's expected...
>>>
>>
>> FWIW I help maintain one the VMware CIs (the one voting on neutron and
>> network-related patches for devstack and tempest).
>> We use gerrit-trigger too (mostly out of lazyness, no other real reason),
>> but we're able to format the message posted back to gerrit.
>> For posting back votes we use the "gerrit review" command to post the
>> message in the standard format.
>>
> Ok. I managed to find a way. It's possible. For future reference, on the
> job configuration, there's a field called "URL to post". The correct value
> is literally "* $JOB_NAME $BUILD_URL". Sorry for the noise guys. I can't
> find myself an excuse not to report results in the expected format anymore.
Thank you, Jordan. Are you able to update the documentation consumed by
third party folk using the Jenkins Gerrit trigger plugin?
http://ci.openstack.org/third_party.html#the-jenkins-gerrit-trigger-plugin-way

http://git.openstack.org/cgit/openstack-infra/system-config/tree/doc/source/third_party.rst#n212

Since I seem to be the only one doing anything by way of turning systems
off and having them turned back on again, I would really be grateful in
future of any conversation that doesn't include adding more
responsibilities to my list. I'm understanding of the reasoning that
unless threatened with being disabled most systems won't take any
conversation about their behaviour seriously but I really am at my limit
of what I can accomplish here. My list is very heavy as it is, I'm not
in favour of adding more to it.

Thanks for taking my perspective into consideration,
Anita.
> 
>> I think the same process is adopted also by the CI voting on nova.
>> However, the job result string is not being posted. I will double check
>> with the respective owners.
>>
>> Salvatore
>>
>>


 This means these systems don't show up in the CI rollup block -
 http://dl.dropbox.com/u/6514884/screenshot_158.png
 <
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__dl.dropbox.com_u_6514884_screenshot-5F158.png&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiE&s=nIjYwznh1_8aVBSz-XVEJrpNaMsDfqyekOQ2IhiHTo8&e=



 Current the Vmware CI will vote +1 iff the patch has passed on the CI.
 We can investigate adding this to the CI rollup block.



 I'd really like that to change. The CI rollup block has been
>>> extremely
 useful in getting the test results of a patch above the fold, and
>>> the
 ability to dig into them clearly. I feel like if any CI system isn't
 reporting in standard format that's parsible by that, we should
>>> probably
 turn it off.


 I do not think that we should turn this off. They have value. It would
 be nice if things were all of the same format, which I guess that this
 is the intension of the mail. Lets all try and make an effort to work
 towards this goal.
>>>
>>> Right, honestly, I don't want these turned off, I want them reporting in
>>> a more standard format. But I do think if they don't report in a
>>> standard format it will cause problems and add to them being ignored.
>>>
>>> -Sean
>>>
>>> --
>>> Sean Dague
>>> http://dague.net
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage quest

Re: [openstack-dev] [os-ansible-deployment] Nominating Nolan Brubaker for core team

[Ian Cordasco]

+1

On 3/25/15, 10:36, "Hugh Saunders"  wrote:

>Great proposal, Nolan will be an asset to the core team.
>
>
>+1
>
>--
>Hugh Saunders
>
>
>
>On 25 March 2015 at 15:24, Kevin Carter
> wrote:
>
>Greetings,
>
>I would like to nominate Nolan Brubaker (palendae on IRC) for the
>os-ansible-deployment-core team. Nolan has been involved with the project
>for the last few months and has been an active reviewer with solid
>reviews. IMHO, I think he is ready to receive core
> powers on the repository.
>
>References:
>  [ 
>https://review.openstack.org/#/q/project:stackforge/os-ansible-deployment+
>reviewer:%22nolan+brubaker%253Cnolan.brubaker%2540rackspace.com%253E%22,n,
>z 
>+reviewer:%22nolan+brubaker%253Cnolan.brubaker%2540rackspace.com%253E%22,n
>,z> ]
>
>Please respond with +1/-1s or any other concerns.
>
>As a reminder, we are using the voting process outlined at [
>https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> ] to
>add members to our core team.
>
>—
>
>Kevin Carter
>
>__
>OpenStack Development Mailing 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]Driver broken

[Jordan Pittier]

Hey,

From
http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9/console.html
:
"Running ` python setup.py testr --testr-args='--subunit --concurrency 1
 test_openvstorage'`"

==
Totals
==
Ran: 10 tests in 2. sec.
 - Passed: 10
 - Skipped: 0
 - Expected Fail: 0
 - Unexpected Success: 0
 - Failed: 0
Sum of execute time for each test: 0.4477 sec.


So his CI did run :)

Jordan


On Wed, Mar 25, 2015 at 4:31 PM, Asselin, Ramy  wrote:

>  Hi Eduard,
>
>
>
> Your third party ci reported success on that patch. The tempest volume
> tests include attached & detaches. Seems your CI is not running them?
>
>
> http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9/console.html
>
>
>
> *CloudFounders OpenvStorage CI check*
>
> *Mar 10, 2015 9:14 AM*
>
> openvstorage-cinder-functionality
> 
>
> SUCCESS in 37m 16s
>
>
>
> Ramy
>
>
>
> *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
> *Sent:* Wednesday, March 25, 2015 8:05 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [cinder]Driver broken
>
>
>
> Hi,
>
>
>
> Just reported an issue: https://bugs.launchpad.net/cinder/+bug/1436367
>
> Seems to be related to https://review.openstack.org/#/c/85847/ which
> introduced another parameter to be passed to the driver, but our driver
> didn't get updated so detach_volume fails for us.
>
>
>
> How can we get this fixed asap?
>
>
>
> Thanks,
>
> Eduard
>
>
>
> __
> OpenStack Development Mailing 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] [os-ansible-deployment] Nominating Nolan Brubaker for core team

[Hugh Saunders]

Great proposal, Nolan will be an asset to the core team.

+1

--
Hugh Saunders

On 25 March 2015 at 15:24, Kevin Carter  wrote:

> Greetings,
>
> I would like to nominate Nolan Brubaker (palendae on IRC) for the
> os-ansible-deployment-core team. Nolan has been involved with the project
> for the last few months and has been an active reviewer with solid reviews.
> IMHO, I think he is ready to receive core powers on the repository.
>
> References:
>   [
> https://review.openstack.org/#/q/project:stackforge/os-ansible-deployment+reviewer:%22nolan+brubaker%253Cnolan.brubaker%2540rackspace.com%253E%22,n,z
> ]
>
> Please respond with +1/-1s or any other concerns.
>
> As a reminder, we are using the voting process outlined at [
> https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess ] to
> add members to our core team.
>
> —
>
> Kevin Carter
>
> __
> OpenStack Development Mailing 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]Driver broken

[Asselin, Ramy]

Hi Eduard,

Your third party ci reported success on that patch. The tempest volume tests 
include attached & detaches. Seems your CI is not running them?
http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9/console.html

CloudFounders OpenvStorage CI check

Mar 10, 2015 9:14 AM

openvstorage-cinder-functionality

SUCCESS in 37m 16s


Ramy

From: Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
Sent: Wednesday, March 25, 2015 8:05 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [cinder]Driver broken

Hi,

Just reported an issue: https://bugs.launchpad.net/cinder/+bug/1436367
Seems to be related to https://review.openstack.org/#/c/85847/ which introduced 
another parameter to be passed to the driver, but our driver didn't get updated 
so detach_volume fails for us.

How can we get this fixed asap?

Thanks,
Eduard

__
OpenStack Development Mailing 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-operators] [Neutron] allow_overlapping_ips (was: Deprecating the use_namespaces option ...)

[Carl Baldwin]

Yesterday, I got looking at another option that I had completely
forgotten about.  It is "allow_overlapping_ips", set in neutron.conf
and defaults to False.  It appears that when it is False, Neutron
doesn't allow any overlapping IPs throughout the deployment, across
all networks.  My guess is that the vast majority of deployments will
set this to True as a matter of course.

My suspicion is that this option is related to the use_namespaces
option because if namespaces are not used, then isolating routing
domains would not be possible on the network node.  However, there may
be other reasons for needing this option.

I'm not yet proposing this option be deprecated.  I'm asking for
feedback from operators and others who might be using the default
value of False.

Carl

On Tue, Mar 24, 2015 at 1:21 PM, Assaf Muller  wrote:
> Note that https://review.openstack.org/#/c/166888/ has been merged.
> This means that the option has been deprecated for K and will be
> removed in L. Anyone using the non-default value of False will be looking
> at errors in his logs.
>
> - Original Message -
>>
>>
>> On 3/23/2015 3:56 AM, Miguel Ángel Ajo wrote:
>> > I see you point Van,
>> >
>> > In the other hand, removing it, cleans up lot of conditional code parts
>> > (moving parts at the other side),
>> > and also the non-netns case is not tested by upstream CI, AFAIK, so it
>> > could be broken anytime
>> > and we would not notice it.
>> >
>> >
>> >
>> > Miguel Ángel Ajo
>> >
>> > On Monday, 23 de March de 2015 at 9:25, Van Leeuwen, Robert wrote:
>> >
>> >>> I think there are valid reasons to not use namespaces:
>> >>>
>> >>>   * Fewer moving parts == less can potentialy fail
>> >>>   * Troubleshooting is easier due to less places to look / need no
>> >>> familiarity with namespaces & tools
>> >>>   * If I remember correctly setting up a namespace can get really
>> >>> slow when you have a lot of them on a single machine
>> >>>
>> >>
>> >> > IMHO, those shouldn’t be valid reasons anymore, since they were due
>> >> > iproute, or sudo issues
>> >> > that have been corrected long ago, and all distros installing neutron
>> >> > are supporting netns at this
>> >>
>> >> Well, you exactly made my point:
>> >> There is lots that can and will go wrong with more moving parts.
>> >> That they are fixed at the moment does not mean that there will not be
>> >> a new bug in the future…
>> >>
>> >> Cheers,
>> >> Robert van Leeuwen
>> >> ___
>> >> OpenStack-operators mailing list
>> >> openstack-operat...@lists.openstack.org
>> >> 
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> >
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> FWIW we were doing CI without namespaces before Kilo simply due to RHEL
>> 6.5 not having the support w/o a kernel patch.
>>
>> Since Kilo dropped py26 support we moved to RHEL 7* for py27 and that
>> has namespace support so it's no longer an issue for us.
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] [barbican] Using KMIP with Barbican (Utkarsh Simha)

[Farr, Kaitlin M.]

Hi Utkarsh,

Specifying "kmip_plugin" in the barbican-api.conf is the correct way to
configure the plugin. In my previous debugging experience, I've found that I
get CryptoPluginNotFound if an error occurred during the plugin's __init__
method. For the KMIP plugin, this means the key file permissions were not
set to 400 or the PyKMIP KMIPProxy object could not be created with the
configuration options set. To debug this further, we'll need to log at the
logs for more clues.

Hope this helps!

Kaitlin Farr
Johns Hopkins University Applied Physics Laboratory


--

Date: Mon, 23 Mar 2015 16:56:43 +0530
From: Utkarsh Simha 
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [barbican] Using KMIP with Barbican
Message-ID:

Content-Type: text/plain; charset=UTF-8

Hello!

I was wondering how it is possible to use an external Key Management
Server with Barbican? I have configured the barbican-api.conf file for
the KMIP Plugin and also set "enabled_crypto_plugins" to
"kmip_plugin", but it says "CryptoPluginNotFound"

Any help is appreciated! Thank you :)

--
Regards



--

*

__
OpenStack Development Mailing 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] [os-ansible-deployment] Nominating Nolan Brubaker for core team

[Kevin Carter]

Greetings,

I would like to nominate Nolan Brubaker (palendae on IRC) for the 
os-ansible-deployment-core team. Nolan has been involved with the project for 
the last few months and has been an active reviewer with solid reviews. IMHO, I 
think he is ready to receive core powers on the repository.

References:
  [ 
https://review.openstack.org/#/q/project:stackforge/os-ansible-deployment+reviewer:%22nolan+brubaker%253Cnolan.brubaker%2540rackspace.com%253E%22,n,z
 ]

Please respond with +1/-1s or any other concerns.

As a reminder, we are using the voting process outlined at [ 
https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess ] to add 
members to our core team.

—

Kevin Carter

__
OpenStack Development Mailing 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] How to do once off/infrequent meetings?

[Bailey, Darragh]

I was looking at using the meetings service
(https://wiki.openstack.org/wiki/Meetings) to run and log a meeting on a
stackforge project (git-upstream -
http://git.openstack.org/cgit/stackforge/git-upstream), which seems to
focus on reoccurring meetings.

So I'm wondering how best to register an adhoc meeting, I'm sure there
may be others in the future, but the project isn't at the point where it
would be useful to run a regular meeting.


I'm happy enough to just run this through the standard IRC channel in
this case, but I figured it might be better if I found out if it was
possible to use the meetings service?


btw, if anyone is interested in the project git-upstream the
discussion/meeting is happening tomorrow in the #git-upstream IRC
channel @5pm UTC.

-- 
Regards,
Darragh Bailey

Systems Software Engineer
Hewlett Packard Galway Ltd.
+353 91 75-4674

Postal Address:Hewlett Packard Galway Limited, Ballybrit Business Park, 
Galway 
Registered Office: Hewlett Packard Galway Limited, 63-74 Sir John Rogerson's 
Quay Dublin 2
Registered Number: 361933

___
The contents of this message and any attachments to it are confidential and may 
be legally privileged. If you have received this message in error you should 
delete it from your system immediately and advise the sender.
To any recipient of this message within HP, unless otherwise stated you should 
consider this message and attachments as "HP CONFIDENTIAL".




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

Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware )

[Jordan Pittier]

On Wed, Mar 25, 2015 at 2:44 PM, Salvatore Orlando 
wrote:

>
>
> On 25 March 2015 at 14:21, Sean Dague  wrote:
>
>> On 03/25/2015 09:03 AM, Gary Kotton wrote:
>> >
>> > From: Jordan Pittier > > >
>> > Reply-To: OpenStack List > > >
>> > Date: Wednesday, March 25, 2015 at 1:47 PM
>> > To: OpenStack List > > >
>> > Subject: Re: [openstack-dev] [nova] CI report formatting (citrix /
>> > hyperv / vmware )
>> >
>> > Hi
>> > On Wed, Mar 25, 2015 at 12:39 PM, Sean Dague > > > wrote:
>> >
>> > Currently Citrix, HyperV, and VMWare CI systems reporting on Nova
>> > patches have a different formatting than the standard that Jenkins
>> and
>> > other systems are using:
>> >
>> > * test-name-no-spaces http://link.to/result
>> > <
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__link.to_result&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiE&s=5SS-txUrD3o8KS3QIaCL3XMBbeCYK5CjmzmuxDda7Oc&e=
>> >
>> > : [SUCCESS|FAILURE] some
>> > comment about the test
>> >
>> > I don't want to talk for Citrix, HyperV or VMWare but the "standard"
>> > only work if you use Zuul in your CI. I am using a setup based on a
>> > Jenkins plugin called gerrit-trigger and there's no way to format the
>> > message the way it's expected...
>>
>
> FWIW I help maintain one the VMware CIs (the one voting on neutron and
> network-related patches for devstack and tempest).
> We use gerrit-trigger too (mostly out of lazyness, no other real reason),
> but we're able to format the message posted back to gerrit.
> For posting back votes we use the "gerrit review" command to post the
> message in the standard format.
>
> Ok. I managed to find a way. It's possible. For future reference, on the
job configuration, there's a field called "URL to post". The correct value
is literally "* $JOB_NAME $BUILD_URL". Sorry for the noise guys. I can't
find myself an excuse not to report results in the expected format anymore.

> I think the same process is adopted also by the CI voting on nova.
> However, the job result string is not being posted. I will double check
> with the respective owners.
>
> Salvatore
>
>
>> >
>> >
>> > This means these systems don't show up in the CI rollup block -
>> > http://dl.dropbox.com/u/6514884/screenshot_158.png
>> > <
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__dl.dropbox.com_u_6514884_screenshot-5F158.png&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiE&s=nIjYwznh1_8aVBSz-XVEJrpNaMsDfqyekOQ2IhiHTo8&e=
>> >
>> >
>> >
>> > Current the Vmware CI will vote +1 iff the patch has passed on the CI.
>> > We can investigate adding this to the CI rollup block.
>> >
>> >
>> >
>> > I'd really like that to change. The CI rollup block has been
>> extremely
>> > useful in getting the test results of a patch above the fold, and
>> the
>> > ability to dig into them clearly. I feel like if any CI system isn't
>> > reporting in standard format that's parsible by that, we should
>> probably
>> > turn it off.
>> >
>> >
>> > I do not think that we should turn this off. They have value. It would
>> > be nice if things were all of the same format, which I guess that this
>> > is the intension of the mail. Lets all try and make an effort to work
>> > towards this goal.
>>
>> Right, honestly, I don't want these turned off, I want them reporting in
>> a more standard format. But I do think if they don't report in a
>> standard format it will cause problems and add to them being ignored.
>>
>> -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
>>
>>
>
> __
> OpenStack Development Mailing 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] [Congress] Info on Currently Supported Data Drivers

[Tim Hinrichs]

Hi Dani,

We do have an interface in Horizon that you’ll get if you install via devstack 
(except that you can’t create rules quite yet—that’s under active development). 
If you install it standalone, you won’t get the Horizon interface, but you can 
still use the CLI or the restful API.

Let us know if you want help getting it setup.  And if you hit any bumps, we’d 
love to hear about them so we can smooth them out.

Tim


On Mar 25, 2015, at 3:28 AM, Daniel Comnea 
mailto:comnea.d...@gmail.com>> wrote:

This project looks very interesting and i might give it a go by installing 
standalone. I have a question though: are there any plans to expose the current 
output as part of Horizon or any other UI ?

Thx,
Dani

On Wed, Mar 25, 2015 at 5:15 AM, Zhou, Zhenzan 
mailto:zhenzan.z...@intel.com>> wrote:
Just found it has been supported, e.g.

openstack  congress driver schema show ceilometer

So here is the way to check data source drivers:

For supported data source drivers:

1.   openstack  congress driver list

2.   openstack  congress driver schema show 

For enabled data source drivers:

1.   openstack congress datasource list

2.   openstack congress datasource schema show 

BR
Zhou Zhenzan

From: Zhou, Zhenzan 
[mailto:zhenzan.z...@intel.com]
Sent: Wednesday, March 25, 2015 12:24 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers


Hi,

The ‘driver list’ sub command could provide supported data source drivers, but 
we cannot show its schema if it’s NOT LOADED. So we still have to check the 
code for the schema. My point is that we could support show schemas for any 
supported data source drivers, even it’s not loaded.

zhenzan@zhenzan-openstack:~$ openstack congress driver list
++--+
| id | description  
|
++--+
| ceilometer | Datasource driver that interfaces with ceilometer.   
|
| plexxi | Datasource driver that interfaces with PlexxiCore.   
|
| swift  | Datasource driver that interfaces with swift.
|
| neutronv2  | Datasource driver that interfaces with OpenStack Networking 
aka Neutron. |
| nova   | Datasource driver that interfaces with OpenStack Compute aka 
nova.   |
| murano | Datasource driver that interfaces with murano
|
| keystone   | Datasource driver that interfaces with keystone. 
|
| cloudfoundryv2 | Datasource driver that interfaces with cloudfoundry  
|
| ironic | Datasource driver that interfaces with OpenStack bare metal 
aka ironic.  |
| cinder | Datasource driver that interfaces with OpenStack cinder. 
|
| vcenter| Datasource driver that interfaces with vcenter   
|
| glancev2   | Datasource driver that interfaces with OpenStack Images aka 
Glance.  |
++--+
zhenzan@zhenzan-openstack:~$ openstack congress datasource schema show 
ceilometer
ERROR: openstack Resource ceilometer not found (HTTP 404)


BR
Zhou Zhenzan
From: Pierre-Emmanuel Ettori [mailto:pe.ett...@gmail.com]
Sent: Wednesday, March 25, 2015 11:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

Hi Zhenzan,
Actually I believe the command that Tim is looking for is:
openstack congress datasource list

Please let us know if you are running into any issue.

Thanks
Pierre

On Tue, Mar 24, 2015 at 8:39 PM Tim Hinrichs 
mailto:thinri...@vmware.com>> wrote:

Hi Zhenzan,



I don't have the CLI in front of me, but check out the 'driver' commands.  The 
command you're looking for is something like the following.



$ openstack congress driver list



Tim




From: Zhou, Zhenzan mailto:zhenzan.z...@intel.com>>
Sent: Tuesday, March 24, 2015 7:39 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers
Hi,

To check LOADED(or ENABLED) data source drivers for a running system, you can 
use congress cli. Maybe we could add a command to list SUPPORTED data source 
drivers?

zhenzan@zhenzan-openstack:~$ openstack congress datasource list
+--+---+-+--+-+
| id   | name  | enab

[openstack-dev] [cinder]Driver broken

[Eduard Matei]

Hi,

Just reported an issue: https://bugs.launchpad.net/cinder/+bug/1436367
Seems to be related to https://review.openstack.org/#/c/85847/ which
introduced another parameter to be passed to the driver, but our driver
didn't get updated so detach_volume fails for us.

How can we get this fixed asap?

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

Re: [openstack-dev] [OpenStack-Infra] [cinder] Status of Huawei Volume CI

[Asselin, Ramy]

I checked 3 random ones and I couldn't see any log files.

Ramy

https://review.openstack.org/#/c/144409/
Patch Set 6: Build succeeded. - huawei-iscsi-dsvm-tempest-full ...

Mar 1 11:54 PM


http://125.70.13.170:8088/huawei-iscsi-dsvm-tempest-full/357  Not found
http://125.70.13.170:8088/huawei-fc-dsvm-tempest-full/26 Not found
Both links fail to show any logs

https://review.openstack.org/#/c/164692/
Huawei Volume CI check

Mar 22, 2015 1:37 PM

huawei-iscsi-dsvm-tempest-full

FAILURE in 12m 54s

huawei-fc-dsvm-tempest-full

FAILURE in 11m 03s


Both links fail to show any logs

https://review.openstack.org/#/c/167080/
Huawei Volume CI check

Mar 24, 2015 6:47 AM

huawei-iscsi-dsvm-tempest-full

UNSTABLE in 15m 32s

huawei-fc-dsvm-tempest-full

SUCCESS in 17m 09s


Both links fail to show any logs

From: liuxinguo [mailto:liuxin...@huawei.com]
Sent: Wednesday, March 25, 2015 5:45 AM
To: OpenStack Development Mailing List (not for usage questions); 
openstack-in...@lists.openstack.org
Cc: Fanyaohong
Subject: [openstack-dev] [OpenStack-Infra] [cinder] Status of Huawei Volume CI

Hello Cinder team,

*Huawei Volume CI has been reporting since December 20 
th 2014. Now it runs
*two tempest jobs for Huawei 18000 iSCSI driver and Huawei 18000 FC 
driver.
*Considering that our drivers have been moved for the upstream, I have 
added some
*code to ensure the jobs run against the real storage 
backend when building devstack.
*
*And now the CI is reporting much more stably and will keep running and 
reporting from now on.
*Below is a link shows the recently posted results 
from the CI:

https://review.openstack.org/#/q/reviewer:%22Huawei+Volume+CI%22,n,z

I kindly request that you accept our CI result and consider re-integrating
our 18000 iSCSI and 18000 FC drivers back in Kilo RC.

If there is any concern, please let us know.

Thanks and regards,
Liu


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

[openstack-dev] [release] oslo.messaging 1.9.0

[Doug Hellmann]

We are content to announce the release of:

oslo.messaging 1.9.0: Oslo Messaging API

This is the first release of the library for the Liberty development cycle.

For more details, please see the git log history below and:

http://launchpad.net/oslo.messaging/+milestone/1.9.0

Please report issues through launchpad:

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

Changes in oslo.messaging 1.8.0..1.9.0
--

8da14f6 Use the oslo_utils stop watch in decaying timer
ec1fb8c Updated from global requirements
84c0d3a Remove 'UNIQUE_ID is %s' logging
9f13794 rabbit: fix ipv6 support
3f967ef Create a unique transport for each server in the functional tests
23dfb6e Publish tracebacks only on debug level
53fde06 Add pluggability for matchmakers
b92ea91 Make option [DEFAULT]amqp_durable_queues work
cc618a4 Reconnect on connection lost in heartbeat thread
f00ec93 Imported Translations from Transifex
0dff20b cleanup connection pool return
2d1a019 rabbit: Improves logging
0ec536b fix up verb tense in log message
b9e134d rabbit: heartbeat implementation
72a9984 Fix changing keys during iteration in matchmaker heartbeat
cf365fe Minor improvement
5f875c0 ZeroMQ deployment guide
410d8f0 Fix a couple typos to make it easier to read.
3aa565b Tiny problem with notify-server in simulator
0f87f5c Fix coverage report generation
3be95ad Add support for multiple namespaces in Targets
513ce80 tools: add simulator script
0124756 Deprecates the localcontext API
ce7d5e8 Update to oslo.context
eaa362b Remove obsolete cross tests script
1958f6e Fix the bug redis do not delete the expired keys
9f457b4 Properly distinguish between server index zero and no server
0006448 Adjust tests for the new namespace

Diffstat (except docs and test files)
-

.coveragerc|   7 +
openstack-common.conf  |   6 +-
.../locale/de/LC_MESSAGES/oslo.messaging.po|  48 ++-
.../locale/en_GB/LC_MESSAGES/oslo.messaging.po |  48 ++-
.../locale/fr/LC_MESSAGES/oslo.messaging.po|  40 ++-
oslo.messaging/locale/oslo.messaging.pot   |  50 ++-
oslo_messaging/_drivers/amqp.py|  55 +++-
oslo_messaging/_drivers/amqpdriver.py  |  15 +-
oslo_messaging/_drivers/common.py  |  20 +-
oslo_messaging/_drivers/impl_qpid.py   |   4 +-
oslo_messaging/_drivers/impl_rabbit.py | 357 ++---
oslo_messaging/_drivers/impl_zmq.py|  32 +-
oslo_messaging/_drivers/matchmaker.py  |   2 +-
oslo_messaging/_drivers/matchmaker_redis.py|   7 +-
oslo_messaging/localcontext.py |  16 +
oslo_messaging/notify/dispatcher.py|   4 +-
oslo_messaging/notify/middleware.py|   2 +-
oslo_messaging/openstack/common/_i18n.py   |  45 +++
oslo_messaging/openstack/common/versionutils.py| 253 +++
oslo_messaging/rpc/dispatcher.py   |   6 +-
oslo_messaging/target.py   |   9 +-
requirements-py3.txt   |  13 +-
requirements.txt   |  15 +-
setup.cfg  |   6 +
test-requirements-py3.txt  |   4 +-
test-requirements.txt  |   4 +-
tools/simulator.py | 207 
tox.ini|   3 +-
43 files changed, 1673 insertions(+), 512 deletions(-)


Requirements updates


diff --git a/requirements-py3.txt b/requirements-py3.txt
index 05cb050..4ec18c6 100644
--- a/requirements-py3.txt
+++ b/requirements-py3.txt
@@ -5,5 +5,6 @@
-oslo.config>=1.9.0  # Apache-2.0
-oslo.serialization>=1.2.0   # Apache-2.0
-oslo.utils>=1.2.0   # Apache-2.0
-oslo.i18n>=1.3.0  # Apache-2.0
-stevedore>=1.1.0  # Apache-2.0
+oslo.config>=1.9.3,<1.10.0  # Apache-2.0
+oslo.context>=0.2.0,<0.3.0 # Apache-2.0
+oslo.serialization>=1.4.0,<1.5.0   # Apache-2.0
+oslo.utils>=1.4.0,<1.5.0   # Apache-2.0
+oslo.i18n>=1.5.0,<1.6.0  # Apache-2.0
+stevedore>=1.3.0,<1.4.0  # Apache-2.0
@@ -21 +22 @@ kombu>=2.5.0
-oslo.middleware>=0.3.0  # Apache-2.0
+oslo.middleware>=1.0.0,<1.1.0  # Apache-2.0
diff --git a/requirements.txt b/requirements.txt
index 3b49a53..ec5fef6 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7,5 +7,6 @@ pbr>=0.6,!=0.7,<1.0
-oslo.config>=1.9.0  # Apache-2.0
-oslo.utils>=1.2.0   # Apache-2.0
-oslo.serialization>=1.2.0   # Apache-2.0
-oslo.i18n>=1.3.0  # Apache-2.0
-stevedore>=1.1.0  # Apache-2.0
+oslo.config>=1.9.3,<1.10.0  # Apache-2.0
+oslo.context>=0.2.0,<0.3.0 # Apache-2.0
+oslo.utils>=1.4.0,<1.5.0   # Apache-2.0
+oslo.serialization>

Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin

[Deepak Shetty]

On Wed, Mar 25, 2015 at 7:30 PM, Dean Troyer  wrote:

> I wasn't clear, let me try again:
>
>   CINDER_ENABLED_BACKENDS=";"
>
> set the value to the separator character semi-colon.  That evaluates to
> not-empty for the shell :- but has no entries so is still effectively null
> for the cinder config code.
>


Ah, i didn't notice the semi-colon :)
I guess this should work, so #1 (per sean's suggested options) seems to be
the way to go for now

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

[openstack-dev] [release] oslo.messaging 1.8.1

[Doug Hellmann]

We are pleased to announce the release of:

oslo.messaging 1.8.1: Oslo Messaging API

This is a Kilo-series patch release, fixing several bugs.

For more details, please see the git log history below and:

http://launchpad.net/oslo.messaging/+milestone/1.8.1

Please report issues through launchpad:

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

Changes in oslo.messaging 1.8.0..1.8.1
--

57fad97 Publish tracebacks only on debug level
b5f91b2 Reconnect on connection lost in heartbeat thread
ac8bdb6 cleanup connection pool return
ee18dc5 rabbit: Improves logging
db99154 fix up verb tense in log message
64bdd80 rabbit: heartbeat implementation
9b14d1a Add support for multiple namespaces in Targets

Diffstat (except docs and test files)
-

oslo_messaging/_drivers/amqp.py  |  44 ++-
oslo_messaging/_drivers/amqpdriver.py|  15 +-
oslo_messaging/_drivers/impl_qpid.py |   2 +-
oslo_messaging/_drivers/impl_rabbit.py   | 346 ---
oslo_messaging/rpc/dispatcher.py |   2 +-
oslo_messaging/target.py |   9 +-
11 files changed, 541 insertions(+), 70 deletions(-)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] VLAN trunking network for NFV

[Ian Wells]

Today:

You need to ensure that your cloud is using a suitable networking config -
with ML2, use Linuxbridge and either VXLAN or GRE.  If you're using either
OVS or VLAN you won't get a trunking network.  A tenant can't tell this, so
they can't easily tell that all or any networks are VLAN trunks without
testing the network.

Tomorrow (i.e. on trunk, or when Kilo is released):

You can use the vlan_transparent flag on a network to explicitly request a
trunk.  The dataplane code hasn't changed, so the cloud will report that
the network is a trunk if you're using ML2 with Linuxbridge and GRE or
VXLAN, and will report you can't have a trunk if you use OVS or VLAN.  This
means that you are no more likely to get a trunk if you ask for one - you
still need a suitable configuration - but your application will immediately
know if it works or not (the old alternative was pretty much to start it
and see if it works, which wasn't helpful).

ML2 now has a reference implementation of this; other plugins (to the best
of my knowledge) don't support the flag.  When they do, then any plugin or
driver can theoretically be written to behave differently if you have ask
for a trunk; for instance, in the future we can change the code to program
OVS differently if you want a trunk, or change ML2 to use a trunk-safe
VXLAN overlay even though VLAN networks are also available in a system.  No
driver does this today.
-- 
Ian.

On 24 March 2015 at 17:48, Guo, Ruijing  wrote:

>  I am trying to understand how guest os use trunking network.
>
>
>
> If guest os use bridge like Linuxbride and OVS, how we launch it and how
> libvirt to support it?
>
>
>
> Thanks,
>
> -Ruijing
>
>
>
>
>
> *From:* Ian Wells [mailto:ijw.ubu...@cack.org.uk]
> *Sent:* Wednesday, March 25, 2015 2:18 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron] VLAN trunking network for NFV
>
>
>
> That spec ensures that you can tell what the plugin is doing.  You can ask
> for a VLAN transparent network, but the cloud may tell you it can't make
> one.
>
> The OVS driver in Openstack drops VLAN tagged packets, I'm afraid, and the
> spec you're referring to doesn't change that.  The spec does ensure that if
> you try and create a VLAN trunk on a cloud that uses the OVS driver, you'll
> be told you can't.  in the future, the OVS driver can be fixed, but that's
> how things stand at present.  Fixing the OVS driver really involves getting
> in at the OVS flow level - can be done, but we started with the basics.
>
> If you want to use a VLAN trunk using the current code, I recommend VXLAN
> or GRE along with the Linuxbridge driver, both of which support VLAN
> transparent networking.  If they're configured and you ask for a VLAN trunk
> you'll be told you got one.
> --
>
> Ian.
>
>
>
>
>
> On 24 March 2015 at 09:43, Daniele Casini 
> wrote:
>
> Hi all:
>
> in reference to the following specification about the creation of VLAN
> trunking network for NFV
>
> https://review.openstack.org/#/c/136554/3/specs/kilo/nfv-vlan-trunks.rst
>
> I would like to better understand how the tagged traffic will be realized.
> In order to explain myself, I report the following use case:
>
> A VNF is deployed in one VM, which has a trunk port carrying traffic for
> two VLANs over a single link able to transport more than one VLAN through a
> single integration-bridge (br-int) port. So, How does br-int manage the
> VLAN-ID? In other words, what are the action performed by the br-int when a
> VM forwards traffic to another host?
> Does it put an additional tag or replace the existing one keeping the
> match with a table or something like that?
>
> Thank you very much.
>
> Daniele
>
>
> __
> OpenStack Development Mailing 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] [kolla] Re: Why we didn't use k8s in kolla?

[Steven Dake (stdake)]

From: Chmouel Boudjnah mailto:chmo...@chmouel.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, March 25, 2015 at 5:36 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla] Re: Why we didn't use k8s in kolla?

Hello,

So if I understand correctly Kubernetes was avoided since there is no control 
point and using fig/docker-compose would get you a top to the bottom deployment 
that easy to control.

That is one reason we stopped using kubernetes.  The second was it didn’t offer 
super privileged container support, which we absolutely require.

Your right on the rationale for fig/docker-compose.


At this point is there any reasons not using something like ansible+docker 
plugin instead? I have used extensively fig back in the days for an internal 
project of mine and quickly come to its limitations with regard to caching and 
redeployment (was keeping having to do fig ps -q|xargs -r docker stop || true )

Your right fig/docker compose seems to have problems when something from docker 
daemon doesn’t do what it expects.  The bugs are really docker daemon bugs, for 
example, see:
https://github.com/docker/compose/issues/812

As far as ansible, I think it would be fantastic to use ansible to deploy kolla 
containers, and if I were making a deployment tool today, this is precisely 
what I’d do.  Whether ansible used docker directly by looking at our fig files, 
or compose, would be up to the author.  I think using fig would be preferrable 
in case the composition needed to change for some technical reason.

Regards
-steve



Cheers,
Chmouel

On Sun, Mar 22, 2015 at 4:50 PM, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:
FenghuaFeng,

Ccing openstack-dev

1. Kubernetes doesn’t offer a control or integration point.  We have that now 
with docker-compose.
2. Kubernetes doesn’t offer super privileged containers.  We need that in order 
to operate an OpenStack environment.

Regards
-steve

From: 449171342 <449171...@qq.com>
Date: Sunday, March 22, 2015 at 1:47 AM
To: Steven Dake mailto:std...@cisco.com>>
Subject: Why we didn't use k8s in kolla?



__
OpenStack Development Mailing 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] [devstack] Overriding settings file for devstack plugin

[Dean Troyer]

I wasn't clear, let me try again:

  CINDER_ENABLED_BACKENDS=";"

set the value to the separator character semi-colon.  That evaluates to
not-empty for the shell :- but has no entries so is still effectively null
for the cinder config code.

dt


On Wed, Mar 25, 2015 at 8:47 AM, Deepak Shetty  wrote:

>
>
> On Wed, Mar 25, 2015 at 6:58 PM, Dean Troyer  wrote:
>
>> On Wed, Mar 25, 2015 at 5:58 AM, Deepak Shetty 
>> wrote:
>>
>>> Sorry, hit send before i could complete
>>> back to square one (unless we modify lib/cinder to *not* use default
>>> for CINDER_ENABLED_BACKENDS
>>> if 'CINDER_ENABLED_BACKENDS=' specified in localrc)
>>>
>>
>> You could safely set CINDER_ENABLED_BACKENDS=; in local.conf to avoid the
>> :- default setting.
>>
>
> Per the comment from yamamoto [1] it seems :- stands for unset or empty,
> so it won't work (IIUC)
>
> [1]: https://review.openstack.org/#/c/167375/1/doc/source/plugins.rst
>
> thanx,
> deepak
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

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

Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin

[Deepak Shetty]

On Wed, Mar 25, 2015 at 6:58 PM, Dean Troyer  wrote:

> On Wed, Mar 25, 2015 at 5:58 AM, Deepak Shetty 
> wrote:
>
>> Sorry, hit send before i could complete
>> back to square one (unless we modify lib/cinder to *not* use default for
>> CINDER_ENABLED_BACKENDS
>> if 'CINDER_ENABLED_BACKENDS=' specified in localrc)
>>
>
> You could safely set CINDER_ENABLED_BACKENDS=; in local.conf to avoid the
> :- default setting.
>

Per the comment from yamamoto [1] it seems :- stands for unset or empty, so
it won't work (IIUC)

[1]: https://review.openstack.org/#/c/167375/1/doc/source/plugins.rst

thanx,
deepak
__
OpenStack Development Mailing 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] [Ceilometer] Meters vs. Metrics

[Ildikó Váncsa]

Hi All,

Thanks for the heads up regarding to this inconsistency of terms in the docs. I 
will open a bug for it and target both Ceilometer and OS Manuals to get it 
corrected everywhere.

Best Regards,
Ildikó

-Original Message-
From: Julien Danjou [mailto:jul...@danjou.info] 
Sent: Wednesday, March 25, 2015 1:14 PM
To: Tim Bell
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Meters vs. Metrics

On Wed, Mar 25 2015, Tim Bell wrote:

> Unfortunately, this is a cause of confusion for the users. Do you have 
> a reference to the differences in the concepts ?

There's a glossary here:
  http://docs.openstack.org/developer/ceilometer/glossary.html

> The ceilometer doc does also have this confusion in some places, for 
> example, 
> http://docs.openstack.org/developer/ceilometer/measurements.html mixes 
> the terms.

Agreed, that's a bug, it should be meter.

--
Julien Danjou
;; Free Software hacker
;; http://julien.danjou.info

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

Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware )

[Salvatore Orlando]

On 25 March 2015 at 14:21, Sean Dague  wrote:

> On 03/25/2015 09:03 AM, Gary Kotton wrote:
> >
> > From: Jordan Pittier  > >
> > Reply-To: OpenStack List  > >
> > Date: Wednesday, March 25, 2015 at 1:47 PM
> > To: OpenStack List  > >
> > Subject: Re: [openstack-dev] [nova] CI report formatting (citrix /
> > hyperv / vmware )
> >
> > Hi
> > On Wed, Mar 25, 2015 at 12:39 PM, Sean Dague  > > wrote:
> >
> > Currently Citrix, HyperV, and VMWare CI systems reporting on Nova
> > patches have a different formatting than the standard that Jenkins
> and
> > other systems are using:
> >
> > * test-name-no-spaces http://link.to/result
> > <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__link.to_result&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiE&s=5SS-txUrD3o8KS3QIaCL3XMBbeCYK5CjmzmuxDda7Oc&e=
> >
> > : [SUCCESS|FAILURE] some
> > comment about the test
> >
> > I don't want to talk for Citrix, HyperV or VMWare but the "standard"
> > only work if you use Zuul in your CI. I am using a setup based on a
> > Jenkins plugin called gerrit-trigger and there's no way to format the
> > message the way it's expected...
>

FWIW I help maintain one the VMware CIs (the one voting on neutron and
network-related patches for devstack and tempest).
We use gerrit-trigger too (mostly out of lazyness, no other real reason),
but we're able to format the message posted back to gerrit.
For posting back votes we use the "gerrit review" command to post the
message in the standard format.

I think the same process is adopted also by the CI voting on nova. However,
the job result string is not being posted. I will double check with the
respective owners.

Salvatore


> >
> >
> > This means these systems don't show up in the CI rollup block -
> > http://dl.dropbox.com/u/6514884/screenshot_158.png
> > <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__dl.dropbox.com_u_6514884_screenshot-5F158.png&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiE&s=nIjYwznh1_8aVBSz-XVEJrpNaMsDfqyekOQ2IhiHTo8&e=
> >
> >
> >
> > Current the Vmware CI will vote +1 iff the patch has passed on the CI.
> > We can investigate adding this to the CI rollup block.
> >
> >
> >
> > I'd really like that to change. The CI rollup block has been
> extremely
> > useful in getting the test results of a patch above the fold, and the
> > ability to dig into them clearly. I feel like if any CI system isn't
> > reporting in standard format that's parsible by that, we should
> probably
> > turn it off.
> >
> >
> > I do not think that we should turn this off. They have value. It would
> > be nice if things were all of the same format, which I guess that this
> > is the intension of the mail. Lets all try and make an effort to work
> > towards this goal.
>
> Right, honestly, I don't want these turned off, I want them reporting in
> a more standard format. But I do think if they don't report in a
> standard format it will cause problems and add to them being ignored.
>
> -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
>
>
__
OpenStack Development Mailing 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] [devstack] Overriding settings file for devstack plugin

[Dean Troyer]

On Wed, Mar 25, 2015 at 5:58 AM, Deepak Shetty  wrote:

> Sorry, hit send before i could complete
> back to square one (unless we modify lib/cinder to *not* use default for
> CINDER_ENABLED_BACKENDS
> if 'CINDER_ENABLED_BACKENDS=' specified in localrc)
>

You could safely set CINDER_ENABLED_BACKENDS=; in local.conf to avoid the
:- default setting.

dt

-- 

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

Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin

[Dean Troyer]

On Wed, Mar 25, 2015 at 6:04 AM, Deepak Shetty  wrote:
>
> Had a question here, why is this source in the end ?
>

More often than not, you will want the variables defined by the other
plugins (including the built-ins), this is really the first case we've had
to deviate from that.  The right solution is to add an 'override_plugins'
phase that runs before the built-ins are sourced so you can override the
built-in defaults.

dt

-- 

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

Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware )

[Sean Dague]

On 03/25/2015 09:03 AM, Gary Kotton wrote:
> 
> From: Jordan Pittier  >
> Reply-To: OpenStack List  >
> Date: Wednesday, March 25, 2015 at 1:47 PM
> To: OpenStack List  >
> Subject: Re: [openstack-dev] [nova] CI report formatting (citrix /
> hyperv / vmware )
> 
> Hi
> On Wed, Mar 25, 2015 at 12:39 PM, Sean Dague  > wrote:
> 
> Currently Citrix, HyperV, and VMWare CI systems reporting on Nova
> patches have a different formatting than the standard that Jenkins and
> other systems are using:
> 
> * test-name-no-spaces http://link.to/result
> 
> 
> : [SUCCESS|FAILURE] some
> comment about the test
> 
> I don't want to talk for Citrix, HyperV or VMWare but the "standard"
> only work if you use Zuul in your CI. I am using a setup based on a
> Jenkins plugin called gerrit-trigger and there's no way to format the
> message the way it's expected...
> 
> 
> This means these systems don't show up in the CI rollup block -
> http://dl.dropbox.com/u/6514884/screenshot_158.png
> 
> 
> 
> 
> Current the Vmware CI will vote +1 iff the patch has passed on the CI.
> We can investigate adding this to the CI rollup block.
> 
> 
> 
> I'd really like that to change. The CI rollup block has been extremely
> useful in getting the test results of a patch above the fold, and the
> ability to dig into them clearly. I feel like if any CI system isn't
> reporting in standard format that's parsible by that, we should probably
> turn it off.
> 
> 
> I do not think that we should turn this off. They have value. It would
> be nice if things were all of the same format, which I guess that this
> is the intension of the mail. Lets all try and make an effort to work
> towards this goal.

Right, honestly, I don't want these turned off, I want them reporting in
a more standard format. But I do think if they don't report in a
standard format it will cause problems and add to them being ignored.

-Sean

-- 
Sean Dague
http://dague.net



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] [Neutron] VLAN trunking network for NFV

[Assaf Muller]

- Original Message -
> > *From:* Ian Wells [mailto: ijw.ubuntu at cack.org.uk ] > *Sent:* Wednesday,
> > March 25, 2015 2:18 AM > > That spec ensures that you can tell what the
> > plugin is doing.  You can ask > for a VLAN transparent network, but the
> > cloud may tell you it can't make > one. > > If you want to use a VLAN
> > trunk using the current code, I recommend VXLAN > or GRE along with the
> > Linuxbridge driver, both of which support VLAN > transparent networking.
> > If they're configured and you ask for a VLAN trunk > you'll be told you
> > got one.
> The linuxbridge agent does not support GRE.
> I tried sending tagged packets over linuxbridge+VxLAN and it did not work - I
> didn't look into it any further.

This was a strong premise of the spec when it was under discussion, that we
at least some part of the reference implementation (LB + VXLAN was cited)
that works. If it doesn't, I think it's problematic to introduce new API
without a reference implementation.

> I also tried over linuxbridge+FLAT - this works when the physical switch
> ports are trunks - they would need to permit all VLAN ids to be fully "VLAN
> transparent".
> I think linuxbridge+VLAN would work too, as along as the switch ports are
> also configured for Q-in-Q.
> Currently the linuxbridge mechanism driver cannot know if a Neutron network
> is VLAN transparent or not.
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware )

[Gary Kotton]

From: Jordan Pittier 
mailto:jordan.pitt...@scality.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, March 25, 2015 at 1:47 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / 
vmware )

Hi
On Wed, Mar 25, 2015 at 12:39 PM, Sean Dague 
mailto:s...@dague.net>> wrote:
Currently Citrix, HyperV, and VMWare CI systems reporting on Nova
patches have a different formatting than the standard that Jenkins and
other systems are using:

* test-name-no-spaces 
http://link.to/result
 : [SUCCESS|FAILURE] some
comment about the test
I don't want to talk for Citrix, HyperV or VMWare but the "standard" only work 
if you use Zuul in your CI. I am using a setup based on a Jenkins plugin called 
gerrit-trigger and there's no way to format the message the way it's expected...

This means these systems don't show up in the CI rollup block -
http://dl.dropbox.com/u/6514884/screenshot_158.png

Current the Vmware CI will vote +1 iff the patch has passed on the CI. We can 
investigate adding this to the CI rollup block.



I'd really like that to change. The CI rollup block has been extremely
useful in getting the test results of a patch above the fold, and the
ability to dig into them clearly. I feel like if any CI system isn't
reporting in standard format that's parsible by that, we should probably
turn it off.

I do not think that we should turn this off. They have value. It would be nice 
if things were all of the same format, which I guess that this is the intension 
of the mail. Lets all try and make an effort to work towards this goal.



What's fair warning to get these systems postings into the standard
format? It realistically should be a very quick change by them, but will
help quite a lot in reviewing 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


__
OpenStack Development Mailing 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] creating stable branches for all libraries, Oslo, client, and other

[Dr. Jens Rosenboom]

Am 24/03/15 um 22:22 schrieb Joe Gordon:

On Tue, Mar 24, 2015 at 1:13 PM, Doug Hellmann 
wrote:


We have a cross-project spec up for review discussing a change in the
release process precipitated by the fact that we are now capping library
versions in stable branch test configurations. We’ve talked about it a
couple of times at the cross-project meetings, but we also want to make
sure it is widely seen because it will affect the way bug fixes need to be
managed in client libraries (new releases of clients won’t automatically
make it into stable branches, and we will need to maintain stable branches
of the clients with back-ports for critical fixes).


Here is a real case where the correct fix is a stable branch for a client:
https://bugs.launchpad.net/python-glanceclient/+bug/1423165


In case someone would like to read a bit about how this bug manifested 
itself for us from an operators point of view:


http://blog.offenerstapel.de/blog/2015/03/25/openstack-gone-wild/

__
OpenStack Development Mailing 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-Infra] [cinder] Status of Huawei Volume CI

[liuxinguo]

Hello Cinder team,

* Huawei Volume CI has been reporting since December 
20 th 2014. Now it runs
* two tempest jobs for Huawei 18000 iSCSI driver and Huawei 18000 FC 
driver.
* Considering that our drivers have been moved for the upstream, I have 
added some
* code to ensure the jobs run against the real storage 
backend when building devstack.
*
* And now the CI is reporting much more stably and will keep running 
and reporting from now on.
* Below is a link shows the recently posted results 
from the CI:

https://review.openstack.org/#/q/reviewer:%22Huawei+Volume+CI%22,n,z

I kindly request that you accept our CI result and consider re-integrating
our 18000 iSCSI and 18000 FC drivers back in Kilo RC.

If there is any concern, please let us know.

Thanks and regards,
Liu


__
OpenStack Development Mailing 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] Re: Why we didn't use k8s in kolla?

[Chmouel Boudjnah]

Hello,

So if I understand correctly Kubernetes was avoided since there is no
control point and using fig/docker-compose would get you a top to the
bottom deployment that easy to control.

At this point is there any reasons not using something like ansible+docker
plugin instead? I have used extensively fig back in the days for an
internal project of mine and quickly come to its limitations with regard to
caching and redeployment (was keeping having to do fig ps -q|xargs -r
docker stop || true )

Cheers,
Chmouel

On Sun, Mar 22, 2015 at 4:50 PM, Steven Dake (stdake) 
wrote:

>  FenghuaFeng,
>
>  Ccing openstack-dev
>
>  1. Kubernetes doesn’t offer a control or integration point.  We have
> that now with docker-compose.
> 2. Kubernetes doesn’t offer super privileged containers.  We need that in
> order to operate an OpenStack environment.
>
>  Regards
> -steve
>
>   From: 449171342 <449171...@qq.com>
> Date: Sunday, March 22, 2015 at 1:47 AM
> To: Steven Dake 
> Subject: Why we didn't use k8s in kolla?
>
>
>
>
> __
> OpenStack Development Mailing 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] 回复：[kolla] Re: Why we didn't use k8s in kolla?

[Steven Dake (stdake)]

From: 449171342 <449171...@qq.com>
Date: Tuesday, March 24, 2015 at 9:58 PM
To: Steven Dake mailto:std...@cisco.com>>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: 回复：[kolla] Re: Why we didn't use k8s in kolla?

TKS，I have  aanather question . DId kolla is a isolate project work together 
with TriplleO or kolla is  part of it?


At the moment we are a separate project.  I’d prefer that multiple deployment 
systems integrate with Kolla.  Some in the community have discussed creating a 
deployment tool as well to deploy Kolla containers if there is little community 
uptake on our work.

Regards
-steve



---原始邮件---
发件人: "Steven Dake (stdake)"mailto:std...@cisco.com>>
发送时间: 2015年03月22日 23:50:17
收件人: "449171342"<449171...@qq.com>;
抄送: "OpenStack Development Mailing List (not for usage 
questions)"mailto:openstack-dev@lists.openstack.org>>;
主题: [kolla] Re: Why we didn't use k8s in kolla?

FenghuaFeng,

Ccing openstack-dev

1. Kubernetes doesn’t offer a control or integration point.  We have that now 
with docker-compose.
2. Kubernetes doesn’t offer super privileged containers.  We need that in order 
to operate an OpenStack environment.

Regards
-steve

From: 449171342 <449171...@qq.com>
Date: Sunday, March 22, 2015 at 1:47 AM
To: Steven Dake mailto:std...@cisco.com>>
Subject: Why we didn't use k8s in kolla?


__
OpenStack Development Mailing 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] [Ceilometer] Meters vs. Metrics

[Julien Danjou]

On Wed, Mar 25 2015, Tim Bell wrote:

> Unfortunately, this is a cause of confusion for the users. Do you have
> a reference to the differences in the concepts ?

There's a glossary here:
  http://docs.openstack.org/developer/ceilometer/glossary.html

> The ceilometer doc does also have this confusion in some places, for
> example,
> http://docs.openstack.org/developer/ceilometer/measurements.html mixes
> the terms.

Agreed, that's a bug, it should be meter.

-- 
Julien Danjou
;; Free Software hacker
;; http://julien.danjou.info


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

Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware )

[Jordan Pittier]

Hi
On Wed, Mar 25, 2015 at 12:39 PM, Sean Dague  wrote:

> Currently Citrix, HyperV, and VMWare CI systems reporting on Nova
> patches have a different formatting than the standard that Jenkins and
> other systems are using:
>
> * test-name-no-spaces http://link.to/result : [SUCCESS|FAILURE] some
> comment about the test
>
I don't want to talk for Citrix, HyperV or VMWare but the "standard" only
work if you use Zuul in your CI. I am using a setup based on a Jenkins
plugin called gerrit-trigger and there's no way to format the message the
way it's expected...

>
> This means these systems don't show up in the CI rollup block -
> http://dl.dropbox.com/u/6514884/screenshot_158.png
>
> I'd really like that to change. The CI rollup block has been extremely
> useful in getting the test results of a patch above the fold, and the
> ability to dig into them clearly. I feel like if any CI system isn't
> reporting in standard format that's parsible by that, we should probably
> turn it off.
>
> What's fair warning to get these systems postings into the standard
> format? It realistically should be a very quick change by them, but will
> help quite a lot in reviewing 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
>
>
__
OpenStack Development Mailing 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] CI report formatting (citrix / hyperv / vmware )

[Sean Dague]

Currently Citrix, HyperV, and VMWare CI systems reporting on Nova
patches have a different formatting than the standard that Jenkins and
other systems are using:

* test-name-no-spaces http://link.to/result : [SUCCESS|FAILURE] some
comment about the test

This means these systems don't show up in the CI rollup block -
http://dl.dropbox.com/u/6514884/screenshot_158.png

I'd really like that to change. The CI rollup block has been extremely
useful in getting the test results of a patch above the fold, and the
ability to dig into them clearly. I feel like if any CI system isn't
reporting in standard format that's parsible by that, we should probably
turn it off.

What's fair warning to get these systems postings into the standard
format? It realistically should be a very quick change by them, but will
help quite a lot in reviewing code.

-Sean

-- 
Sean Dague
http://dague.net



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] [Ceilometer] Meters vs. Metrics

[Tim Bell]

> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: 25 March 2015 08:55
> To: Tim Bell
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Ceilometer] Meters vs. Metrics
> 
> On Tue, Mar 24 2015, Tim Bell wrote:
> 
> > Can we keep it consistent ? The APIs have meter in them, so do the
> > CLIs so we should really stick to that convention.
> 
> It should be consistent already, as picked terms years ago.
> Meters represents a set of samples with the same meter_name.
> 
> There's no metrics in Ceilometer.
> 

Unfortunately, this is a cause of confusion for the users. Do you have a 
reference to the differences in the concepts ?

The ceilometer doc does also have this confusion in some places, for example, 
http://docs.openstack.org/developer/ceilometer/measurements.html mixes the 
terms.

Existing meters
---

For the list of existing metrics see the tables under the Measurements page of 
Ceilometer in the Cloud Administrator Guide.

Tim

> > If Gnocchi is using metrics, I feel it should change to use meters or
> > a V3 API proposed that changes it all.
> 
> Gnocchi is using metrics to differ from Ceilometer's meters because they are 
> not
> the same "concept".
> 
> --
> Julien Danjou
> // Free Software hacker
> // http://julien.danjou.info

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

Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin

[Deepak Shetty]

On Wed, Mar 25, 2015 at 3:58 PM, Sean Dague  wrote:

> On 03/25/2015 03:16 AM, Deepak Shetty wrote:
> >
> >
> > On Wed, Mar 25, 2015 at 11:29 AM, Deepak Shetty  > > wrote:
> >
> >
> >
> > On Wed, Mar 25, 2015 at 12:58 AM, Ian Wienand  > > wrote:
> >
> > On 03/24/2015 03:17 PM, Deepak Shetty wrote:
> > > For eg: Look at [1]
> > > [1]
> https://github.com/stackforge/devstack-plugin-glusterfs/blob/master/devstack/settings
> >
> > > I would like ability to change these while I use the
> enable_plugin
> > > apporach to setup devstack w/ GlusterFS per my local glusterfs
> setup
> >
> > So I think the plugin should do
> >
> >
>  
> CINDER_ENABLED_BACKENDS=${CINDER_ENABLED_BACKENDS:-glusterfs:glusterfs,lvm:lvm1}
> >
> > i.e. provide a default only if the variable is unset.
> >
> >
> > Bah! That was easy, i should have figured that myself :)
> > Thanks for catching that
> >
> >
> >
> > This seems like one of those "traps for new players" and is one
> > concern I have with devstack plugins -- that authors keep having
> to
> > find out lessons learned independently.  I have added a note on
> this
> > to the documentation in [1].
> >
> > -i
> >
> > [1] https://review.openstack.org/#/c/167375/
> >
> >
> > Great, i +1'ed it.
> >
> > Also i posted patch to fix settings file @
> > https://review.openstack.org/167494
> >
> >
> > Ian,
> >Looks like usign bash default in settings file of plugin is not
> > working, in my patch it didn't use glusterfs driver, it used LVM
> (default)
> > I think whats happening here is that by the time settings file is
> > sourced, CINDER_ENABLED_BACKENDS is already set to lvm by lib/cinder
> > so settings file's default value is never taken
> >
> > IIUC there are 3 scenarios (taking CINDER_ENABLED_BACKENDS as example
> var) :
> >
> > 1) localrc doesn't have CINDER_ENABLED_BACKENDS and enable_plugin
> > - Here we want the lib/cinder's default value to be taken
> > - this should work fine
> >
> > 2) localrc doesn't have CINDER_ENABLED_BACKENDS but has enable_plugin
> > glusterfs
> > - Here we want the plugin's default values to be taken, but its not
> > as lib/cinder already initialized CINDER_ENABLED_BACKENDS to use lvm
> backend
> > - Thus broken
> >
> > 3) localrc has both CINDER_ENABLED_BACKENDS and enable_plugin glusterfs
> > specified
> > - Here we want CINDER_ENABLED_BACKENDS present in my localrc to be
> > chosen
> > - This will work as by the time settings file is sourced
> > CINDER_ENABLED_BACKENDS is already initialised to my value in localrc
> >
> > So #2 scenario would need some changes in stack.sh handling of plugin
> code ?
>
> Right, so this code runs late enough that you don't get to change the
> defaults. I think that's ok.
>

Had a question here, why is this source in the end ?

plugin config is something that should be allowed to be overridden, thus
this should
be sourced in the beginning and then anything in localrc will override what
the plugin
sets/unsets

That ways if someone wants to use plugin config, just enable the plugin.
if they want to override, enable plugin and override the env specific parts

Am i thinkign wrong ?

thanx,
deepak
__
OpenStack Development Mailing 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] [depfreeze][horizon] Update to Django-1.7.x

[Matthias Runge]

On 25/03/15 11:34, Sean Dague wrote:


Could you make this one "Depends on"
https://review.openstack.org/#/c/167515/ so that we check that all
Django 1.7 related issues are fixed ?


I don't think it was ever sufficiently explained why horizon now needs
django nose to compile it's message catalog (which is where it is
failing) when moving to 1.7.

http://logs.openstack.org/53/155353/7/check/check-tempest-dsvm-full/961c75f/logs/devstacklog.txt.gz#_2015-03-20_19_25_51_098


We're getting nearer here, thank you!

--compilemessages is called with test settings, which is wrong imo.

The question is, why it has not hit us earlier.

In any case, django_nose is not a runtime dep. I can see, why this is 
run at the gate as part of tests, though.


Matthias

__
OpenStack Development Mailing 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] [devstack] Overriding settings file for devstack plugin

[Deepak Shetty]

On Wed, Mar 25, 2015 at 4:24 PM, Deepak Shetty  wrote:

>
>
> On Wed, Mar 25, 2015 at 4:20 PM, Deepak Shetty 
> wrote:
>
>>
>>
>> On Wed, Mar 25, 2015 at 3:58 PM, Sean Dague  wrote:
>>
>>> On 03/25/2015 03:16 AM, Deepak Shetty wrote:
>>> >
>>> >
>>> > On Wed, Mar 25, 2015 at 11:29 AM, Deepak Shetty >> > > wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Mar 25, 2015 at 12:58 AM, Ian Wienand >> > > wrote:
>>> >
>>> > On 03/24/2015 03:17 PM, Deepak Shetty wrote:
>>> > > For eg: Look at [1]
>>> > > [1]
>>> https://github.com/stackforge/devstack-plugin-glusterfs/blob/master/devstack/settings
>>> >
>>> > > I would like ability to change these while I use the
>>> enable_plugin
>>> > > apporach to setup devstack w/ GlusterFS per my local
>>> glusterfs setup
>>> >
>>> > So I think the plugin should do
>>> >
>>> >
>>>  
>>> CINDER_ENABLED_BACKENDS=${CINDER_ENABLED_BACKENDS:-glusterfs:glusterfs,lvm:lvm1}
>>> >
>>> > i.e. provide a default only if the variable is unset.
>>> >
>>> >
>>> > Bah! That was easy, i should have figured that myself :)
>>> > Thanks for catching that
>>> >
>>> >
>>> >
>>> > This seems like one of those "traps for new players" and is one
>>> > concern I have with devstack plugins -- that authors keep
>>> having to
>>> > find out lessons learned independently.  I have added a note
>>> on this
>>> > to the documentation in [1].
>>> >
>>> > -i
>>> >
>>> > [1] https://review.openstack.org/#/c/167375/
>>> >
>>> >
>>> > Great, i +1'ed it.
>>> >
>>> > Also i posted patch to fix settings file @
>>> > https://review.openstack.org/167494
>>> >
>>> >
>>> > Ian,
>>> >Looks like usign bash default in settings file of plugin is not
>>> > working, in my patch it didn't use glusterfs driver, it used LVM
>>> (default)
>>> > I think whats happening here is that by the time settings file is
>>> > sourced, CINDER_ENABLED_BACKENDS is already set to lvm by lib/cinder
>>> > so settings file's default value is never taken
>>> >
>>> > IIUC there are 3 scenarios (taking CINDER_ENABLED_BACKENDS as example
>>> var) :
>>> >
>>> > 1) localrc doesn't have CINDER_ENABLED_BACKENDS and enable_plugin
>>> > - Here we want the lib/cinder's default value to be taken
>>> > - this should work fine
>>> >
>>> > 2) localrc doesn't have CINDER_ENABLED_BACKENDS but has enable_plugin
>>> > glusterfs
>>> > - Here we want the plugin's default values to be taken, but its not
>>> > as lib/cinder already initialized CINDER_ENABLED_BACKENDS to use lvm
>>> backend
>>> > - Thus broken
>>> >
>>> > 3) localrc has both CINDER_ENABLED_BACKENDS and enable_plugin glusterfs
>>> > specified
>>> > - Here we want CINDER_ENABLED_BACKENDS present in my localrc to be
>>> > chosen
>>> > - This will work as by the time settings file is sourced
>>> > CINDER_ENABLED_BACKENDS is already initialised to my value in localrc
>>> >
>>> > So #2 scenario would need some changes in stack.sh handling of plugin
>>> code ?
>>>
>>> Right, so this code runs late enough that you don't get to change the
>>> defaults. I think that's ok.
>>>
>>> I would instead do the following:
>>>
>>> 1) CINDER_ENABLED_BACKENDS+=,glusterfs:glusterfs
>>>
>>> or
>>>
>>> 2) CINDER_ENABLED_BACKENDS=glusterfs:glusterfs
>>>
>>> in the plugin.
>>>
>>> Clearly, if you've enabled the plugin, you want glusterfs. I think that
>>> in most cases you probably only want glusterfs as your backend, so
>>> option #2 seems sensible.
>>>
>>
>>
>> #1 is needed for multi-backend testing
>> #2 is needed for single-backend testing
>>
>> #2 is what we currently, we blindly override the var, but that forces the
>> devstack user to
>> use the config given in the plugin, I wanted a way to either use plugin
>> config or override it
>>
>> I think #1 is better, since it gives the power in localrc to do:
>>
>> 1) CINDER_ENABLED_BACKENDS=
>> This will ensure lib/cinder doesn't populate it and plugin adds
>> glusterfs:glusterfs for single backend
>>
>
> My bad here, lib/cinder uses :- which IIUC means empty or unset, use
> default
> so with #1 or #2 there isn't a way to provide ability to use plugin config
> or override it , both ?
>
> back to square one.
>

Sorry, hit send before i could complete
back to square one (unless we modify lib/cinder to *not* use default for
CINDER_ENABLED_BACKENDS
if 'CINDER_ENABLED_BACKENDS=' specified in localrc)

thanx,
deepak


>
> thanx,
> deepak
>
>
>>
>> 2) No mention of CINDER_ENABLED_BACKENDS in localrc
>> This will make it CINDER_ENABLED_BACKENDS=lvm:lvm-driver1,
>> glusterfs:glusterfs for multi-backend
>>
>> Also for vars in settings file that are backend specific (hence not
>> touched by lib/cinder):
>>
>> GLUSTERFS_LOOPBACK_DISK_SIZE & CINDER_GLUSTERFS_SHARES
>>
>> They can remain as :
>> GLUSTERFS_LOOPBACK_DISK_SIZE=${GLUSTERFS_LOOPBACK_DISK_SIZE:-8G}
>>
>> CINDER_GLUSTERFS_SHARES=${CI

Re: [openstack-dev] [Neutron] [TripleO] [Ironic] Deprecating the use_namespaces option - Now's the time to speak up!

[Neil.Jerram]

  Thanks for your interest; following is a description of what Calico does in this area. Just to be clear, this is for interest and information only and I don't mean to suggest that this has any bearing on the use_namespaces deprecation discussion (especially since that change is now merged).Calico doesn't use namespaces because it transports VM IP data between compute hosts by routing it, instead of bridging and tunnelling it. The routing between compute hosts is established in the default namespace by BGP clients (BIRD), so to connect with that the TAP interfaces from VMs need to sit in the default namespace too.‎Then the question arises of how to provide DHCP for those TAP interfaces - unbridged, and in the default namespace. Calico does this by running dnsmasq in the default namespace, using dnsmasq's --bridge-interfaces option to treat those TAP interfaces as aliases of the dummy interface on which the DHCP context and subnet gateway IP address are provisioned.Now, to set all that up - i.e. to provision the dummy interface; create the config files that dnsmasq needs, and update those as VMs are added or removed; launch dnsmasq; etc. -‎ is a lot of extra value, that neutron-dhcp-agent provides, and it's currently (in Icehouse and Juno) a relatively small patch on neutron-dhcp-agent to do all those things with the tweaks that Calico needs.I hope that makes sense, and is of some interest. Please do feel free to ask any further questions. Regards,        NeilFrom: Miguel Ángel AjoSent: Monday, 23 March 2015 06:59To: OpenStack Development Mailing List (not for usage questions)Reply To: OpenStack Development Mailing List (not for usage questions)Cc: openstack-operat...@lists.openstack.orgSubject: Re: [openstack-dev] [Neutron] [TripleO] [Ironic] Deprecating the use_namespaces option - Now's the time to speak up!Looking at project Calico, I don’t know if what they do is similar to what the people fromtriple-o & ironic do with the neutron-dhcp-agent. I believe we should ask thembefore deprecation.I added their tags to the subject.
AFAIK TripleO/Ironic was patching neutron-dhcp-agent too.For project Calico, why do you need no netns and why do you patch it? Kevin, thanks for pointing that out.Best,Miguel Ángel Ajo
 
On Monday, 23 de March de 2015 at 7:34, Miguel Ángel Ajo wrote:



+1 for deprecation if people don’t have use cases / good reasons to keep it, I don’t know      and I can’t think of any, but that doesn’t mean they don’t exist.
Miguel Ángel Ajo
  
On Monday, 23 de March de 2015 at 2:34, shihanzhang wrote:
+1 to deprecate this optionAt 2015-03-21 02:57:09, "Assaf Muller"  wrote:
>Hello everyone,
>
>The use_namespaces option in the L3 and DHCP Neutron agents controls if you
>can create multiple routers and DHCP networks managed by a single L3/DHCP agent,
>or if the agent manages only a single resource.
>
>Are the setups out there *not* using the use_namespaces option? I'm curious as
>to why, and if it would be difficult to migrate such a setup to use namespaces.
>
>I'm asking because use_namespaces complicates Neutron code for what I gather
>is an option that has not been relevant for years. I'd like to deprecate the option
>for Kilo and remove it in Liberty.
>
>
>Assaf Muller, Cloud Networking Engineer
>Red Hat
>
>__
>OpenStack Development Mailing 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
  
  



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

Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin

[Deepak Shetty]

On Wed, Mar 25, 2015 at 4:20 PM, Deepak Shetty  wrote:

>
>
> On Wed, Mar 25, 2015 at 3:58 PM, Sean Dague  wrote:
>
>> On 03/25/2015 03:16 AM, Deepak Shetty wrote:
>> >
>> >
>> > On Wed, Mar 25, 2015 at 11:29 AM, Deepak Shetty > > > wrote:
>> >
>> >
>> >
>> > On Wed, Mar 25, 2015 at 12:58 AM, Ian Wienand > > > wrote:
>> >
>> > On 03/24/2015 03:17 PM, Deepak Shetty wrote:
>> > > For eg: Look at [1]
>> > > [1]
>> https://github.com/stackforge/devstack-plugin-glusterfs/blob/master/devstack/settings
>> >
>> > > I would like ability to change these while I use the
>> enable_plugin
>> > > apporach to setup devstack w/ GlusterFS per my local
>> glusterfs setup
>> >
>> > So I think the plugin should do
>> >
>> >
>>  
>> CINDER_ENABLED_BACKENDS=${CINDER_ENABLED_BACKENDS:-glusterfs:glusterfs,lvm:lvm1}
>> >
>> > i.e. provide a default only if the variable is unset.
>> >
>> >
>> > Bah! That was easy, i should have figured that myself :)
>> > Thanks for catching that
>> >
>> >
>> >
>> > This seems like one of those "traps for new players" and is one
>> > concern I have with devstack plugins -- that authors keep
>> having to
>> > find out lessons learned independently.  I have added a note on
>> this
>> > to the documentation in [1].
>> >
>> > -i
>> >
>> > [1] https://review.openstack.org/#/c/167375/
>> >
>> >
>> > Great, i +1'ed it.
>> >
>> > Also i posted patch to fix settings file @
>> > https://review.openstack.org/167494
>> >
>> >
>> > Ian,
>> >Looks like usign bash default in settings file of plugin is not
>> > working, in my patch it didn't use glusterfs driver, it used LVM
>> (default)
>> > I think whats happening here is that by the time settings file is
>> > sourced, CINDER_ENABLED_BACKENDS is already set to lvm by lib/cinder
>> > so settings file's default value is never taken
>> >
>> > IIUC there are 3 scenarios (taking CINDER_ENABLED_BACKENDS as example
>> var) :
>> >
>> > 1) localrc doesn't have CINDER_ENABLED_BACKENDS and enable_plugin
>> > - Here we want the lib/cinder's default value to be taken
>> > - this should work fine
>> >
>> > 2) localrc doesn't have CINDER_ENABLED_BACKENDS but has enable_plugin
>> > glusterfs
>> > - Here we want the plugin's default values to be taken, but its not
>> > as lib/cinder already initialized CINDER_ENABLED_BACKENDS to use lvm
>> backend
>> > - Thus broken
>> >
>> > 3) localrc has both CINDER_ENABLED_BACKENDS and enable_plugin glusterfs
>> > specified
>> > - Here we want CINDER_ENABLED_BACKENDS present in my localrc to be
>> > chosen
>> > - This will work as by the time settings file is sourced
>> > CINDER_ENABLED_BACKENDS is already initialised to my value in localrc
>> >
>> > So #2 scenario would need some changes in stack.sh handling of plugin
>> code ?
>>
>> Right, so this code runs late enough that you don't get to change the
>> defaults. I think that's ok.
>>
>> I would instead do the following:
>>
>> 1) CINDER_ENABLED_BACKENDS+=,glusterfs:glusterfs
>>
>> or
>>
>> 2) CINDER_ENABLED_BACKENDS=glusterfs:glusterfs
>>
>> in the plugin.
>>
>> Clearly, if you've enabled the plugin, you want glusterfs. I think that
>> in most cases you probably only want glusterfs as your backend, so
>> option #2 seems sensible.
>>
>
>
> #1 is needed for multi-backend testing
> #2 is needed for single-backend testing
>
> #2 is what we currently, we blindly override the var, but that forces the
> devstack user to
> use the config given in the plugin, I wanted a way to either use plugin
> config or override it
>
> I think #1 is better, since it gives the power in localrc to do:
>
> 1) CINDER_ENABLED_BACKENDS=
> This will ensure lib/cinder doesn't populate it and plugin adds
> glusterfs:glusterfs for single backend
>

My bad here, lib/cinder uses :- which IIUC means empty or unset, use default
so with #1 or #2 there isn't a way to provide ability to use plugin config
or override it , both ?

back to square one.

thanx,
deepak


>
> 2) No mention of CINDER_ENABLED_BACKENDS in localrc
> This will make it CINDER_ENABLED_BACKENDS=lvm:lvm-driver1,
> glusterfs:glusterfs for multi-backend
>
> Also for vars in settings file that are backend specific (hence not
> touched by lib/cinder):
>
> GLUSTERFS_LOOPBACK_DISK_SIZE & CINDER_GLUSTERFS_SHARES
>
> They can remain as :
> GLUSTERFS_LOOPBACK_DISK_SIZE=${GLUSTERFS_LOOPBACK_DISK_SIZE:-8G}
>
> CINDER_GLUSTERFS_SHARES=${CINDER_GLUSTERFS_SHARES:-"127.0.0.1:
> /vol1;127.0.0.1:/vol2"}
>
> (as mentioned in the patch @
> https://review.openstack.org/#/c/167494/1/devstack/settings)
>
> This will give the end user the ability to change loopback size and/or
> gluster server IPs
> based on the needs of his/her local setup
>
> Agree ?
>
> If yes, then we must mention this in the plugin.rst in a nice way for
> other plugin writers to
> understand properl

Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin

[Ian Wienand]

On 03/25/2015 09:28 PM, Sean Dague wrote:

I would instead do the following:
1) CINDER_ENABLED_BACKENDS+=,glusterfs:glusterfs


This is what I was about to suggest.  I'd be willing to believe
ordering could still get tangled depending on exactly what you want --
I think at that point best to follow up in a bug and we can pull apart
the specifics.

-i

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

Re: [openstack-dev] [oslo] stable-maint for oslo.vmware

[Vipin Balachandran]

Doug,

Please add me to the stable maintenance team for oslo.vmware.

Thanks,
Vipin

-Original Message-
From: Doug Hellmann [mailto:d...@doughellmann.com] 
Sent: Tuesday, March 24, 2015 2:08 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [oslo] stable-maint for oslo.vmware

Gary pinged me on IRC earlier today and I missed him, so I’m sending this to 
the list in case someone else wants to volunteer.

It sounds like there are some stable branch changes for oslo.vmware that need 
attention. Does someone on the oslo.vmware team want to volunteer to be on a 
stable-maintenance team for the library?

Doug


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

Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin

[Deepak Shetty]

On Wed, Mar 25, 2015 at 3:58 PM, Sean Dague  wrote:

> On 03/25/2015 03:16 AM, Deepak Shetty wrote:
> >
> >
> > On Wed, Mar 25, 2015 at 11:29 AM, Deepak Shetty  > > wrote:
> >
> >
> >
> > On Wed, Mar 25, 2015 at 12:58 AM, Ian Wienand  > > wrote:
> >
> > On 03/24/2015 03:17 PM, Deepak Shetty wrote:
> > > For eg: Look at [1]
> > > [1]
> https://github.com/stackforge/devstack-plugin-glusterfs/blob/master/devstack/settings
> >
> > > I would like ability to change these while I use the
> enable_plugin
> > > apporach to setup devstack w/ GlusterFS per my local glusterfs
> setup
> >
> > So I think the plugin should do
> >
> >
>  
> CINDER_ENABLED_BACKENDS=${CINDER_ENABLED_BACKENDS:-glusterfs:glusterfs,lvm:lvm1}
> >
> > i.e. provide a default only if the variable is unset.
> >
> >
> > Bah! That was easy, i should have figured that myself :)
> > Thanks for catching that
> >
> >
> >
> > This seems like one of those "traps for new players" and is one
> > concern I have with devstack plugins -- that authors keep having
> to
> > find out lessons learned independently.  I have added a note on
> this
> > to the documentation in [1].
> >
> > -i
> >
> > [1] https://review.openstack.org/#/c/167375/
> >
> >
> > Great, i +1'ed it.
> >
> > Also i posted patch to fix settings file @
> > https://review.openstack.org/167494
> >
> >
> > Ian,
> >Looks like usign bash default in settings file of plugin is not
> > working, in my patch it didn't use glusterfs driver, it used LVM
> (default)
> > I think whats happening here is that by the time settings file is
> > sourced, CINDER_ENABLED_BACKENDS is already set to lvm by lib/cinder
> > so settings file's default value is never taken
> >
> > IIUC there are 3 scenarios (taking CINDER_ENABLED_BACKENDS as example
> var) :
> >
> > 1) localrc doesn't have CINDER_ENABLED_BACKENDS and enable_plugin
> > - Here we want the lib/cinder's default value to be taken
> > - this should work fine
> >
> > 2) localrc doesn't have CINDER_ENABLED_BACKENDS but has enable_plugin
> > glusterfs
> > - Here we want the plugin's default values to be taken, but its not
> > as lib/cinder already initialized CINDER_ENABLED_BACKENDS to use lvm
> backend
> > - Thus broken
> >
> > 3) localrc has both CINDER_ENABLED_BACKENDS and enable_plugin glusterfs
> > specified
> > - Here we want CINDER_ENABLED_BACKENDS present in my localrc to be
> > chosen
> > - This will work as by the time settings file is sourced
> > CINDER_ENABLED_BACKENDS is already initialised to my value in localrc
> >
> > So #2 scenario would need some changes in stack.sh handling of plugin
> code ?
>
> Right, so this code runs late enough that you don't get to change the
> defaults. I think that's ok.
>
> I would instead do the following:
>
> 1) CINDER_ENABLED_BACKENDS+=,glusterfs:glusterfs
>
> or
>
> 2) CINDER_ENABLED_BACKENDS=glusterfs:glusterfs
>
> in the plugin.
>
> Clearly, if you've enabled the plugin, you want glusterfs. I think that
> in most cases you probably only want glusterfs as your backend, so
> option #2 seems sensible.
>


#1 is needed for multi-backend testing
#2 is needed for single-backend testing

#2 is what we currently, we blindly override the var, but that forces the
devstack user to
use the config given in the plugin, I wanted a way to either use plugin
config or override it

I think #1 is better, since it gives the power in localrc to do:

1) CINDER_ENABLED_BACKENDS=
This will ensure lib/cinder doesn't populate it and plugin adds
glusterfs:glusterfs for single backend

2) No mention of CINDER_ENABLED_BACKENDS in localrc
This will make it CINDER_ENABLED_BACKENDS=lvm:lvm-driver1,
glusterfs:glusterfs for multi-backend

Also for vars in settings file that are backend specific (hence not touched
by lib/cinder):

GLUSTERFS_LOOPBACK_DISK_SIZE & CINDER_GLUSTERFS_SHARES

They can remain as :
GLUSTERFS_LOOPBACK_DISK_SIZE=${GLUSTERFS_LOOPBACK_DISK_SIZE:-8G}

CINDER_GLUSTERFS_SHARES=${CINDER_GLUSTERFS_SHARES:-"127.0.0.1:
/vol1;127.0.0.1:/vol2"}

(as mentioned in the patch @
https://review.openstack.org/#/c/167494/1/devstack/settings)

This will give the end user the ability to change loopback size and/or
gluster server IPs
based on the needs of his/her local setup

Agree ?

If yes, then we must mention this in the plugin.rst in a nice way for other
plugin writers to
understand properly :) ?

thanx,
deepak


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

[openstack-dev] [Neutron] VLAN trunking network for NFV

[Darragh O'Reilly]

> *From:* Ian Wells [mailto:ijw.ubuntu at cack.org.uk]
> *Sent:* Wednesday, March 25, 2015 2:18 AM
>
> That spec ensures that you can tell what the plugin is doing.  You can ask
> for a VLAN transparent network, but the cloud may tell you it can't make
> one.
>
> If you want to use a VLAN trunk using the current code, I recommend VXLAN
> or GRE along with the Linuxbridge driver, both of which support VLAN
> transparent networking.  If they're configured and you ask for a VLAN trunk
> you'll be told you got one.The linuxbridge agent does not support GRE.I tried 
> sending tagged packets over linuxbridge+VxLAN and it did not work - I didn't 
> look into it any further.I also tried over linuxbridge+FLAT - this works when 
> the physical switch ports are trunks - they would need to permit all VLAN ids 
> to be fully "VLAN transparent". 
I think linuxbridge+VLAN would work too, as along as the switch ports are also 
configured for Q-in-Q.Currently the linuxbridge mechanism driver cannot know if 
a Neutron network is VLAN transparent or not.
__
OpenStack Development Mailing 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] [depfreeze][horizon] Update to Django-1.7.x

[Sean Dague]

On 03/25/2015 05:04 AM, Thierry Carrez wrote:
> Matthias Runge wrote:
>> I'm requesting an exception to bump Django to Django-1.7.x (or better).
>>
>> Rationale:
>>
>> Django-1.8 is expected to be released during the next days. Once it's
>> released, Django-1.6.x will become unsupported by its upstream.
>> Unfortunately that's the latest version we're gating against and that's
>> the version frozen for kilo, or in other words:
>>
>> When Kilo is released, it relies on a version, not supported any more.
>>
>> Review is at https://review.openstack.org/#/c/155353/
> 
> Could you make this one "Depends on"
> https://review.openstack.org/#/c/167515/ so that we check that all
> Django 1.7 related issues are fixed ?

I don't think it was ever sufficiently explained why horizon now needs
django nose to compile it's message catalog (which is where it is
failing) when moving to 1.7.

http://logs.openstack.org/53/155353/7/check/check-tempest-dsvm-full/961c75f/logs/devstacklog.txt.gz#_2015-03-20_19_25_51_098

That seems to mean that nose is no longer a test only requirement, but a
hard requirement for installation.

While we can work around that in the gate, I think this might bite some
real users here. And I'd rather know why this need changed.

-Sean

-- 
Sean Dague
http://dague.net



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