Re: [openstack-dev] [Horizon] Ceilometer Alarm management page

[Ladislav Smola]

Hello Julien,

thank you very much for your response. I have commented it in-line. I 
have already started working on 1., I will plan the others, depending on 
the feedback.


Ladislav

On 09/23/2013 03:33 PM, Julien Danjou wrote:

On Thu, Sep 19 2013, Ladislav Smola wrote:

Hi Ladislav,

Sorry for the late reply,


1. The points 1-4 from are some sort simple version of the page, that uses
all basic alarm-api features. Do you think we need them all? Any feedback
for them? Enhancements?

That looks like a really good start if we can have all of this!


2. There is a thought, that we should maybe divide Alarms into (System,
User-defined). The only system alarms now, are set up with Heat and used for
auto-scaling.

I don't think there is any formal way to distinguish alarms. Though it's
likely you can retrieve the alarm list Heat created for the user to
distinguish them.
On the other hand, I am not sure the user can see the alarms created by
Heat since they might not directly belong to the user, but to Heat.


I have already talked about this with eglynn, recognition by the user could 
work. Now,
I am talking about the Admin role, which has rights to observe/manage alarms of 
all users,
I think.


3. There is a thought about watching correlation of multiple alarm histories
in one Chart (either Alarm Histories, or the real statistics the Alarm is
defined by). Do you think it will be needed? Any real life examples you have
in mind?

I think the first use case is to debug combined alarms.
There's also a lot of potential to debug an entire platform activity by
superimposing several alarm graphs.
Yes debugging combined alarms and superimposing them makes sense, also 
as I've talked
with eglynn, we can show alarm history as a chart of real statistics 
values, instead of
just (alarm, ok, insufficient data) states. That could present the 
alarms pretty good
and you could visually check the thresholds (in the future probably 
showing a thresholds

in the chart, and marking somehow the values that will exceed them)

4. There is a thought about tagging the alarms by user defined tag, so user
can easily group alarms together and then watch them together based on their
tag.

The alarm API don't provide that directly, but you can imagine some sort
of filter based on description matching some texts.
Yes, this could definitely work as a first version, if we decide this is 
needed feature.
The implementation of tags could be changed later if needed (probably to 
something

more optimized to query).

5. There is a thought about generating a default alarms, that could observe
the most important things (verifying good behaviour, showing bad behaviour).
Does anybody have an idea which alarms could be the most important and
usable for everybody?

I'm not sure you want to create alarm by default; alarm are resources, I
don't think we should create resources without the user asking for it.

Maybe you were talking about generating alarm template? You could start
with things like CPU usage staying at >90% for more than 1 hour, and
having an action that alerts the user via mail.
Same for disk usage.

Well for example, if we find metrics, that can be used for measuring health
(this is probably more undercloud talking, or hardware metrics in general),
we could do something like "I want this alarm on all resources of this 
type",
if there will be e.g. 100s of the resources of the same type, it would 
be pretty

dull to connect alarm to each of them, or to decide to change them.
Btw. it doesn't have to be a list of resource ids, but once the 
sample-api is finished,
it can be any query, that will produce a list of resources, tenants, 
etc.. (anything that

will allowed to be grouped by)

So it could serve as some kind of alarm groups management (let's say the 
group
is tagged somehow so you can recognize it ^^), it would add alarm on 
adding a

new resource and you could manage all alarms by one form.

Then when we have some alarm groups, that will be likely used by 80% of the
clouds, we could e.g. switch them on as default for Admins. Then Admin 
could

change the alarm group, or delete it if needed.

And yes, preparing a general templates is also a good idea, probably 
categorized by use case.
Users will have something pre-prepared, and they can set the most used 
Alarms

without need of reading the whole docs.


6. There is a thought about making overview pages customizable by the users,
so they can really observe, what they need. (includes Ceilometer statistics
and alarms)

I think that could be as easy as picking the alarms you want in
overviews with a very small and narrowed graph.


True that. The more complex version would be to save any complex query
of some general chart e.g. cpu_util, grouped by tenant, in last week. Showed
on some grid system. -> though this is more distant future.

Let's start simple as you say, just picking the alarms. And there would 
be a one
select-box, that would change a time period of all displayed cha

[openstack-dev] [LBaaS][Horizon] Subnet for VIP?

[fank]

Hi,

When adding a VIP for this pool, we suppose to specify the subnet which the VIP 
will be on. However, the Horizon UI forces us to provide an IP address for the 
VIP from the subnet which we used to create the pool. That subnet for pool is 
supposed to be the subnet for pool's members, not the subnet for the VIP.

This looks like a UI bug?

Thanks,
-Kaiwei

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

Re: [openstack-dev] On the usage of pip vs. setup.py install

[Joshua Harlow]

I wonder who got the plague if u got the food :-/

Sent from my really tiny device...

On Sep 23, 2013, at 8:07 PM, "Michael Basnight"  wrote:

> But I got suddenly full. Interesting thing that is. 
> 
> Sent from my digital shackles
> 
>> On Sep 23, 2013, at 7:16 PM, Joshua Harlow  wrote:
>> 
>> I ran that but world peace didn't happen.
>> 
>> Where can I get my refund?
>> 
>> Sent from my really tiny device...
>> 
>>> On Sep 23, 2013, at 6:47 PM, "Monty Taylor"  wrote:
>>> 
>>> tl;dr - easy_install sucks, so use pip
>>> 
>>> It is common practice in python to run:
>>> 
>>> python setup.py install
>>> or
>>> python setup.py develop
>>> 
>>> So much so that we spend a giant amount of effort to make sure that
>>> those always work.
>>> 
>>> Fortunately for us, the underlying mechanism, setuptools, can often be a
>>> pile of monkies. pip, while also with its fair share of issues, _is_ a
>>> bit better at navigating the shallow waters at times. SO - I'd like to
>>> suggest:
>>> 
>>> Instead of:
>>> 
>>> "python setup.py install"
>>> 
>>> Run:
>>> 
>>> "pip install ."
>>> 
>>> It should have the exact same result, but pip can succeed in some places
>>> where setup.py install directly can fail.
>>> 
>>> Also, if you'd like to run python setup.py develop, simply run:
>>> 
>>> "pip install -e ."
>>> 
>>> Which you may not have known will run setup.py develop behind the scenes.
>>> 
>>> Things this will help with:
>>> - world peace
>>> - requirements processing
>>> - global hunger
>>> - the plague
>>> 
>>> Enjoy.
>>> 
>>> Monty
>>> 
>>> PS. The other should work. It's just sometimes it doesn't, and when it
>>> doesn't it's less my fault.
>>> 
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron] dnsmasq process wasn't created after added a network

[Yoshihiro Kaneko]

Hi,

I misunderstood.
dnsmasq process was created when VM port, not a network, was added.

Thanks,
Kaneko


2013/9/20 Yoshihiro Kaneko :
> Hello,
>
> I tried latest devstack (master branch).
> And I created a network, but dnsmasq process for the network wasn't created.
>
> localrc I used is as follows:
> --
> HOST_NAME=$(hostname)
> SERVICE_HOST=192.168.1.10
>
> disable_service n-net
> enable_service q-svc q-agt q-dhcp q-l3 q-meta neutron
>
> Q_HOST=$SERVICE_HOST
> MYSQL_HOST=$SERVICE_HOST
> RABBIT_HOST=$SERVICE_HOST
> GLANCE_HOSTPORT=$SERVICE_HOST:9292
> KEYSTONE_AUTH_HOST=$SERVICE_HOST
> KEYSTONE_SERVICE_HOST=$SERVICE_HOST
>
> MYSQL_PASSWORD=mysql
> RABBIT_PASSWORD=rabbit
> SERVICE_TOKEN=service
> SERVICE_PASSWORD=admin
> SERVICE_TENANT_NAME=service
> ADMIN_PASSWORD=admin
>
> RECLONE=yes
> --
>
> There is dnsmasq process for initial network (private) after stack.sh started.
> --
> $ neutron net-list
> +--+-+--+
> | id   | name| subnets
>  |
> +--+-+--+
> | b2c2cc34-d349-4a2d-b153-f4cd0d357d3d | public  |
> 0aad0524-12b3-4ec9-9c4b-c592570a5711 172.24.4.224/28 |
> | c2b46689-d1a4-40d0-b0d5-103582980eea | private |
> 09aa0f86-eeeb-4324-91b0-233d336a29d0 10.0.0.0/24 |
> +--+-+--+
> $ neutron subnet-list
> +--++-+--+
> | id   | name   | cidr
>| allocation_pools |
> +--++-+--+
> | 09aa0f86-eeeb-4324-91b0-233d336a29d0 | private-subnet | 10.0.0.0/24
>| {"start": "10.0.0.2", "end": "10.0.0.254"}   |
> | 0aad0524-12b3-4ec9-9c4b-c592570a5711 | public-subnet  |
> 172.24.4.224/28 | {"start": "172.24.4.226", "end": "172.24.4.238"} |
> +--++-+--+
> $ neutron port-list -c fixed_ips -c device_owner
> +-+--+
> | fixed_ips
>| device_owner |
> +-+--+
> | {"subnet_id": "09aa0f86-eeeb-4324-91b0-233d336a29d0", "ip_address":
> "10.0.0.2"} | network:dhcp |
> | {"subnet_id": "0aad0524-12b3-4ec9-9c4b-c592570a5711", "ip_address":
> "172.24.4.226"} | network:router_gateway   |
> | {"subnet_id": "09aa0f86-eeeb-4324-91b0-233d336a29d0", "ip_address":
> "10.0.0.1"} | network:router_interface |
> +-+--+
> $ ps ax | grep dnsmasq
>  5864 ?S  0:00 dnsmasq --no-hosts --no-resolv
> --strict-order --bind-interfaces --interface=tap7d7f5c08-61
> --except-interface=lo
> --pid-file=/opt/stack/data/neutron/dhcp/c2b46689-d1a4-40d0-b0d5-103582980eea/pid
> --dhcp-hostsfile=/opt/stack/data/neutron/dhcp/c2b46689-d1a4-40d0-b0d5-103582980eea/host
> --dhcp-optsfile=/opt/stack/data/neutron/dhcp/c2b46689-d1a4-40d0-b0d5-103582980eea/opts
> --leasefile-ro --dhcp-range=set:tag0,10.0.0.0,static,86400s
> --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
> --
>
> Then, I added a new network, subnet and router, but dnsmasq process
> wasn't added.
> --
> $ neutron net-create private2
> Created a new network:
> +---+--+
> | Field | Value|
> +---+--+
> | admin_state_up| True |
> | id| 99341220-b12d-4dd0-af96-19a4915e3a03 |
> | name  | private2 |
> | provider:network_type | local|
> | provider:physical_network |  |
> | provider:segmentation_id  |  |
> | shared| False|
> | status| ACTIVE   |
> | subnets   |  |
> | tenant_id | 818d0e9c0ae94f43bd6d65a69b6f2e17 |
> +---+--+
> $ neutron subnet-create --ip-version 4 --gateway 11.0.0.1 private2 11.0.0.0/24
> C

Re: [openstack-dev] [heat] [scheduler] Bringing things together for Icehouse

[Clint Byrum]

Excerpts from Mike Spreitzer's message of 2013-09-23 20:31:32 -0700:
> I was not trying to raise issues of geographic dispersion and other higher 
> level structures, I think the issues I am trying to raise are relevant 
> even without them.  This is not to deny the importance, or relevance, of 
> higher levels of structure.  But I would like to first respond to the 
> discussion that I think is relevant even without them.
> 
> I think it is valuable for OpenStack to have a place for holistic 
> infrastructure scheduling.  I am not the only one to argue for this, but I 
> will give some use cases.  Consider Hadoop, which stresses the path 
> between Compute and Block Storage.  In the usual way of deploying and 
> configuring Hadoop, you want each data node to be using directly attached 
> storage.  You could address this by scheduling one of those two services 
> first, and then the second with constraints from the first --- but the 
> decisions made by the first could paint the second into a corner.  It is 
> better to be able to schedule both jointly.  Also consider another 
> approach to Hadoop, in which the block storage is provided by a bank of 
> storage appliances that is equidistant (in networking terms) from all the 
> Compute.  In this case the Storage and Compute scheduling decisions have 
> no strong interaction --- but the Compute scheduling can interact with the 
> network (you do not want to place Compute in a way that overloads part of 
> the network).
> 
> Once a holistic infrastructure scheduler has made its decisions, there is 
> then a need for infrastructure orchestration.  The infrastructure 
> orchestration function is logically downstream from holistic scheduling. I 
> do not favor creating a new and alternate way of doing infrastructure 
> orchestration in this position.  Rather I think it makes sense to use 
> essentially today's heat engine.
> 

Ok, now I think I understand you.

What you're talking about, in many ways, is very similar to what the
autoscale-interested folk have been proposing. Something that sits
outside of Heat and makes use of other information (alarms/policy/etc)
to tweak a Heat stack.

Only this service would make use of information before a stack was
even created.

I like it, and I do think that it should be "part of heat" because it will
be making use of Heat's templating to make those decisions. However,
I also think it should be a separate repository/project within the
"OpenStack Orchestration" program, to keep it honest with regard to
interfaces. Heat's infrastructure-focused service is already big enough,
we don't need to grow it even more with only slightly-related code.

Also I imagine there are many ways to skin this cat, and thus we may see
alternative holistic schedulers for specific applications (Savannah may
use a hadoop specific approach, as you suggested). There is also the
possibility of chaining schedulers.

The Tuskar project also comes to mind, as the deployment of baremetal with
a mind toward network topology and physical placement (racks/rooms/etc)
for the explicit purpose of deploying OpenStack is itself a form of
holistic scheduling.

> Today Heat is the only thing that takes a holistic view of 
> patterns/topologies/templates, and there are various pressures to expand 
> the mission of Heat.  A marquee expansion is to take on software 
> orchestration.  I think holistic infrastructure scheduling should be 
> downstream from the preparatory stage of software orchestration (the other 
> stage of software orchestration is the run-time action in and supporting 
> the resources themselves).  There are other pressures to expand the 
> mission of Heat too.  This leads to conflicting usages for the word 
> "heat": it can mean the infrastructure orchestration function that is the 
> main job of today's heat engine, or it can mean the full expanded mission 
> (whatever you think that should be).  I have been mainly using "heat" in 
> that latter sense, but I do not really want to argue over naming of bits 
> and assemblies of functionality.  Call them whatever you want.  I am more 
> interested in getting a useful arrangement of functionality.  I have 
> updated my picture at 
> https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o0R9U
>  
> --- do you agree that the arrangement of functionality makes sense?

I do now. I stand by the original position that Heat, as it exists today,
would simply pass along infrastructure scheduling decisions made by a
holistic scheduler. However I think it would be unwise to try and develop
these things apart from one another as it may encourage fracturing the
template language. So I would propose that if there is a more general
purpose attempt at holistic scheduling via Heat templates that it be
done as a separate service/repository within the Heat program.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.or

Re: [openstack-dev] [heat] [scheduler] Bringing things together for Icehouse

[Mike Spreitzer]

Someone earlier asked for greater clarity about infrastructure 
orchestration, so here is my view.  I see two main issues: (1) deciding 
the order in which to do things, and (2) doing them in an acceptable 
order.  That's an oversimplified wording because, in general, some 
parallelism is possible.  In general, the set of things to do is 
constrained by a partial order --- and that partial order comes from two 
sources.  One is the nature of the downstream APIs.  For examples, you can 
not attach a volume or floating IP address to a VM until after both have 
been created.  The other source of ordering constraints is upstream 
decision makers.  Decisions made upstream are conveyed into today's heat 
engine by data dependencies between resources in a heat template.  The 
heat engine is not making those decisions.  It is not a source of 
important ordering constraints.  When the ordering constraints actually 
allow some parallelism --- they do not specify a total order --- the heat 
engine has freedom in which of that parallelism to exploit vs flatten into 
sequential ordering.  What today's heat engine does is make its available 
choices about that and issue the operations, keeping track of IDs and 
outcomes.  I have been using the term "infrastructure orchestration" to 
refer to this latter job (issuing infrastructure operations with 
acceptable ordering/parallelism), not the decision-making of upstream 
agents.  This might be confusing; I think the plain English meaning of 
"orchestration" suggests decision-making as well as execution.

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

Re: [openstack-dev] [heat] [scheduler] Bringing things together for Icehouse

[Mike Spreitzer]

I was not trying to raise issues of geographic dispersion and other higher 
level structures, I think the issues I am trying to raise are relevant 
even without them.  This is not to deny the importance, or relevance, of 
higher levels of structure.  But I would like to first respond to the 
discussion that I think is relevant even without them.

I think it is valuable for OpenStack to have a place for holistic 
infrastructure scheduling.  I am not the only one to argue for this, but I 
will give some use cases.  Consider Hadoop, which stresses the path 
between Compute and Block Storage.  In the usual way of deploying and 
configuring Hadoop, you want each data node to be using directly attached 
storage.  You could address this by scheduling one of those two services 
first, and then the second with constraints from the first --- but the 
decisions made by the first could paint the second into a corner.  It is 
better to be able to schedule both jointly.  Also consider another 
approach to Hadoop, in which the block storage is provided by a bank of 
storage appliances that is equidistant (in networking terms) from all the 
Compute.  In this case the Storage and Compute scheduling decisions have 
no strong interaction --- but the Compute scheduling can interact with the 
network (you do not want to place Compute in a way that overloads part of 
the network).

Once a holistic infrastructure scheduler has made its decisions, there is 
then a need for infrastructure orchestration.  The infrastructure 
orchestration function is logically downstream from holistic scheduling. I 
do not favor creating a new and alternate way of doing infrastructure 
orchestration in this position.  Rather I think it makes sense to use 
essentially today's heat engine.

Today Heat is the only thing that takes a holistic view of 
patterns/topologies/templates, and there are various pressures to expand 
the mission of Heat.  A marquee expansion is to take on software 
orchestration.  I think holistic infrastructure scheduling should be 
downstream from the preparatory stage of software orchestration (the other 
stage of software orchestration is the run-time action in and supporting 
the resources themselves).  There are other pressures to expand the 
mission of Heat too.  This leads to conflicting usages for the word 
"heat": it can mean the infrastructure orchestration function that is the 
main job of today's heat engine, or it can mean the full expanded mission 
(whatever you think that should be).  I have been mainly using "heat" in 
that latter sense, but I do not really want to argue over naming of bits 
and assemblies of functionality.  Call them whatever you want.  I am more 
interested in getting a useful arrangement of functionality.  I have 
updated my picture at 
https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o0R9U 
--- do you agree that the arrangement of functionality makes sense?

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

Re: [openstack-dev] On the usage of pip vs. setup.py install

[Michael Basnight]

But I got suddenly full. Interesting thing that is. 

Sent from my digital shackles

> On Sep 23, 2013, at 7:16 PM, Joshua Harlow  wrote:
> 
> I ran that but world peace didn't happen.
> 
> Where can I get my refund?
> 
> Sent from my really tiny device...
> 
>> On Sep 23, 2013, at 6:47 PM, "Monty Taylor"  wrote:
>> 
>> tl;dr - easy_install sucks, so use pip
>> 
>> It is common practice in python to run:
>> 
>> python setup.py install
>> or
>> python setup.py develop
>> 
>> So much so that we spend a giant amount of effort to make sure that
>> those always work.
>> 
>> Fortunately for us, the underlying mechanism, setuptools, can often be a
>> pile of monkies. pip, while also with its fair share of issues, _is_ a
>> bit better at navigating the shallow waters at times. SO - I'd like to
>> suggest:
>> 
>> Instead of:
>> 
>> "python setup.py install"
>> 
>> Run:
>> 
>> "pip install ."
>> 
>> It should have the exact same result, but pip can succeed in some places
>> where setup.py install directly can fail.
>> 
>> Also, if you'd like to run python setup.py develop, simply run:
>> 
>> "pip install -e ."
>> 
>> Which you may not have known will run setup.py develop behind the scenes.
>> 
>> Things this will help with:
>> - world peace
>> - requirements processing
>> - global hunger
>> - the plague
>> 
>> Enjoy.
>> 
>> Monty
>> 
>> PS. The other should work. It's just sometimes it doesn't, and when it
>> doesn't it's less my fault.
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] On the usage of pip vs. setup.py install

[Joshua Harlow]

I ran that but world peace didn't happen.

Where can I get my refund?

Sent from my really tiny device...

On Sep 23, 2013, at 6:47 PM, "Monty Taylor"  wrote:

> tl;dr - easy_install sucks, so use pip
> 
> It is common practice in python to run:
> 
> python setup.py install
> or
> python setup.py develop
> 
> So much so that we spend a giant amount of effort to make sure that
> those always work.
> 
> Fortunately for us, the underlying mechanism, setuptools, can often be a
> pile of monkies. pip, while also with its fair share of issues, _is_ a
> bit better at navigating the shallow waters at times. SO - I'd like to
> suggest:
> 
> Instead of:
> 
> "python setup.py install"
> 
> Run:
> 
> "pip install ."
> 
> It should have the exact same result, but pip can succeed in some places
> where setup.py install directly can fail.
> 
> Also, if you'd like to run python setup.py develop, simply run:
> 
> "pip install -e ."
> 
> Which you may not have known will run setup.py develop behind the scenes.
> 
> Things this will help with:
> - world peace
> - requirements processing
> - global hunger
> - the plague
> 
> Enjoy.
> 
> Monty
> 
> PS. The other should work. It's just sometimes it doesn't, and when it
> doesn't it's less my fault.
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Infra] Meeting Tuesday September 24th at 19:00 UTC

[Elizabeth Krumbach Joseph]

The OpenStack Infrastructure (Infra) team is hosting our weekly
meeting tomorrow, Tuesday September 24th, at 19:00 UTC in
#openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.


-- 
Elizabeth Krumbach Joseph || Lyz || pleia2
http://www.princessleia.com

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

[openstack-dev] [Nova] Review request for bp cancel-swap-volume and idempotency-client-token

[志田 隆弘]

Hi everyone.

We registered two individual blue print.
One is simple, swap-volume feature should be provide cancelling functionality.
Another is a bit complicated, OpenStack API should be support API idempotency.

- Cancelling a swap volume
https://blueprints.launchpad.net/nova/+spec/cancel-swap-volume
- Idempotency for OpenStack API
https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token

Please check and review these.

Best Regards,

/**
Takahiro Shida
Cheif Consultant
NTTDATA INTELLILINK
Phone: +81 3 5843 6880
Mail: sh...@intellilink.co.jp
*/


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

Re: [openstack-dev] Client and Policy

[Adam Young]

On 09/23/2013 03:21 PM, Doug Hellmann wrote:




On Mon, Sep 23, 2013 at 4:25 AM, Flavio Percoco > wrote:


On 20/09/13 15:20 -0700, Monty Taylor wrote:

On 09/20/2013 02:55 PM, Ben Nemec wrote:

Not from a Gerrit perspective, but the Oslo policy is that
a maintainer
+1 on the code they maintain is the equivalent of a +2, so
only one core
is needed to approve.

See

https://github.com/openstack/oslo-incubator/blob/master/MAINTAINERS#L28


What if we rethought the organization just a little bit.
Instead of
having oslo-incubator from which we copy code, and then oslo.*
that we
consume as libraries, what if:

- we split all oslo modules into their own repos from the start


IIRC, we're planning to have a design session around these lines at
the summit. I think the only issue here is figuring out where some
modules belong. For example, where would we put strutils? Should we
have a single repo for it or perhaps have a more generic one, say
oslo.text, were we could group strutils, jsonutils and some other
modules?

There are plenty of "single-file" packages out there but I'd
personally prefer grouping modules as much as possible.


I agree.


Another thing to consider is, what happens with Oslo modules depending
on other oslo modules? I guess we would make sure all the dependencies
are copied in the project as we do today but, when it comes to testing
the single module, I think this could be an issue. For example,
policy.py depends on fileutils, gettextutils and other oslo module
which wouldn't fit in the same package, oslo.policy. This will make
testing oslo.policy a real pain since we would have to "copy" its
dependencies in its own tree as well.


This is a great reason to keep everything together in a single 
incubator repository until a package is ready to stand on its own as a 
library. Libraries can easily declare dependencies to be installed for 
testing, but if we start copying bits of oslo around into separate git 
repositories then we'll all go mad trying to keep all of the repos up 
to date. :-) In the mean time, any review pain we have can be used as 
encouragement to bring the library to a point where it can be moved 
out of the incubator.


It sounds like the primary concern is having enough keystone folks 
looking at reviews of the policy code, without being overwhelmed by 
tracking all Oslo changes. There are a couple of ways to address that.


The policy code seems very tightly associated with the keystone work. 
There's no reason for Oslo to be the only program releasing reusable 
libraries. We should consider having the Keystone team manage the 
policy library in a repo they own. I'd love to have the Keystone 
middleware work the same way, instead of being in the client repo, but 
one step at a time.


Of course, if the policy code is nearing the point where it is ready 
to graduate from the incubator, then maybe that suggestion is moot and 
we should just continue to push ahead on the path we're on now. We 
could have people submitting policy code to oslo-incubator add 
"keystone-core" to reviews (adding a group automatically adds its 
members), so they don't have to subscribe to oslo notifications.


How close is the policy code to being ready to graduate?


I would argue that it should graduate now.  Keystone is willing to take 
it on as a subproject, just like  the keystoneclient code is. We 
discussed  putting it in keystoneclient, since auth_token middleware is 
there already.   Thus, anything already using auth_token middleware 
already has the package.






Doug



- we make update.py a utility that groks copying from a
directory that
contains a bunch of repos - so that a person wanting to use is
might have:
 ~/src
 ~/src/oslo
 ~/src/oslo/oslo.db
 ~/src/oslo/oslo.policy
 and then when they run update.py ~/src/oslo ~/src/nova and
get the
same results (the copying and name changing and whatnot)


If we split modules in its own repos, I'd rather use git submodules,
which would then work better. 





That way, we can add per-module additional core easily like we
can for
released oslo modules (like hacking and pbr have now)


+1



Also, that would mean that moving from copying to releasing is
more a
matter of just making a release than it is of doing the git
magic to
split the repo out into a separate one and then adding the new
repo to
gerrit.


+1

Thoughts?


I like the idea overall, I'm a bit worried about how those modules
would be organized.

Any thoughts about the above concerns?


Cheers,
FF

-- 
@flaper87

Flavio Percoco

_

Re: [openstack-dev] On the usage of pip vs. setup.py install

[Dolph Mathews]

On Mon, Sep 23, 2013 at 8:44 PM, Monty Taylor  wrote:

> tl;dr - easy_install sucks, so use pip
>
> It is common practice in python to run:
>
> python setup.py install
> or
> python setup.py develop
>
> So much so that we spend a giant amount of effort to make sure that
> those always work.
>
> Fortunately for us, the underlying mechanism, setuptools, can often be a
> pile of monkies. pip, while also with its fair share of issues, _is_ a
> bit better at navigating the shallow waters at times. SO - I'd like to
> suggest:
>
> Instead of:
>
> "python setup.py install"
>
> Run:
>
> "pip install ."
>
> It should have the exact same result, but pip can succeed in some places
> where setup.py install directly can fail.
>
> Also, if you'd like to run python setup.py develop, simply run:
>
> "pip install -e ."
>
> Which you may not have known will run setup.py develop behind the scenes.
>
> Things this will help with:
> - world peace
> - requirements processing
> - global hunger
> - the plague
>
> Enjoy.
>

+1 for you and all your fancy tricks! Thank you!


>
> Monty
>
> PS. The other should work. It's just sometimes it doesn't, and when it
> doesn't it's less my fault.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

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

[openstack-dev] On the usage of pip vs. setup.py install

[Monty Taylor]

tl;dr - easy_install sucks, so use pip

It is common practice in python to run:

python setup.py install
or
python setup.py develop

So much so that we spend a giant amount of effort to make sure that
those always work.

Fortunately for us, the underlying mechanism, setuptools, can often be a
pile of monkies. pip, while also with its fair share of issues, _is_ a
bit better at navigating the shallow waters at times. SO - I'd like to
suggest:

Instead of:

"python setup.py install"

Run:

"pip install ."

It should have the exact same result, but pip can succeed in some places
where setup.py install directly can fail.

Also, if you'd like to run python setup.py develop, simply run:

"pip install -e ."

Which you may not have known will run setup.py develop behind the scenes.

Things this will help with:
- world peace
- requirements processing
- global hunger
- the plague

Enjoy.

Monty

PS. The other should work. It's just sometimes it doesn't, and when it
doesn't it's less my fault.

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

Re: [openstack-dev] Is "python setup.py intsall" recommended way to install Neutron Server in dev environment?

[Monty Taylor]

On 09/23/2013 01:20 PM, Vijay Venkatachalam wrote:
> Hi,
> 
> I am new to openstack, please pardon if the questions
> are dumb.
> 
>  
> 
> Attempting to run a neutron dev setup with openvswitch plugin with VLAN
> isolation and 2 hosts.
> 
>  
> 
> _DISCLAIMER: _I am not using devstack. Attempting to install the
> services in a controller node  - Ubuntu12.04 VM.
> 
>  
> 
> 1.   In the controller node
> 
> a)  Services horizon/keystone/glance are installed using “apt-get”.
> Yet to install nova.
> 
> b)  Also in addition, for development needs, we have cloned neutron
> from github
> 
> c)   ran “python setup.py install”
> 
> # Is this the recommended way? This seems to have installed all agents
>  “/usr/local/bin/neutron-*-agent”s as well in  Controller Node.


Yes - this is both fine and expected.

I actually recommend a minor variation, for reasons that get very
annoying...

Instead of:

"python setup.py install"

Run:

"pip install ."

It should have the exact same result, but pip can succeed in some places
where setup.py install directly can fail.

Also, if you'd like to run python setup.py develop, simply run:

"pip install -e ."

Which will do the same thing.

Hrm. I should send that out generally.
>  
> 
>
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] Does quantum work with vmware esxi ?

[Dan Wendlandt]

Compatibility of various Quantum/Neutron plugins with various Nova
hypervisors is documented here:
http://docs.openstack.org/grizzly/openstack-network/admin/content/flexibility.html
.


Dan





On Mon, Sep 23, 2013 at 4:00 PM, openstack learner <
openstacklea...@gmail.com> wrote:

> Hi all,
>
>  I am thinking about using quantum to do some network setting for the vms
> on esxi host but I am not sure if it should work or not because the *
> VMwareVCDriver* is listed as a compute driver.
>
> Last time when I enable the quantum service in my devstack installation,
> there is a boot instance failure when i tried to boot an instance.  I dont
> know the if failure is caused by my devstack setting or it arose just
> because quantum does not work with esxi.  Anyone know if quantum works with
> esxi ?
>
>
> Thank you
> xin
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Oslo PTL election

[Adam Young]

On 09/23/2013 02:37 AM, Mark McLoughlin wrote:

Hey

I meant to send this as soon as nominations opened - I figure that
incumbent PTLs should make it clear if they don't intend to nominate
themselves for re-election.

To that end - I'm not going to put myself forward for election as Oslo
PTL this time around. This is purely based on a gut instinct that doing
so will actually be better for Oslo. I still care a great deal about
Oslo's mission and will continue to work on Oslo in Icehouse, e.g. doing
reviews and getting the oslo.messaging work over the line.

I think the legacy of cut-and-paste code across OpenStack is a serious
threat to OpenStack's future progress and tackling it effectively is
going to require the help of many more of the core developers from other
projects. I'm hoping that by not being PTL, there'll be more space for
others to jump in and help drive Oslo's direction with new ideas and new
approaches.

Thanks,
Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Knowing your commitment to Open Stack, I don't feel any need to say 
"Sorry to see you go" as I know this means just an adjustment of focus 
for you.


What if we said that all core developers on other projects were 
considered core developers on Oslo?  In other words, all of OpenStack 
has a vested interest in code review of the common components.  Would 
this encourage more reviews in Oslo?  Or, would it hurt the overall 
quality of the Oslo code base?  It would certainly broaden the pool of 
developers, but there would be a need to level set the coding standards.


Another approach would be that each of the major projects "adopts" a 
subset of Oslo functionality.  For example, Keystone could claim 
responsibility for revewing Crypto and Policy changes.  I realize that 
Oslo already has a way of identifying developers that can review subsets 
of the code, but this would mean that core projects would collectively 
have more responsiblity and ownership of the Oslo libraries.








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

[openstack-dev] [Nova][vmware] VMwareAPI sub-team reviews update 2013-09-23

[Shawn Hartsock]

Greetings Stackers!

We've had a lot of merges lately in the vmwareapi folders so if you have a 
review pending there, take a moment to "git fetch --all" and rebase your patch! 
Thanks for all the attention we've been getting lately, and thanks tot he 
contributors for staying on top of their respective contributions. Here's a 
breakdown of the changes I'm tracking. First ordered by "priority" based on 
health of the driver, then ordered by the number of +1 votes.

We have 6 reviews that look like they're in good shape for a core-reviewer to 
take a look.



Ordered by bug priority:
 High/Critical https://bugs.launchpad.net/bugs/1223709 
https://review.openstack.org/46027 votes:(+2:2,+1:5,-1:0,-2:1), status: 
needs revision

 High/Critical https://bugs.launchpad.net/bugs/1226211 
https://review.openstack.org/46789 votes:(+2:1,+1:7,-1:0,-2:0), status: 
needs one more +2/approval

 High/Critical https://bugs.launchpad.net/bugs/1217541 
https://review.openstack.org/43621 votes:(+2:1,+1:2,-1:1,-2:0), status: 
needs revision

 High/High https://bugs.launchpad.net/bugs/1226052 
https://review.openstack.org/46730 votes:(+2:0,+1:2,-1:0,-2:0), status: 
needs review

 High/High https://bugs.launchpad.net/bugs/1171226 
https://review.openstack.org/43994 votes:(+2:0,+1:4,-1:0,-2:0), status: 
ready for core

 Medium/High https://bugs.launchpad.net/bugs/1207064 
https://review.openstack.org/47503 votes:(+2:1,+1:3,-1:1,-2:0), status: 
needs revision

 Medium/Medium https://bugs.launchpad.net/bugs/1199954 
https://review.openstack.org/46231 votes:(+2:1,+1:3,-1:1,-2:0), status: 
needs revision

 High https://bugs.launchpad.net/bugs/1214850 
https://review.openstack.org/43270 votes:(+2:0,+1:1,-1:0,-2:0), status: 
needs review

 High https://bugs.launchpad.net/bugs/1226826 
https://review.openstack.org/47030 votes:(+2:0,+1:5,-1:0,-2:0), status: 
ready for core

 High https://bugs.launchpad.net/bugs/1225002 
https://review.openstack.org/41977 votes:(+2:0,+1:5,-1:0,-2:0), status: 
ready for core

 High https://bugs.launchpad.net/bugs/1227825 
https://review.openstack.org/47289 votes:(+2:0,+1:2,-1:0,-2:0), status: 
needs review

 High https://bugs.launchpad.net/bugs/1194018 
https://review.openstack.org/43641 votes:(+2:1,+1:6,-1:0,-2:0), status: 
needs one more +2/approval

 trimming anything Medium or below off..


Ordered by fitness for review:

== needs one more +2/approval ==
* https://review.openstack.org/43268
title: 'VMware: enable VNC access without user having to enter pa...'
votes: +2:1, +1:3, -1:0, -2:0. +32 days in progress, revision: 13 is 1 
days old 
* https://review.openstack.org/43641
title: 'VMware: Fix ensure_vlan_bridge to work properly with exis...'
votes: +2:1, +1:6, -1:0, -2:0. +29 days in progress, revision: 14 is 6 
days old 
* https://review.openstack.org/46789
title: 'VMware: fix bug for incorrect cluster access'
votes: +2:1, +1:7, -1:0, -2:0. +7 days in progress, revision: 1 is 7 
days old 
* https://review.openstack.org/46896
title: 'Add linked clone related unit tests for VMware Hyper'
votes: +2:1, +1:5, -1:0, -2:0. +6 days in progress, revision: 1 is 6 
days old 

== ready for core ==
* https://review.openstack.org/43994
title: 'VMwareVCDriver Fix sparse disk copy error on spawn'
votes: +2:0, +1:4, -1:0, -2:0. +26 days in progress, revision: 20 is 0 
days old 
* https://review.openstack.org/47030
title: 'VMware: Fix volume detach failure'
votes: +2:0, +1:5, -1:0, -2:0. +6 days in progress, revision: 2 is 5 
days old 
* https://review.openstack.org/41977
title: 'VMware: Network fallback in case specified one not found'
votes: +2:0, +1:5, -1:0, -2:0. +40 days in progress, revision: 5 is 8 
days old 

== needs review ==
* https://review.openstack.org/43665
title: 'VMware: Check for the propSet attribute's existence befor...'
votes: +2:0, +1:2, -1:0, -2:0. +28 days in progress, revision: 6 is 2 
days old 
* https://review.openstack.org/47289
title: 'fixes datastore selection bug 1227825'
votes: +2:0, +1:2, -1:0, -2:0. +5 days in progress, revision: 8 is 0 
days old 
* https://review.openstack.org/46730
title: 'VMware: Fix bug for root disk size'
votes: +2:0, +1:2, -1:0, -2:0. +7 days in progress, revision: 10 is 1 
days old 
* https://review.openstack.org/46400
title: 'VMware: booting multiple instances fails if image is not ...'
votes: +2:0, +1:2, -1:0, -2:0. +11 days in progress, revision: 7 is 3 
days old 

== needs revision ==
* https://review.openstack.org/46824
title: 'VMware: Fix SwitchNotFound error when network exists'
votes: +2:1, +1:2, -1:1, -2:0. +7 days in progress, revision: 2 is 0 
days old 
* 

[openstack-dev] [Ceilometer] Token's project (tenant) not passed to API layer (v2.py) from auth_token.py

[Pendergrass, Eric]

Hi, I'm struggling with a problem related to tokens.  I have one token for
which the project ID gets passed to v2.MeterController.get_all() in the
kwargs:

 

(Pdb) kwargs

{'project': u'10032339952700', 'meter': u'network.outgoing.bytes'}

 

I have another token for a different tenant and the project does not get
passed in:

 

(Pdb) kwargs

{'meter': u'network.outgoing.bytes'}

 

As far as I can tell the token data is roughly the same, except for the
details about the tenant.  I'm stepping through the auth_token code trying
to find the cause.

 

Could someone point me in a direction with some possible causes for why one
token would pass the tenant and another wouldn't?

 

Thank you,

Eric Pendergrass



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Does quantum work with vmware esxi ?

[openstack learner]

Hi all,

 I am thinking about using quantum to do some network setting for the vms
on esxi host but I am not sure if it should work or not because the *
VMwareVCDriver* is listed as a compute driver.

Last time when I enable the quantum service in my devstack installation,
there is a boot instance failure when i tried to boot an instance.  I dont
know the if failure is caused by my devstack setting or it arose just
because quantum does not work with esxi.  Anyone know if quantum works with
esxi ?


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

Re: [openstack-dev] [heat] [scheduler] Bringing things together for Icehouse

[Clint Byrum]

Excerpts from Keith Bray's message of 2013-09-23 12:22:16 -0700:
> 
> I think this picture is relevant to Heat context:
> https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o
> 0R9U/edit
> 
> 
> As more and more types of compute (containers, VMs, bare metal) and other
> resources (geographically dispersed) become available from the cloud with
> boarder capabilities (e.g. regionally dispersed backups,
> failover/recovery, etc.), the concept of scheduling and optimizing
> resource placement becomes more important, particularly when a customer
> wants to deploy an application that has multiple underlying resource needs
> but doesn't want to know (or care) about specifying the details of those
> resources and their placement.
> 
> I'm not advocating that this does or does not belongs in Heat (in general
> I think Stack resource placement, region, etc., belongs with the template
> author or authoring system, and I think physical resource placement
> belongs with the underlying service, Nova, Trove, etc.), but I appreciate
> Mike including Heat on this. I for one would vote that we consider this
> "in-context" for discussion purposes, regardless of action.  Placement
> coordination across disparate resource services is likely to become a more
> prominent problem, and given Heat has the most holistic view of the
> application topology stack within the cloud, Heat may have something to
> offer in being a piece of the solution.

Just to restate what you and Zane have just said succintly: There is
definitely a need for Heat to be able to communicate to the API's any
placement details that can be communicated. However, Heat should not
actually be "scheduling" anything.

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

Re: [openstack-dev] [Openstack] Snapshot failure with VMwareVCDriver

[Shawn Hartsock]

Have you tried pulling the patch directly and retesting?

$ git fetch https://review.openstack.org/openstack/nova 
refs/changes/98/40298/18 && git checkout FETCH_HEAD

I just pulled the change by itself (for the sake of paranoia) and tested it 
manually. It works fine in isolation. For my test I used "nova image-create" 
then booted an instance from the new image. This all worked fine.

# Shawn Hartsock

- Original Message -
> From: "openstack learner" 
> To: openstack-dev@lists.openstack.org
> Sent: Monday, September 23, 2013 5:00:58 PM
> Subject: [openstack-dev] [Openstack] Snapshot failure with VMwareVCDriver
> 
> Hi all,
> 
> There was a bug fixed on the snapshot failure in* **Snapshot failure with
> VMwareVCDriver* https://review.openstack.org/#/c/40298
> 
> After git clone the newest devstack repository on sep23 2013  and reinstall
> devstack, when i did a snapshot it still failed.
> 
> This time, from the vCenter task history i could see both the  "Create
> virtual machine snapshot" and the "Copy virtual disk" operation are
> completed successfully. There was a "Copy virtual disk" operation failure
> before and now this issue is fixed in the new code i think. However, the
> snapshot stilled failed in my case.
> 
> 
> From the horizon, the new created snapshot image status was firstly
> "queued" and then "deleted". And the snapshot image is not in the list when
> i do a nova image-list, glance image-list or look at the horizon
> image&snapshot list.
> 
> From the screen "*g-reg*" log, I found it seems like the snapshot image was
> created and then deleted before glance upload the image.
> 
> The output log is shown as followed:
> 
> 2013-09-23 12:49:46.634 13386 INFO glance.registry.api.v1.images
> [61f1aefc-e56b-481e-ac5d-23e5c8a1ab6c 1e1e314becc94d2ebe8246f0a36ca99a
> 09ee20f776914ad7983bb2ace867623a] Successfully retrieved image
> 66e47135-8576-49af-a474-47a11de0c46d
> 2013-09-23 12:50:09.126 13386 DEBUG keystoneclient.middleware.auth_token
> [-] Authenticating user token __call__
> /opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py:532
> 2013-09-23 12:50:09.126 13386 DEBUG keystoneclient.middleware.auth_token
> [-] Removing headers from request environment:
> X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Project-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User-Name,X-User-Domain-Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-Tenant,X-Role
> _remove_auth_headers
> /opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py:591
> 2013-09-23 12:50:09.126 13386 DEBUG keystoneclient.middleware.auth_token
> [-] Returning cached token a06afb4e1371592a52ee6cb53b0e2bae _cache_get
> /opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py:982
> 2013-09-23 12:50:09.127 13386 DEBUG glance.api.policy [-] Loaded policy
> rules: {u'context_is_admin': 'role:admin', u'default': '@',
> u'manage_image_cache': 'role:admin'} load_rules
> /opt/stack/glance/glance/api/policy.py:75
> 2013-09-23 12:50:09.127 13386 DEBUG routes.middleware [-] Matched GET
> /images/66e47135-8576-49af-a474-47a11de0c46d __call__
> /usr/lib/python2.7/dist-packages/routes/middleware.py:100
> 2013-09-23 12:50:09.127 13386 DEBUG routes.middleware [-] Route path:
> '/images/{id}', defaults: {'action': u'show', 'controller':
> } __call__
> /usr/lib/python2.7/dist-packages/routes/middleware.py:102
> 2013-09-23 12:50:09.127 13386 DEBUG routes.middleware [-] Match dict:
> {'action': u'show', 'controller':  0x279ba50>, 'id': u'66e47135-8576-49af-a474-47a11de0c46d'} __call__
> /usr/lib/python2.7/dist-packages/routes/middleware.py:103
> 2013-09-23 12:50:09.138 13386 INFO glance.registry.api.v1.images
> [fa8c8425-0637-45cc-a80f-c188a787ad41 1e1e314becc94d2ebe8246f0a36ca99a
> 09ee20f776914ad7983bb2ace867623a] Successfully retrieved image
> 66e47135-8576-49af-a474-47a11de0c46d
> 2013-09-23 12:50:34.130 13386 DEBUG keystoneclient.middleware.auth_token
> [-] Authenticating user token __call__
> /opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py:532
> 2013-09-23 12:50:34.131 13386 DEBUG keystoneclient.middleware.auth_token
> [-] Removing headers from request environment:
> X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Project-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User-Name,X-User-Domain-Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-Tenant,X-Role
> _remove_auth_headers
> /opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py:591
> 2013-09-23 12:50:34.131 13386 DEBUG keystoneclient.middleware.auth_token
> [-] Returning cached token a06afb4e1371592a52ee6cb53b0e2bae _cache_get
> /opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py:982
> 2013-09-23 12:50:34.131 13386 DEBUG glance.api.policy [-] Loaded policy
> rules: {u'context_is_admin': 'role:admin', u'default': '@',
> u'manage_image_cache': 'role:admin'} load_ru

[openstack-dev] [Horizon] PTL Candidacy

[Gabriel Hurley]

I hereby declare my candidacy for the Horizon PTL position.

My current qualifications:

  * PTL for the Grizzly and Havana cycles.
  * Core developer on Horizon since Essex, and Keystone core since Folsom.
  * Primary architect of the existing Horizon framework.
  * Core developer for the Django web framework upon which Horizon is built.
  * Author of the "Core Values" of Horizon: 
http://docs.openstack.org/developer/horizon/intro.html
  * Extensive depth and breadth of knowledge of all of the OpenStack service 
APIs.
  * Helped shape the Keystone V3 API and Nova v3 API.
  * Provided the initial push to internationalize OpenStack as a whole in the 
Grizzly cycle which has now extended to all projects and dozens of translators.
  * Ongoing advocate for OpenStack to provide a unified and sensible experience 
for end users.
  * Highly engaged in discussions around the future of OpenStack.

Things I can't directly take credit for but which happened under my watch (and 
I'd like to think with my guidance):

  * Overall contributor base has grown steadily with each release.
  * Core team expanded significantly in size and diversity.
  * New OpenStack projects have continued to be represented in each release.
  * Translation team actively engaged.
  * UX team formed and steadily becoming an active part of the design and 
development process.
  * Essex, Folsom, Grizzly and Havana releases have all been stable, 
high-quality, on-time, and both forwards and backwards compatible.

What I see for Icehouse and beyond:

  * We have known goals for making Horizon truly event-driven. This is a large 
job and now is the time.
  * Downstream distros and large OpenStack providers have given feedback on 
their pain points; they center around packaging, configuration, and how to 
alter or "remix" the OpenStack Dashboard. We can and must improve in these 
areas.
  * More projects are entering and graduating from incubation each cycle. We 
will continue to fulfill our commitment to those projects, and the PTL must 
engage those projects leaders and their developers to drive their own 
integrations.
  * The UX community is giving great insight into how the usability of the 
dashboard can be improved as it grows. Navigation, user-oriented workflows, and 
responsive design are low-hanging fruit.
  * Providing raw data and tools are a base layer, but there are vast green 
fields for how we can anticipate user questions and needs and provide solutions 
that cover the 90% cases.
  * Visualizations and interactivity not only provide better experiences, they 
also help capture OpenStack mindshare. First impressions matter.
  * Better integration of "help" by collaborating with the Docs team connects 
the end users to the information they need when they need it most.
  * Multi-region, federation, hybrid public-private, etc. clouds are on the 
horizon (no pun intended) and we need to start thinking about these issues.

All of these lists could go on, but these are the high level items.

I want to close by saying that I'm thrilled that someone else in the Horizon 
community is interested in being PTL, and that the outcome is not a foregone 
conclusion. It is the highest order of success for a project that there are 
enough people with passion and vision that there's actually competition for the 
position.

I don't intend to be PTL forever but I believe l have the right experience and 
vision to guide Horizon through Icehouse.

Best of luck to all!

 - Gabriel

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

Re: [openstack-dev] keystone Identity API v3 OS-OAUTH1 Extension

[Miller, Mark M (EB SW Cloud - R&D - Corvallis)]

Thank you for the pointer. I have it running now.

Mark


From: Steve Martinelli [mailto:steve...@ca.ibm.com]
Sent: Monday, September 23, 2013 1:37 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] keystone Identity API v3 OS-OAUTH1 Extension


Hey Mark,

You would also have to add it to the v3 pipeline, by modifying the 
keystone-paste file. You will also need to create the necessary db tables too.

https://github.com/openstack/keystone/blob/master/doc/source/extensions/oauth1-configuration.rst


Thanks,

_
Steve Martinelli | A4-317 @ IBM Toronto Software Lab
Software Developer - OpenStack
Phone: (905) 413-2851
E-Mail: steve...@ca.ibm.com

[Inactive hide details for "Miller, Mark M (EB SW Cloud - R&D - Corvallis)" 
---09/23/2013 04:12:15 PM---Hello, I would like to t]"Miller, Mark M (EB SW 
Cloud - R&D - Corvallis)" ---09/23/2013 04:12:15 PM---Hello, I would like to 
try/test the latest Keystone OS-OAUTH1 Extension, but I have not figured out

From: "Miller, Mark M (EB SW Cloud - R&D - Corvallis)" 
mailto:mark.m.mil...@hp.com>>
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>,
Date: 09/23/2013 04:12 PM
Subject: [openstack-dev] keystone Identity API v3 OS-OAUTH1 Extension





Hello,

I would like to try/test the latest Keystone OS-OAUTH1 Extension, but I have 
not figured out how to access it with the latest H-3 code release. The 
documentation states that this extension requires v3.0+ of the Identity API. 
Questions:

1. What version of the Identity API is included in the Havana H-3 release?
2. What URL do I need to use. The following one returns a 404:  
https://havanatest:35357/v3/OS-OAUTH1/consumers
3. I have added the following lines to keystone.conf. Am I still lacking some 
configuration items?


   [oauth1]
   driver = keystone.contrib.oauth1.backends.sql.OAuth1

   [auth]
   methods = password,token,oauth1
   password = keystone.auth.plugins.password.Password
   token = keystone.auth.plugins.token.Token
   oauth1 = keystone.auth.plugins.oauth1.OAuth

Thanks,

Mark

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

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

[openstack-dev] [Openstack] Snapshot failure with VMwareVCDriver

[openstack learner]

Hi all,

There was a bug fixed on the snapshot failure in* **Snapshot failure with
VMwareVCDriver* https://review.openstack.org/#/c/40298

After git clone the newest devstack repository on sep23 2013  and reinstall
devstack, when i did a snapshot it still failed.

This time, from the vCenter task history i could see both the  "Create
virtual machine snapshot" and the "Copy virtual disk" operation are
completed successfully. There was a "Copy virtual disk" operation failure
before and now this issue is fixed in the new code i think. However, the
snapshot stilled failed in my case.


>From the horizon, the new created snapshot image status was firstly
"queued" and then "deleted". And the snapshot image is not in the list when
i do a nova image-list, glance image-list or look at the horizon
image&snapshot list.

>From the screen "*g-reg*" log, I found it seems like the snapshot image was
created and then deleted before glance upload the image.

The output log is shown as followed:

2013-09-23 12:49:46.634 13386 INFO glance.registry.api.v1.images
[61f1aefc-e56b-481e-ac5d-23e5c8a1ab6c 1e1e314becc94d2ebe8246f0a36ca99a
09ee20f776914ad7983bb2ace867623a] Successfully retrieved image
66e47135-8576-49af-a474-47a11de0c46d
2013-09-23 12:50:09.126 13386 DEBUG keystoneclient.middleware.auth_token
[-] Authenticating user token __call__
/opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py:532
2013-09-23 12:50:09.126 13386 DEBUG keystoneclient.middleware.auth_token
[-] Removing headers from request environment:
X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Project-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User-Name,X-User-Domain-Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-Tenant,X-Role
_remove_auth_headers
/opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py:591
2013-09-23 12:50:09.126 13386 DEBUG keystoneclient.middleware.auth_token
[-] Returning cached token a06afb4e1371592a52ee6cb53b0e2bae _cache_get
/opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py:982
2013-09-23 12:50:09.127 13386 DEBUG glance.api.policy [-] Loaded policy
rules: {u'context_is_admin': 'role:admin', u'default': '@',
u'manage_image_cache': 'role:admin'} load_rules
/opt/stack/glance/glance/api/policy.py:75
2013-09-23 12:50:09.127 13386 DEBUG routes.middleware [-] Matched GET
/images/66e47135-8576-49af-a474-47a11de0c46d __call__
/usr/lib/python2.7/dist-packages/routes/middleware.py:100
2013-09-23 12:50:09.127 13386 DEBUG routes.middleware [-] Route path:
'/images/{id}', defaults: {'action': u'show', 'controller':
} __call__
/usr/lib/python2.7/dist-packages/routes/middleware.py:102
2013-09-23 12:50:09.127 13386 DEBUG routes.middleware [-] Match dict:
{'action': u'show', 'controller': , 'id': u'66e47135-8576-49af-a474-47a11de0c46d'} __call__
/usr/lib/python2.7/dist-packages/routes/middleware.py:103
2013-09-23 12:50:09.138 13386 INFO glance.registry.api.v1.images
[fa8c8425-0637-45cc-a80f-c188a787ad41 1e1e314becc94d2ebe8246f0a36ca99a
09ee20f776914ad7983bb2ace867623a] Successfully retrieved image
66e47135-8576-49af-a474-47a11de0c46d
2013-09-23 12:50:34.130 13386 DEBUG keystoneclient.middleware.auth_token
[-] Authenticating user token __call__
/opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py:532
2013-09-23 12:50:34.131 13386 DEBUG keystoneclient.middleware.auth_token
[-] Removing headers from request environment:
X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Project-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User-Name,X-User-Domain-Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-Tenant,X-Role
_remove_auth_headers
/opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py:591
2013-09-23 12:50:34.131 13386 DEBUG keystoneclient.middleware.auth_token
[-] Returning cached token a06afb4e1371592a52ee6cb53b0e2bae _cache_get
/opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py:982
2013-09-23 12:50:34.131 13386 DEBUG glance.api.policy [-] Loaded policy
rules: {u'context_is_admin': 'role:admin', u'default': '@',
u'manage_image_cache': 'role:admin'} load_rules
/opt/stack/glance/glance/api/policy.py:75
2013-09-23 12:50:34.132 13386 DEBUG routes.middleware [-] Matched GET
/images/66e47135-8576-49af-a474-47a11de0c46d __call__
/usr/lib/python2.7/dist-packages/routes/middleware.py:100
2013-09-23 12:50:34.132 13386 DEBUG routes.middleware [-] Route path:
'/images/{id}', defaults: {'action': u'show', 'controller':
} __call__
/usr/lib/python2.7/dist-packages/routes/middleware.py:102
2013-09-23 12:50:34.132 13386 DEBUG routes.middleware [-] Match dict:
{'action': u'show', 'controller': , 'id': u'66e47135-8576-49af-a474-47a11de0c46d'} __call__
/usr/lib/python2.7/dist-packages/routes/middleware.py:103
2013-09-23 12:50:34.139 13386 INFO glance.registry.api.v1.images
[5d0b9eec-b064-40b2-8db7-aeeb1f88c97e 1e1e314becc94d2ebe8246f0a36ca99a
0

[openstack-dev] [Heat] PTL candidacy

[Steve Baker]

Hi

I would like to announce my candidacy for the Orchestration (Heat) PTL.

I have been a software engineer for 16 years and have been developing on
Heat for over 12 months. In this period Heat has grown from a small
project to being part of the OpenStack ecosystem with a healthy growth
in contributors and users. During this time my Heat related development
has led to productive relationships with contributors from other
projects including Horizon, Infrastructure, Documentation, QA, TripleO
and DevStack.

The Heat core team has always performed well without the need for
prescriptive leadership. Consequently, I feel that this role's primary
function is to act as the point of contact with the greater OpenStack
community. There is also a need to facilitate the process of reaching
consensus, and to advocate for areas which are being neglected. I'm
already familiar with most of the tasks of a PTL while filling in for
others on several occasions and doing release management for
python-heatclient and heat-cfntools.

Some of my activity artifacts:
https://review.openstack.org/#/q/owner:sbaker%2540redhat.com,n,z
https://review.openstack.org/#/q/reviewer:sbaker%2540redhat.com,n,z
http://russellbryant.net/openstack-stats/heat-reviewers-180.txt

Icehouse


During the next cycle, I see these activities as among those the team
need to consider:
- Growing the core team to match the level of new contributions
- Focus on documentation including a comprehensive template writers guide
- Resource implementations for all the things, ideally contributed from
outside the core developers
- Finishing the HOT template format design and implementation
- Evaluating the suitability of TaskFlow[1] for Heat
- Native autoscaling, with associated autoscaling API.
- For projects and cloud providers that adopt Heat, ensuring their needs
are being met
- Ensuring all Heat features can be used without making any reference to
CloudFormation/AWS
- Make Heat templates multi-region and multi-cloud aware

Finally, despite the overwhelming correlation, and my temporary desire
for it to remain so, it is not considered mandatory for the Heat PTL to
be called Steve.

[1] https://wiki.openstack.org/wiki/TaskFlow
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] Heat PTL election

[Steven Hardy]

Hi all,

As suggested by markmc earlier[1] it seems sensible for incumbent PTLs to
clarify their position if they are not planning to nominate themselves for
re-election.

Therefore, I'd like to confirm that I do not plan to put myself forward as
Heat PTL for the Icehouse cycle.

Heat is fortunate in that we have an extremely strong core team, with
several members who I'm sure would do a great job serving as PTL.

When I stepped into the role, we had discussions about the idea of rotating
the PTL responsibility, and since I'm confident that at least one of those
folks plans to nominate themselves, I'm happy to step aside and concentrate
on coding for Icehouse :)

I remain very much committed to the Heat project, I'm looking forward to
continuing my work as a core reviewer and contributor.

Thanks,

Steve

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2013-September/015478.html

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

Re: [openstack-dev] keystone Identity API v3 OS-OAUTH1 Extension

[Steve Martinelli]

Hey Mark,

You would also have to add it to the v3 pipeline, by modifying the
keystone-paste file. You will also need to create the necessary db tables
too.

https://github.com/openstack/keystone/blob/master/doc/source/extensions/oauth1-configuration.rst



Thanks,

_
Steve Martinelli | A4-317 @ IBM Toronto Software Lab
Software Developer - OpenStack
Phone: (905) 413-2851
E-Mail: steve...@ca.ibm.com



From:   "Miller, Mark M (EB SW Cloud - R&D - Corvallis)"

To: OpenStack Development Mailing List
,
Date:   09/23/2013 04:12 PM
Subject:[openstack-dev] keystone Identity API v3 OS-OAUTH1 Extension



Hello,

I would like to try/test the latest Keystone OS-OAUTH1 Extension, but I
have not figured out how to access it with the latest H-3 code release. The
documentation states that this extension requires v3.0+ of the Identity
API. Questions:

1. What version of the Identity API is included in the Havana H-3 release?
2. What URL do I need to use. The following one returns a 404:
https://havanatest:35357/v3/OS-OAUTH1/consumers
3. I have added the following lines to keystone.conf. Am I still lacking
some configuration items?


[oauth1]
driver = keystone.contrib.oauth1.backends.sql.OAuth1

[auth]
methods = password,token,oauth1
password = keystone.auth.plugins.password.Password
token = keystone.auth.plugins.token.Token
oauth1 = keystone.auth.plugins.oauth1.OAuth

Thanks,

Mark

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

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

[openstack-dev] keystone Identity API v3 OS-OAUTH1 Extension

[Miller, Mark M (EB SW Cloud - R&D - Corvallis)]

Hello,

I would like to try/test the latest Keystone OS-OAUTH1 Extension, but I have 
not figured out how to access it with the latest H-3 code release. The 
documentation states that this extension requires v3.0+ of the Identity API. 
Questions:

1. What version of the Identity API is included in the Havana H-3 release? 
2. What URL do I need to use. The following one returns a 404:  
https://havanatest:35357/v3/OS-OAUTH1/consumers
3. I have added the following lines to keystone.conf. Am I still lacking some 
configuration items?


[oauth1]
driver = keystone.contrib.oauth1.backends.sql.OAuth1

[auth]
methods = password,token,oauth1
password = keystone.auth.plugins.password.Password
token = keystone.auth.plugins.token.Token
oauth1 = keystone.auth.plugins.oauth1.OAuth

Thanks,

Mark

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

[openstack-dev] [scheduler] Smart Resource Placement Vision - high level overview document

[Yathiraj Udupi (yudupi)]

Hi,

We have written a high-level vision document for Smart Resource Placement in 
Openstack.  This covers all the required solutions, and how it relates to some 
of the proposed blueprints.
So this is an attempt to bring the bits together, so that we can collaborate 
and work towards bringing all of this together.

Please review: 
https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit?usp=sharing

Provides additional details for our proposal of a unified constraints-based 
resource placement engine.

Thanks,
Yathi.



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

[openstack-dev] [Savanna][EDP] Issues from internal UI demo

[Nadya Privalova]

Hello folks,
Today I've showed a demo with EDP UI. Here a feedback from our
Mirantis-team.  Items without NOTEs should be done, I believe. For some of
them bugs are already filed:

1. We need URL hints for DataSouce (as it done for JobBinary)
2. DataSource UI should depend on DataSource type (
https://wiki.openstack.org/w/images/6/62/DataSourceCreation.jpg)
3. Usability issue. User should create DataSource each time. Each time he
or she should set auth info for DataSource. It will be better to split
DataSource on two objects: DataSourceAuth and DataSourceeURL. *NOTE: that's
just a proposal*
4. JobBinary TODOs:
4.1. Remove  swift-external option (we will not support it in current
phase)
4.2 *NOTE: that's just a proposal: *Hide swift-internal option if Swift
is not available
4.3. *NOTE: that's just a proposal: *Set available storage for binaries
in savanna.conf. Becuase it's  unlikely to store binaries in db-internal if
swift is available
4.4 People wants to write scripts in Horizon (h :/)
5. Job contains now:
name
description
type
job_origin_id
input_type
output_type
job_configs

Type is determined by JobOrigin. input_type and output_type are determined
by JobExecution's DataSources. So, remove Job. Changes in objects after
that:
in JobExecution:
job_id ===> job_origin_id

in JobOrigin:
type appears

6. Config for job. Configs will be key-value. We will get user a hint about
configs that user may use but  user may set it's own. That's because we are
not sure where to get all possible job.xml configs.

Tomorrow I'm planning to resolve 5th.

Your feedback will be very appreciated
Thanks,
Nadya
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Climate] Use Taskflow for leases start/end ?

[Joshua Harlow]

Howdy there!

Taskflow currently should be ready for usage, its not a pypi library yet, I am 
hoping for a 0.1 release soon (maybe 2 weeksish).

But in the meantime it does have a similar `update.py` as oslo-incubator, so 
you can use that to start integrating.

Jump in #openstack-state-management if u have any questions, here to help!

-Josh

From: Sylvain Bauza mailto:sylvain.ba...@bull.net>>
Reply-To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, September 23, 2013 12:20 AM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Climate] Use Taskflow for leases start/end ?

I can't agree more. My point was not using it for v1, but just make sure 
everoybody in the team is aware of that kind of transactional framework.

On a second pro, it would make sense to conceptualize transaction model and 
think on a move later, even if we're still yet not using it :-)


Taskflow ppl, do you have any kind of code freeze deadline which could give us 
a glance on when the first release will be ready for use ?

Thanks,
-Sylvain

Le 22/09/2013 09:39, Dina Belova a écrit :
Hi all,

I think that TaskFlow is an interesting initiative that could provide us some 
benefits like good encapsulation of logical code blocks, better exception 
handling and management of actions taking place in Climate core, rollbacks and 
replays management.

It looks like that we should initially understand our workflows in Climate and 
then decide if we should use TaskFlow for them or not.


On Thu, Sep 19, 2013 at 4:54 PM, Sylvain Bauza 
mailto:sylvain.ba...@bull.net>> wrote:
Hi Climate team,

I just went through https://wiki.openstack.org/wiki/TaskFlow
Do you think Taskflow could help us in providing ressources defined in the 
lease on an atomic way ?

We could leave the implementation up to the plugins, but maybe the Lease 
Manager could also benefit of it.

-Sylvain

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




--

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.



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

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

[openstack-dev] [tuskar] pecan models vs. db models

[Petr Blaho]

Hi,

during my work on getting tests to pass for
https://review.openstack.org/#/c/46947/ I discovered that we are
misusing pecan models for HTTP representation of Resources.

In controllers pecan/wsme calls actions with pecan model prepopulated
from HTTP request's params.

For example, when creating new Rack, post
method in Racks controller is called with rack object
( 
https://github.com/stackforge/tuskar/blob/master/tuskar/api/controllers/v1/rack.py#L26-L31
 ).
This object is instance of Rack from
https://github.com/stackforge/tuskar/blob/master/tuskar/api/controllers/v1/types/rack.py
.
Next this object is used in pecan.request.dbapi.create_rack(rack) call
(method defined here
https://github.com/stackforge/tuskar/blob/master/tuskar/db/sqlalchemy/api.py#L385-L431
)

This method just assumes that new_rack object (passed from controller)
has some attributes with getters defined (name, subnet, location, ...).

This is fine if we have 1-1 relationship between how resource is stored
in db and how it is represented via HTTP. In fact this assumes that both
versions have the same set of atributes.

Marios wrote a patch (mentioned above) which needs some internal
attributes only, ie. present in table but not exposed via HTTP.

In that moment I found that we use pecan models (
https://github.com/stackforge/tuskar/tree/master/tuskar/api/controllers/v1/types
 )
to transfer HTTP params _directly_ to our db layer
( https://github.com/stackforge/tuskar/blob/master/tuskar/db/sqlalchemy/api.py 
).
By _directly_ I mean that we assume 1-1 mapping between attributes in
pecan models and db models.

This is not to be true anymore. We can solve it by using conditionals like
this
https://review.openstack.org/#/c/46947/3/tuskar/db/sqlalchemy/api.py
(lines 175 to 181) but I think this is not good solution b/c of repetion
of code and generaly we are mixing up HTTP repr. with db repr.

I propose to write a simple layer responsible for "translating" pecan
models into db representation. This way we can keep all diffs in what
attributes are exposed via HTTP and which not in one place - easy to
see, easy to change, easy to review. To scatter it around dbapi code
is not a good way IMHO.


Another issue which comes with this coupling of pecan/db models is in
tests.

In db tests we use utility helpers for creating resources in memory, ie
create_test_resource_class method (
https://github.com/stackforge/tuskar/blob/master/tuskar/tests/db/test_db_racks.py#L28
). This kind of methods comes from "from tuskar.tests.db import utils"
and they use pecan models (
https://github.com/stackforge/tuskar/blob/master/tuskar/tests/db/utils.py#L17-L23
 ).
We are now on the same page as mentioned above. These db tests uses
Relation and Link pecan models which means that easy solution like
importing db models instead of pecan models is not doable at the moment
b/c db models do not contains direct counterparts for Relation and Link.


I am pretty woried about this pecan-db models coupling b/c if (or when)
we will need more different stuctures on HTTP side than on db side (no
1-1 relationship) we will have to change our code and tests more.

I hope that we will find a solution for this sooner than tuskar code
will grow more complex.


I would like to see something like "service objects" in controller part
but simple set of "translations" can be ok if we do not break 1-1 parity too
much.

Tests will require more attention b/c of that Relation and Link pecan
objects.


Thank you for your patience with reading this and looking for a
feedback. Maybe I missed something or I see this bigger than it really
is or I am totally out :-)

-- 
Petr Blaho, pbl...@redhat.com
Software Engineer

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

Re: [openstack-dev] [heat] [scheduler] Bringing things together for Icehouse

[Keith Bray]

I think this picture is relevant to Heat context:
https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o
0R9U/edit


As more and more types of compute (containers, VMs, bare metal) and other
resources (geographically dispersed) become available from the cloud with
boarder capabilities (e.g. regionally dispersed backups,
failover/recovery, etc.), the concept of scheduling and optimizing
resource placement becomes more important, particularly when a customer
wants to deploy an application that has multiple underlying resource needs
but doesn't want to know (or care) about specifying the details of those
resources and their placement.

I'm not advocating that this does or does not belongs in Heat (in general
I think Stack resource placement, region, etc., belongs with the template
author or authoring system, and I think physical resource placement
belongs with the underlying service, Nova, Trove, etc.), but I appreciate
Mike including Heat on this. I for one would vote that we consider this
"in-context" for discussion purposes, regardless of action.  Placement
coordination across disparate resource services is likely to become a more
prominent problem, and given Heat has the most holistic view of the
application topology stack within the cloud, Heat may have something to
offer in being a piece of the solution.

Kind regards,
-Keith


On 9/23/13 11:22 AM, "Zane Bitter"  wrote:

>On 15/09/13 09:19, Mike Spreitzer wrote:
>> But first I must admit that I am still a newbie to OpenStack, and still
>> am missing some important clues.  One thing that mystifies me is this: I
>> see essentially the same thing, which I have generally taken to calling
>> holistic scheduling, discussed in two mostly separate contexts: (1) the
>> (nova) scheduler context, and (2) the ambitions for heat.  What am I
>> missing?
>
>I think what you're missing is that the only person discussing this in
>the context of Heat is you. Beyond exposing the scheduling parameters in
>other APIs to the user, there's nothing here for Heat to do.
>
>So if you take [heat] out of the subject line then it will be discussed
>in only one context, and you will be mystified no longer. Hope that helps
>:)
>
>cheers,
>Zane.
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] Client and Policy

[Doug Hellmann]

On Mon, Sep 23, 2013 at 4:25 AM, Flavio Percoco  wrote:

> On 20/09/13 15:20 -0700, Monty Taylor wrote:
>
>> On 09/20/2013 02:55 PM, Ben Nemec wrote:
>>
>>> Not from a Gerrit perspective, but the Oslo policy is that a maintainer
>>> +1 on the code they maintain is the equivalent of a +2, so only one core
>>> is needed to approve.
>>>
>>> See https://github.com/openstack/**oslo-incubator/blob/master/**
>>> MAINTAINERS#L28
>>>
>>
>> What if we rethought the organization just a little bit. Instead of
>> having oslo-incubator from which we copy code, and then oslo.* that we
>> consume as libraries, what if:
>>
>> - we split all oslo modules into their own repos from the start
>>
>
> IIRC, we're planning to have a design session around these lines at
> the summit. I think the only issue here is figuring out where some
> modules belong. For example, where would we put strutils? Should we
> have a single repo for it or perhaps have a more generic one, say
> oslo.text, were we could group strutils, jsonutils and some other
> modules?
>
> There are plenty of "single-file" packages out there but I'd
> personally prefer grouping modules as much as possible.
>

I agree.


>
> Another thing to consider is, what happens with Oslo modules depending
> on other oslo modules? I guess we would make sure all the dependencies
> are copied in the project as we do today but, when it comes to testing
> the single module, I think this could be an issue. For example,
> policy.py depends on fileutils, gettextutils and other oslo module
> which wouldn't fit in the same package, oslo.policy. This will make
> testing oslo.policy a real pain since we would have to "copy" its
> dependencies in its own tree as well.


This is a great reason to keep everything together in a single incubator
repository until a package is ready to stand on its own as a library.
Libraries can easily declare dependencies to be installed for testing, but
if we start copying bits of oslo around into separate git repositories then
we'll all go mad trying to keep all of the repos up to date. :-) In the
mean time, any review pain we have can be used as encouragement to bring
the library to a point where it can be moved out of the incubator.

It sounds like the primary concern is having enough keystone folks looking
at reviews of the policy code, without being overwhelmed by tracking all
Oslo changes. There are a couple of ways to address that.

The policy code seems very tightly associated with the keystone work.
There's no reason for Oslo to be the only program releasing reusable
libraries. We should consider having the Keystone team manage the policy
library in a repo they own. I'd love to have the Keystone middleware work
the same way, instead of being in the client repo, but one step at a time.

Of course, if the policy code is nearing the point where it is ready to
graduate from the incubator, then maybe that suggestion is moot and we
should just continue to push ahead on the path we're on now. We could have
people submitting policy code to oslo-incubator add "keystone-core" to
reviews (adding a group automatically adds its members), so they don't have
to subscribe to oslo notifications.

How close is the policy code to being ready to graduate?

Doug


>
>
>  - we make update.py a utility that groks copying from a directory that
>> contains a bunch of repos - so that a person wanting to use is might have:
>>  ~/src
>>  ~/src/oslo
>>  ~/src/oslo/oslo.db
>>  ~/src/oslo/oslo.policy
>>  and then when they run update.py ~/src/oslo ~/src/nova and get the
>> same results (the copying and name changing and whatnot)
>>
>
> If we split modules in its own repos, I'd rather use git submodules,
> which would then work better.


>
>
>> That way, we can add per-module additional core easily like we can for
>> released oslo modules (like hacking and pbr have now)
>>
>
> +1
>
>
>
>> Also, that would mean that moving from copying to releasing is more a
>> matter of just making a release than it is of doing the git magic to
>> split the repo out into a separate one and then adding the new repo to
>> gerrit.
>>
>>
> +1
>
>  Thoughts?
>>
>
> I like the idea overall, I'm a bit worried about how those modules
> would be organized.
>
> Any thoughts about the above concerns?
>
>
> Cheers,
> FF
>
> --
> @flaper87
> Flavio Percoco
>
> __**_
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.**org 
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tuskar] pecan models vs. db models

[Doug Hellmann]

On Mon, Sep 23, 2013 at 12:31 PM, Petr Blaho  wrote:

> Hi,
>
> during my work on getting tests to pass for
> https://review.openstack.org/#/c/46947/ I discovered that we are
> misusing pecan models for HTTP representation of Resources.
>
> In controllers pecan/wsme calls actions with pecan model prepopulated
> from HTTP request's params.
>
> For example, when creating new Rack, post
> method in Racks controller is called with rack object
> (
> https://github.com/stackforge/tuskar/blob/master/tuskar/api/controllers/v1/rack.py#L26-L31).
> This object is instance of Rack from
>
> https://github.com/stackforge/tuskar/blob/master/tuskar/api/controllers/v1/types/rack.py
> .
> Next this object is used in pecan.request.dbapi.create_rack(rack) call
> (method defined here
>
> https://github.com/stackforge/tuskar/blob/master/tuskar/db/sqlalchemy/api.py#L385-L431
> )
>
> This method just assumes that new_rack object (passed from controller)
> has some attributes with getters defined (name, subnet, location, ...).
>
> This is fine if we have 1-1 relationship between how resource is stored
> in db and how it is represented via HTTP. In fact this assumes that both
> versions have the same set of atributes.
>
> Marios wrote a patch (mentioned above) which needs some internal
> attributes only, ie. present in table but not exposed via HTTP.
>
> In that moment I found that we use pecan models (
>
> https://github.com/stackforge/tuskar/tree/master/tuskar/api/controllers/v1/types)
> to transfer HTTP params _directly_ to our db layer
> (
> https://github.com/stackforge/tuskar/blob/master/tuskar/db/sqlalchemy/api.py).
> By _directly_ I mean that we assume 1-1 mapping between attributes in
> pecan models and db models.
>
> This is not to be true anymore. We can solve it by using conditionals like
> this
> https://review.openstack.org/#/c/46947/3/tuskar/db/sqlalchemy/api.py
> (lines 175 to 181) but I think this is not good solution b/c of repetion
> of code and generaly we are mixing up HTTP repr. with db repr.
>
> I propose to write a simple layer responsible for "translating" pecan
> models into db representation. This way we can keep all diffs in what
> attributes are exposed via HTTP and which not in one place - easy to
> see, easy to change, easy to review. To scatter it around dbapi code
> is not a good way IMHO.


>
> Another issue which comes with this coupling of pecan/db models is in
> tests.
>
> In db tests we use utility helpers for creating resources in memory, ie
> create_test_resource_class method (
>
> https://github.com/stackforge/tuskar/blob/master/tuskar/tests/db/test_db_racks.py#L28
> ). This kind of methods comes from "from tuskar.tests.db import utils"
> and they use pecan models (
>
> https://github.com/stackforge/tuskar/blob/master/tuskar/tests/db/utils.py#L17-L23).
> We are now on the same page as mentioned above. These db tests uses
> Relation and Link pecan models which means that easy solution like
> importing db models instead of pecan models is not doable at the moment
> b/c db models do not contains direct counterparts for Relation and Link.
>
>
> I am pretty woried about this pecan-db models coupling b/c if (or when)
> we will need more different stuctures on HTTP side than on db side (no
> 1-1 relationship) we will have to change our code and tests more.
>
> I hope that we will find a solution for this sooner than tuskar code
> will grow more complex.
>
>
> I would like to see something like "service objects" in controller part
> but simple set of "translations" can be ok if we do not break 1-1 parity
> too
> much.
>

Yes, you definitely do not want to be using WSME models in the storage
layer. In addition to the issues you've already discovered with the
database schema not mapping directly to the API schema, it will force the
storage code to depend on web front-end code.

In ceilometer, we solved this problem by creating a separate set of models
for the storage layer:
https://github.com/openstack/ceilometer/blob/master/ceilometer/storage/models.py

These are standalone objects, rather than sqlalchemy models, because we
support multiple storage backends. At this point most of the objects are
very simple data containers, but we used classes instead of dictionaries to
ensure that all of the storage plugins behaved consistently (early on, we
had a couple of drivers providing dictionaries with extra or missing keys).

The conversion between storage and API models is done in the API layer:
https://github.com/openstack/ceilometer/blob/master/ceilometer/api/controllers/v2.py

The base WSME model has a "from_db_model()" method that lets you create an
API object from a DB object. I could easily see creating a similar method
to create a DB object from an API object, but it looks like we did that
conversion within a Pecan controller method where we could validate the
inputs more easily.

Doug


>
> Tests will require more attention b/c of that Relation and Link pecan
> objects.
>
>
> Thank you for your pati

Re: [openstack-dev] [cinder]The inconsistency between cinder client v1 and v2 supported arguments.

[Mike Perez]

On Mon, Sep 23, 2013 at 12:18 AM, Da Zhao Y Yu  wrote:

> Hi all,
>
> When I was fixing bug 1221611, current codeReview link. I found in
> CinderClient component, there are many inconsistent arguments in v1 and v2
> shell.py.
>
> Consider backwards compatibility and consistency, I think we need to fix
> this problem. For convenience, I made the following list of v1/v2 arguments
> inconsistency,
> please review it, the folks who have better understanding of the CLI
> client history please provide more insights on how to deal with current
> situation. Thanks!
>

We're moving towards dashes in the optional argument name with v2. In v1,
optional args that don't support underscores can be changed to do so, but
they should still support what they originally supported for compatibility.


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

Re: [openstack-dev] [heat] [scheduler] Bringing things together for Icehouse

[Zane Bitter]

On 15/09/13 09:19, Mike Spreitzer wrote:

But first I must admit that I am still a newbie to OpenStack, and still
am missing some important clues.  One thing that mystifies me is this: I
see essentially the same thing, which I have generally taken to calling
holistic scheduling, discussed in two mostly separate contexts: (1) the
(nova) scheduler context, and (2) the ambitions for heat.  What am I
missing?


I think what you're missing is that the only person discussing this in 
the context of Heat is you. Beyond exposing the scheduling parameters in 
other APIs to the user, there's nothing here for Heat to do.


So if you take [heat] out of the subject line then it will be discussed 
in only one context, and you will be mystified no longer. Hope that helps :)


cheers,
Zane.

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

Re: [openstack-dev] [heat] cross-stack references

[Zane Bitter]

On 18/09/13 19:34, Mike Spreitzer wrote:

When we get into things like affinity concerns or managing network
bandwidth, we see the need for cross-stack relationships.  You may want
to place parts of a new stack near parts of an existing one, for
example.  I see that in CFN you can make cross-references between
different parts of a single stack using the resource names that appear
in the original template.  Is there a way to refer to something that did
not come from the same original template?  If not, won't we need such a
thing to be introduced?  Any thoughts on how that would be done?


Yes, you can do this now. In fact, nothing in a template should be 
making cross-references using only the resource name. Instead you should 
use {"Ref": "resource_name"}. The value returned by this varies, but in 
most cases it is just the UUID of the resource. You can return this 
value in an output, and you can use an input of the same form (i.e. a 
UUID in most cases) in place of a Ref to a local resource in cases where 
you want to refer to an existing resource instead of one managed by the 
template. A similar story applied to attributes (which are just strings) 
and Fn::GetAtt.


There's no magic in a template, it's just functions that manipulate strings.

cheers,
Zane.


Fine Print:
We violate this rule in a number of places in Heat, mostly where there's 
no real underlying OpenStack API for a given resource type so we've had 
to implement the resource within Heat. CloudFormation does not make this 
mistake, and I hope to clean up as many of these as possible over time. 
However, none of these are likely relevant to the use case you have in mind.


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

[openstack-dev] Is "python setup.py intsall" recommended way to install Neutron Server in dev environment?

[Vijay Venkatachalam]

Hi,
I am new to openstack, please pardon if the questions are dumb.

Attempting to run a neutron dev setup with openvswitch plugin with VLAN 
isolation and 2 hosts.

DISCLAIMER: I am not using devstack. Attempting to install the services in a 
controller node  - Ubuntu12.04 VM.


1.   In the controller node

a)  Services horizon/keystone/glance are installed using "apt-get". Yet to 
install nova.

b)  Also in addition, for development needs, we have cloned neutron from 
github

c)   ran "python setup.py install"
# Is this the recommended way? This seems to have installed all agents  
"/usr/local/bin/neutron-*-agent"s as well in  Controller Node.
Thanks,
Vijay V.




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

Re: [openstack-dev] [Tuskar] [UI] Identifying metrics to show in Tuskar UI detail pages

[Ladislav Smola]

Liz,

thank you very much for this, I will try to sort this and pick the ones, 
that will need to be implemented in Ceilometer. Will comment the etherpad.


FYI there are only two Agents, that collects Hardware related data now.
This one is almost complete:
https://blueprints.launchpad.net/ceilometer/+spec/monitoring-physical-devices
This one has just started:
https://blueprints.launchpad.net/ceilometer/+spec/ipmi-inspector-for-monitoring-physical-devices

Thank you,
Ladislav

On 09/23/2013 04:55 PM, Liz Blanchard wrote:

Ladislav & All,

I've spent some time the last few days trying to identify the metrics that a 
user would want to view around the details pages for Resource Classes, Racks, 
and Nodes. The notes have been captured here, where I've also tried to call out 
the items that are available in Ceilometer currently:
https://etherpad.openstack.org/tuskar-metrics

A lot of these metrics seem as though they will need to be calculated as 
aggregates of metrics that are currently available, but some are completely 
new, I think. Please take a look as you have time and feel free to comment and 
add things to this etherpad if you identify any metrics that should be shown in 
these views.

I hope to have some basic wireframes based on these metrics to review with the 
UX community and UI team by the end of the week.

Thanks,
Liz


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

[openstack-dev] [Murano] Meeting Minutes 2013-09-23

[Timur Nurlygayanov]

Hello,

Below, you can see the meeting minutes from today's Murano meeting.

Minutes:
http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-09-23-15.04.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-09-23-15.04.txt
Log:
http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-09-23-15.04.log.html

The next meeting will be held at 30th Sep.

-- 

Timur,
QA Lead
OpenStack Murano Project
Mirantis Inc
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Tuskar] [UI] Identifying metrics to show in Tuskar UI detail pages

[Liz Blanchard]

Ladislav & All,

I've spent some time the last few days trying to identify the metrics that a 
user would want to view around the details pages for Resource Classes, Racks, 
and Nodes. The notes have been captured here, where I've also tried to call out 
the items that are available in Ceilometer currently:
https://etherpad.openstack.org/tuskar-metrics

A lot of these metrics seem as though they will need to be calculated as 
aggregates of metrics that are currently available, but some are completely 
new, I think. Please take a look as you have time and feel free to comment and 
add things to this etherpad if you identify any metrics that should be shown in 
these views.

I hope to have some basic wireframes based on these metrics to review with the 
UX community and UI team by the end of the week.

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

Re: [openstack-dev] unable to run tox due to the '--pre' argument

[Monty Taylor]

On 09/23/2013 12:14 AM, Zhongyue Luo wrote:
> Looks like this problem happens in systems that use pip<1.4 but upgraded
> tox to 1.6.1
> 
> http://tox.readthedocs.org/en/latest/config.html#confval-install_command=ARGV

Yes. We have been rolling out tox.ini changes to projects. I'll push one
up for neutronclient right now...

https://review.openstack.org/47848

This change should essentially be ported in to all projects. I'm getting
to it slowly, but if other people want to step up and do that too, I'd
welcome the help!

> On Fri, Sep 20, 2013 at 12:47 AM, Jeremy Stanley  > wrote:
> 
> On 2013-09-19 09:24:08 +0800 (+0800), Yongsheng Gong wrote:
> [...]
> > I upgrade the pip into 1.4.1:
> >
> > gongysh@gongysh-ThinkPad-T530:/opt/stack/python-neutronclient$
> > .tox/py27/bin/pip install -U pip
> > gongysh@gongysh-ThinkPad-T530:/opt/stack/python-neutronclient$
> > .tox/py27/bin/pip  --version
> > pip 1.4.1 from /mnt/data/opt/stack/python-neutronclient/.tox/py27
> > /lib/python2.7/site-packages (python 2.7)
> [...]
> > Then I run tox -e py27 and it failed:
> [...]
> > I check the pip version in .tox:
> > gongysh@gongysh-ThinkPad-T530:/mnt/data/opt/stack/
> > python-neutronclient$  .tox/py27/bin/pip --version
> > pip 1.3.1 from /mnt/data/opt/stack/python-neutronclient/.tox/py27
> > /lib/python2.7/site-packages/pip-1.3.1-py2.7.egg (python 2.7)
> >
> > It is changed back!!!
> 
> I've tried to reproduce this and it doesn't seem to happen for me.
> Using tox 1.6.1 to run 'tox -e py27' in a current checkout of
> python-neutronclient's master branch automatically installs pip
> 1.4.1 in the virtualenv it creates. Can you try this on another
> machine/vm just for confirmation? Clark also suggested on IRC just
> now that maybe you have some global tox configuration specifying to
> always recreate the virtualenv (essentially -r) and that its
> populating it with your system-installed version or perhaps an older
> cached download.
> --
> Jeremy Stanley
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> *Intel SSG/STOD/DCST/CIT*
> 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
> China
> +862161166500
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

[openstack-dev] [Ceilometer][IceHouse] Ceilometer + Kibana + ElasticSearch Integration

[Sandy Walsh]

Nachi ... love it!

It would be very cool to see how this would work with Events, since they
have much more metadata associated with them.

This is the sort of stuff I think we should be doing a lot more of.
There are so many excellent open source monitoring components out there.
Better integration with them should be our focus. Let people assemble
the monitoring stack they want.

Recently Logstash also joined Kibana, so that's going to make it even
better.

-S

---

Sorry for the new thread. Got dropped from openstack-dev and only found
this from the archive.

From
http://lists.openstack.org/pipermail/openstack-dev/2013-September/015042.html


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

Re: [openstack-dev] [Openstack-docs] [Docs] Documentation PTL Candidacy

[Emilien Macchi]

+1

Anne is doing without any doubt an amazing job on OpenStack manuals.

Thank you Anne,

Emilien Macchi

# OpenStack Engineer
// eNovance Inc.  http://enovance.com
// ? emil...@enovance.com ? +33 (0)1 49 70 99 80
// 10 rue de la Victoire 75009 Paris

On 09/22/2013 08:19 PM, Anne Gentle wrote:
> Hi all, 
> I'm writing to declare my intention to run for OpenStack documentation
> program technical lead. [1]
>
> I've been working on OpenStack docs since September 2010, and it has
> been an honor and a privilege to serve in this position informally
> prior to having documentation declared a program. I've been serving as
> the interim PTL as encouraged by my doc peers. 
>
> In Havana we've been hard at work (and continue to do so), refactoring
> the openstack-manuals repo to ensure installation, configuration, and
> administration info is as complete and accurate as we can, including
> the addition of automation tools for gathering configuration options
> into one location.
>
> We've added an End User Guide, an Admin User Guide, and a Cloud
> Administration Guide to document OpenStack as a whole, including all
> the clients and the things you can do with your OpenStack clouds
> through command-line calls. 
>
> We also work on API documentation to bring you a compete reference
> listing of all OpenStack APIs including example requests and responses.
>
> In the last year we've held two successful book sprints in the past
> year resulting in the OpenStack Operations Guide and the OpenStack
> Security Guide. We're actively recruiting writers for a book sprint to
> write an OpenStack Architecture Design Guide. The Operations Guide has
> been translated to Chinese and Japanese.
>
> I believe the documentation PTL role is one of coordination, coaching,
> and providing platforms for documentation. This doesn't happen in
> isolation and requires constant attention and coordination. I do know
> our shortcomings and continue to work through the difficulties we face
> trying to document a fast-moving integrated set of projects. In the
> future I'd like to recruit more upstream OpenStack writers and have
> designated project doc leads. 
>
> I continue to be the top committer to the openstack-manuals repo [2]
> and I am an active reviewer of all docs repos. [3]
>
> I'm proud of the work we've done so far and would be privileged to
> continue this most challenging work. 
> Thanks,
> Anne
>
> 1. Wow, that sounds too formal, but that's what this email is. 
> 2. https://github.com/openstack/openstack-manuals/graphs/contributors
> 3. https://review.openstack.org/#/q/reviewer:anne%2540openstack.org,n,z
>
>
>
> ___
> Openstack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Ceilometer Alarm management page

[Julien Danjou]

On Thu, Sep 19 2013, Ladislav Smola wrote:

Hi Ladislav,

Sorry for the late reply,

> 1. The points 1-4 from are some sort simple version of the page, that uses
> all basic alarm-api features. Do you think we need them all? Any feedback
> for them? Enhancements?

That looks like a really good start if we can have all of this!

> 2. There is a thought, that we should maybe divide Alarms into (System,
> User-defined). The only system alarms now, are set up with Heat and used for
> auto-scaling.

I don't think there is any formal way to distinguish alarms. Though it's
likely you can retrieve the alarm list Heat created for the user to
distinguish them.
On the other hand, I am not sure the user can see the alarms created by
Heat since they might not directly belong to the user, but to Heat.

> 3. There is a thought about watching correlation of multiple alarm histories
> in one Chart (either Alarm Histories, or the real statistics the Alarm is
> defined by). Do you think it will be needed? Any real life examples you have
> in mind?

I think the first use case is to debug combined alarms.
There's also a lot of potential to debug an entire platform activity by
superimposing several alarm graphs.

> 4. There is a thought about tagging the alarms by user defined tag, so user
> can easily group alarms together and then watch them together based on their
> tag.

The alarm API don't provide that directly, but you can imagine some sort
of filter based on description matching some texts.

> 5. There is a thought about generating a default alarms, that could observe
> the most important things (verifying good behaviour, showing bad behaviour).
> Does anybody have an idea which alarms could be the most important and
> usable for everybody?

I'm not sure you want to create alarm by default; alarm are resources, I
don't think we should create resources without the user asking for it.

Maybe you were talking about generating alarm template? You could start
with things like CPU usage staying at >90% for more than 1 hour, and
having an action that alerts the user via mail.
Same for disk usage.

> 6. There is a thought about making overview pages customizable by the users,
> so they can really observe, what they need. (includes Ceilometer statistics
> and alarms)

I think that could be as easy as picking the alarms you want in
overviews with a very small and narrowed graph.

-- 
Julien Danjou
/* Free Software hacker * independent consultant
   http://julien.danjou.info */


signature.asc
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Questions about plans for heat wadls moving forward

[Mike Asthalter]

Hi Anne & Steve,

I already have removing the "original" heal WADL in my work plan.

I am just waiting for the released version of the clouddocs maven plugin to be 
fixed (1.10.0) to support pulling the wadl content into the  api-ref doc 
(https://github.com/openstack/heat/blob/master/doc/docbkx/api-ref/src/docbkx/api-ref.xml)
 from the orchestration wadl in the api-ref site.

Mike

From: Steven Dake mailto:sd...@redhat.com>>
Reply-To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, September 20, 2013 2:46 PM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Cc: Anne Gentle 
mailto:annegen...@justwriteclick.com>>
Subject: Re: [openstack-dev] [Heat] Questions about plans for heat wadls moving 
forward

On 09/13/2013 01:21 PM, Anne Gentle wrote:



On Fri, Sep 13, 2013 at 1:53 PM, Mike Asthalter 
mailto:mike.asthal...@rackspace.com>> wrote:
Hi Anne,

I want to make sure I've understood the ramifications of your statement about 
content sharing.

So for now, until the infrastructure team provides us with a method to share 
content between repos, the only way to share the content from the orchestration 
wadl with the api-ref doc 
(https://github.com/openstack/heat/blob/master/doc/docbkx/api-ref/src/docbkx/api-ref.xml)
 is to manually copy the content from the orchestration wadl to the original 
heat wadl and then use that for the shared content. So we will not delete the 
original heat wadl until that new method of content sharing is in place. Is 
this correct?


Hi Mike,
It sounds like the dev team is fine with deleting that "original" heat WADL and 
only maintaining one from here forward.

The way they will control Icehouse edits to the heat WADL that shouldn't yet be 
displayed to end users is to use the "Work In Progress" button on 
review.openstack.org. When a patch is marked WIP, 
you can't merge it.

So, you can safely delete the original Heat WADL and then from your dev guides, 
if you want to include a WADL, you can point to the one in the api-site 
repository. We now have a mirror of the github.com 
repository at git.openstack.org that gives you access 
to the WADL in the api-site repository at all times. I can walk you through 
building the URL that points to the WADL file.


Anne,

Sorry for delay in response - I've been traveling.  I will submit a change to 
remove the wadl from the heat repo since  the api-site is finished.

Regards
-steve

What we also need to build is logic in the build jobs so that any time the 
api-site WADL is updated, your dev guide is also updated. This is done in the 
Jenkins job in 
https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/api-jobs.yaml.
 I can either submit this patch for you, or I'll ask Steve or Zane to do so.

Hope this helps -

Anne


Thanks!

Mike

From: Anne Gentle 
mailto:annegen...@justwriteclick.com>>
Reply-To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, September 12, 2013 11:32 PM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Heat] Questions about plans for heat wadls moving 
forward




On Thu, Sep 12, 2013 at 10:41 PM, Monty Taylor 
mailto:mord...@inaugust.com>> wrote:


On 09/12/2013 04:33 PM, Steve Baker wrote:
> On 09/13/2013 08:28 AM, Mike Asthalter wrote:
>> Hello,
>>
>> Can someone please explain the plans for our 2 wadls moving forward:
>>
>>   * wadl in original heat
>> repo: 
>> https://github.com/openstack/heat/blob/master/doc/docbkx/api-ref/src/wadls/heat-api/src/heat-api-1.0.wadl
>> 
>> <%22https://github.com/openstack/heat/blob/master/doc/docbkx/api-ref/src/wadls/heat-api/src/heat-api-1.>
>>   * wadl in api-site
>> repo: 
>> https://github.com/openstack/api-site/blob/master/api-ref/src/wadls/orchestration-api/src/v1/orchestration-api.wadl
>>
> The original intention was to delete the heat wadl when the api-site one
> became merged.

Sounds good.

>> 1. Is there a need to maintain 2 wadls moving forward, with the wadl
>> in the original heat repo containing calls that may not be
>> implemented, and the wadl in the api-site repo containing implemented
>> calls only?
>>
>> Anne Gentle advises as follows in regard to these 2 wadls:
>>
>> "I'd like the WADL in api-site repo to be user-facing. The other
>> WADL can be truth if it needs to be a specification that's not yet
>> implemented. If the WADL in api-site repo is true and implemented,
>> please just maintain one going forward."
>>
>>
>> 2. If we maintain 2 wadls, what are the consequences (gerrit reviews,
>> docs out of sync, etc.)?
>>
>> 3. If we maintain only the 1 orchestration wadl, how do we want to
>> pull in the wadl content to the api-ref doc
>> (https://github.com/openstack/heat/blob/master/doc/docbkx/api-ref/src/docbkx

Re: [openstack-dev] [nova][libvirt] Should file injection work for boot from volume images?

[Russell Bryant]

On 09/21/2013 12:02 AM, Pádraig Brady wrote:
> On 09/20/2013 10:47 PM, Michael Still wrote:
>> Before https://review.openstack.org/#/c/46867/ if file injection of a
>> mandatory file fails, nova just silently ignores the failure, which is
>> clearly wrong. 
> 
> For reference, the original code you're adjusting is
> https://review.openstack.org/#/c/18900
> BTW, I'm not sure of your adjustments but that's beside the point
> and best left for discussion at the above review.
> 
>> However, that review now can't land because its
>> revealed another failure in the file injection code via tempest, which
>> is...
>>
>> Should file injection work for instances which are boot from volume?
> 
> For consistency probably yes.
> 
>> Now that we actually notice injection failures we're now failing to
>> boot such instances as file injection for them doesn't work.
>>
>> I'm undecided though -- should file injection work for boot from
>> volume at all? Or should we just skip file injection for instances
>> like this? I'd prefer to see us just support config drive and metadata
>> server for these instances, but perhaps I am missing something really
>> important.
> 
> Now I wouldn't put too much effort into new file injection mechanisms,
> but in this case it might be easy enough to support injection to volumes.
> In fact there was already an attempt made at:
> https://review.openstack.org/#/c/33221/

I agree with Monty and Thierry that ideally file injection should DIAF
everywhere.  On that note, have we done anything with that in the v3
API?  I propose we remove it completely.

However, I also agree with Pádraig here that for the sake of
consistency, as long as file injection is supported, I would expect this
to work.

-- 
Russell Bryant

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

Re: [openstack-dev] sqlalchemy version regression

[Pádraig Brady]

On 09/23/2013 06:48 AM, Thomas Goirand wrote:
> On 09/23/2013 01:36 PM, Thomas Goirand wrote:
>> On 09/23/2013 11:04 AM, Pádraig Brady wrote:
>>> OpenStack should be compatible with sqlalchemy 0.8.x at this stage,
>>> or should be easily tweaked to be so.
>>
>> My view as well.
>>
>>> sqlalchemy-migrate will be a bit awkward though as upstream
>>> seems to have moved to alembic and is no longer that interested in 
>>> maintenance/releases.
>>> So what would be the best way to handle that?
>>
>> This has already been discussed in July:
>> http://lists.openstack.org/pipermail/openstack-dev/2013-July/011755.html
>>
>> However, I'm not sure how the plan went through.
>>
>>> For distros it's easy, just patch their latest python-migrate-0.7.2 
>>> packages with:
>>> http://pkgs.fedoraproject.org/cgit/python-migrate.git/plain/python-migrate-sqlalchemy-0.8.patch
>>> and maybe this for postgres support too:
>>> http://www.mergely.com/editor?lhs=https://raw.github.com/lugensa/sqlalchemy-migrate/1f87b7c4/migrate/changeset/ansisql.py&rhs=https://raw.github.com/lugensa/sqlalchemy-migrate/master/migrate/changeset/ansisql.py
>>
>> Is this the new upstream repository?
>>
>> I have already applied some patches to fix sqlalchemy-migrate wrt
>> sqlalchemy 0.8 in Debian. I believe that was enough to make it work.
>>
>> Thomas
> 
> Having a deeper look, I have found:
> https://github.com/stackforge/sqlalchemy-migrate

Cool, and both the above patches are already there.
The first with:
  https://github.com/stackforge/sqlalchemy-migrate/commit/2ff11c17
  https://github.com/stackforge/sqlalchemy-migrate/commit/74ccf7a3
The second (which I have an untested alternative for) at:
  
https://github.com/stackforge/sqlalchemy-migrate/commit/c670d1d3#commitcomment-4154121

> However, there's no new release. Could someone tag and release a new version

I suppose we might tag/use a version between 0.7.2 >= and <= 0.7.3
to allow official upstream to release in future without clashes?
Or do we use 0.8... to indicate sqlalchemy 0.8 compat?

Oh I see we've pypi creds for this too:
http://lists.openstack.org/pipermail/openstack-dev/2013-July/011767.html
So we can control versions from now on?

> so that it can be packaged in Debian?

I'd update Fedora/EPEL to use that release if available too.

thanks!
Pádraig.

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

[openstack-dev] [RelCycleMgmt] PTL Candidacy

[Thierry Carrez]

Hi,

I'm writing to announce my candidacy for the "Release Cycle Management"
program technical lead position.

"Release Cycle Management" is a set of activities around OpenStack
release and maintenance which have been formalized into an official
"program" a few months ago, and I've been serving as its acting PTL so
far. It is composed of the following activities:

* Release management
This activity is about coordinating the development cycle, creating a
release schedule, communicating and enforcing the common rhythm,
extracting and publishing feature roadmaps, and documenting our
development community shared understandings. I've been filling those
duties starting with the Bexar release cycle, and it's safe to say that
it's been an interesting ride. The challenges ahead of us are about
really scaling this activity to more than one person, as we keep on
adding projects: working more as a team than as an individual on those
issues.

* Stable branch maintenance
This activity is about helping our downstream consumers (OpenStack
distributions) by providing reference points in time (stable branches)
that we backport critical bugfixes to (and publish point releases for).
It is lead by Alan Pevec and Adam Gandelman. The challenges ahead of us
are about attracting new contributors while keeping the high "safe
patches" standards of our stable branch policy.

* Vulnerability management
This activity is about triaging incoming security vulnerability reports
and getting security patches and advisories published (as fast and
safely as we can produce them). I've been leading that team from its
inception (but would definitely like to hand out the leading of this
activity to someone else!). The challenges ahead of us are to refresh
our policy in the age of "programs", and to grow the team. It's quite
difficult to find people combining the security mindset, the process
obsession and the deep involvement in the OpenStack community that is
necessary to succeed in this role, so we need to keep on looking :)

If I'm elected to the PTL position, I intend to focus on those
challenges. I would also like to codify contributions to this new
program (by attaching code repositories to it, to which active members
would end up naturally contributing) so that the team ends up being more
open and less co-opted. Finally, I would like to reinforce program team
spirit: make it the work of a real group of people working together
rather than a loose collection of activities.

Regards,

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [horizon]

[Deepak Selvaraj]

Hi Stackers,

I am newbiee to Openstack and I just wanted to know if there is any Horizon
developer available to help me with the implementation of a minor
modification in Horizon ? I am stuck with the authentication part when I am
trying to modify Horizon with federated access. I am nearing the deadline,
is there anyone who can freelance the project ? Please let me know

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

Re: [openstack-dev] [Glance]

[Thierry Carrez]

Vitaliy Kolosov wrote:
> Hi, guys.
> 
> Please, review my changes:
> https://review.openstack.org/#/c/46064/
> https://review.openstack.org/#/c/46066/
> https://review.openstack.org/#/c/46072/

Looks like my previous warning went ignored, so I'll boilerplate it in
specific replies now:

"""
We've seen a lot of "review requests" on the mailing-list lately. These
create noise and should be pretty useless.

Core reviewers already receive emails about things they should review,
and use tools to prioritize their review queue. If you'd like someone in
particular to review things, send an email to them or ping them on IRC.
If you'd like to get your review prioritized up, chiming in in the
corresponding weekly team meeting should be a hundred times more
efficient. But sending something which duplicates the automatic email
notification is ineffective and creates ML noise (which is a pain for
everyone).
"""

Regards,

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [Ceilometer] PTL candidacy

[Julien Danjou]

Hi,

I hereby would like to announce my candidacy for the Ceilometer PTL.

I am the current Ceilometer PTL. While I had no clue what to expect six
months ago, I've enjoyed having so many problems to solve over the last
development cycle. ;-)

Our team continued to grow during the Havana cycle, and we managed to
bring the project to a new stage at an amazing speed (alarm evaluation,
events handling…), while improving the project quality overall (new gate
checks, etc).

I wish we can continue to make this project successful. We still have a
lot of subjects to tackle that I would like we accomplish during
Icehouse; and I'd be glad to lead the way.

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


signature.asc
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][libvirt] Should file injection work for boot from volume images?

[Thierry Carrez]

Monty Taylor wrote:
> On 09/20/2013 02:47 PM, Michael Still wrote:
>> Before https://review.openstack.org/#/c/46867/ if file injection of a
>> mandatory file fails, nova just silently ignores the failure, which is
>> clearly wrong. However, that review now can't land because its
>> revealed another failure in the file injection code via tempest, which
>> is...
>>
>> Should file injection work for instances which are boot from volume?
>> Now that we actually notice injection failures we're now failing to
>> boot such instances as file injection for them doesn't work.
>>
>> I'm undecided though -- should file injection work for boot from
>> volume at all? Or should we just skip file injection for instances
>> like this? I'd prefer to see us just support config drive and metadata
>> server for these instances, but perhaps I am missing something really
>> important.
> 
> Well, first of all, I think file injection should DIAF everywhere.

+1

> That said, it may be no surprise that I think boot-from-volume should
> just do config drive and metadata.

That sounds like the simplest way to preserve behavior. From what you
said the current behavior is "try, fail and ignore failure" -- having
noop instead is probably the right thing to do for havana.

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [Glance]

[Vitaliy Kolosov]

Hi, guys.

Please, review my changes:
https://review.openstack.org/#/c/46064/
https://review.openstack.org/#/c/46066/
https://review.openstack.org/#/c/46072/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Client and Policy

[Flavio Percoco]

On 20/09/13 15:20 -0700, Monty Taylor wrote:

On 09/20/2013 02:55 PM, Ben Nemec wrote:

Not from a Gerrit perspective, but the Oslo policy is that a maintainer
+1 on the code they maintain is the equivalent of a +2, so only one core
is needed to approve.

See https://github.com/openstack/oslo-incubator/blob/master/MAINTAINERS#L28


What if we rethought the organization just a little bit. Instead of
having oslo-incubator from which we copy code, and then oslo.* that we
consume as libraries, what if:

- we split all oslo modules into their own repos from the start


IIRC, we're planning to have a design session around these lines at
the summit. I think the only issue here is figuring out where some
modules belong. For example, where would we put strutils? Should we
have a single repo for it or perhaps have a more generic one, say
oslo.text, were we could group strutils, jsonutils and some other
modules?

There are plenty of "single-file" packages out there but I'd
personally prefer grouping modules as much as possible.

Another thing to consider is, what happens with Oslo modules depending
on other oslo modules? I guess we would make sure all the dependencies
are copied in the project as we do today but, when it comes to testing
the single module, I think this could be an issue. For example,
policy.py depends on fileutils, gettextutils and other oslo module
which wouldn't fit in the same package, oslo.policy. This will make
testing oslo.policy a real pain since we would have to "copy" its
dependencies in its own tree as well.


- we make update.py a utility that groks copying from a directory that
contains a bunch of repos - so that a person wanting to use is might have:
 ~/src
 ~/src/oslo
 ~/src/oslo/oslo.db
 ~/src/oslo/oslo.policy
 and then when they run update.py ~/src/oslo ~/src/nova and get the
same results (the copying and name changing and whatnot)


If we split modules in its own repos, I'd rather use git submodules,
which would then work better.



That way, we can add per-module additional core easily like we can for
released oslo modules (like hacking and pbr have now)


+1



Also, that would mean that moving from copying to releasing is more a
matter of just making a release than it is of doing the git magic to
split the repo out into a separate one and then adding the new repo to
gerrit.



+1


Thoughts?


I like the idea overall, I'm a bit worried about how those modules
would be organized.

Any thoughts about the above concerns?

Cheers,
FF

--
@flaper87
Flavio Percoco

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

[openstack-dev] [cinder]The inconsistency between cinder client v1 and v2 supported arguments.

[Da Zhao Y Yu]

Hi all,

When I was fixing bug 1221611, current codeReview link. I found in 
CinderClient component, there are many inconsistent arguments in v1 and v2 
shell.py.

Consider backwards compatibility and consistency, I think we need to fix 
this problem. For convenience, I made the following list of v1/v2 
arguments inconsistency, 
please review it, the folks who have better understanding of the CLI 
client history please provide more insights on how to deal with current 
situation. Thanks!


Method
V1
V2
do_rename
Only support "--display-description" argument, do not support 
"--display_description"
Support both ("--display-description" and "--display_description")
do_snapshot_list
Do not support "--display_name" and "--volume_id" argument
Support both
do_snapshot_rename
Do not support "--display_description"
Support "--display_description"
do_upload_image
Do not support "--container_format" "--disk_format" and  "--image_name"
Support these arguments
 
Thanks & Best Regards
Yu Da Zhao(于大钊)
--
Cloud Solutions & OpenStack Development
China Systems & Technology Laboratory in Beijing
Email: d...@cn.ibm.com
Tel:   (86)10-82450677
--
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Climate] Use Taskflow for leases start/end ?

[Sylvain Bauza]

I can't agree more. My point was not using it for v1, but just make sure 
everoybody in the team is aware of that kind of transactional framework.


On a second pro, it would make sense to conceptualize transaction model 
and think on a move later, even if we're still yet not using it :-)



Taskflow ppl, do you have any kind of code freeze deadline which could 
give us a glance on when the first release will be ready for use ?


Thanks,
-Sylvain

Le 22/09/2013 09:39, Dina Belova a écrit :

Hi all,

I think that TaskFlow is an interesting initiative that could provide 
us some benefits like good encapsulation of logical code blocks, 
better exception handling and management of actions taking place in 
Climate core, rollbacks and replays management.


It looks like that we should initially understand our workflows in 
Climate and then decide if we should use TaskFlow for them or not.



On Thu, Sep 19, 2013 at 4:54 PM, Sylvain Bauza > wrote:


Hi Climate team,

I just went through https://wiki.openstack.org/wiki/TaskFlow
Do you think Taskflow could help us in providing ressources
defined in the lease on an atomic way ?

We could leave the implementation up to the plugins, but maybe the
Lease Manager could also benefit of it.

-Sylvain

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

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




--

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.



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


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