Re: [openstack-dev] [nova][vmware][qa] vmware nsx CI appears gone

[Gary Kotton]

Hi,
We have an infra issue - seems related to
https://review.openstack.org/190047 - we are investigating.
Thanks
Gary

On 9/1/15, 5:58 PM, "Matt Riedemann"  wrote:

>I haven't seen the vmware nsx CI reporting on anything in awhile but
>don't see any outage events here:
>
>https://wiki.openstack.org/wiki/NovaVMware/Minesweeper/Status
>
>Is there some status?
>
>-- 
>
>Thanks,
>
>Matt Riedemann
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Heat] Use block_device_mapping_v2 for swap?

[Rabi Mishra]

Rabi Mishra
+91-7757924167

- Original Message -
> On 31/08/15 11:19, TIANTIAN wrote:
> > 
> > 
> > At 2015-08-28 21:48:11, "marios"  wrote:
> >> I am working with the OS::Nova::Server resource and looking at the tests
> >> [1], it should be possible to just define 'swap_size' and get a swap
> >> space created on the instance:
> >>
> >>  NovaCompute:
> >>type: OS::Nova::Server
> >>properties:
> >>  image:
> >>{get_param: Image}
> >>  ...
> >>  block_device_mapping_v2:
> >>- swap_size: 1
> >>
> >> When trying this the first thing I hit is a validation code nit that is
> >> already fixed @ [2] (I have slightly older heat) and I applied that fix.
> >> However, when I try and deploy with a Flavor that has a 2MB swap for
> >> example, and with the above template, I still end up with a 2MB swap.
> >>
> >> Am I right in my assumption that the above template is the equivalent of
> >> specifying --swap on the nova boot cli (i.e. should this work?)? I am
> >> working with the Ironic nova driver btw and when deploying using the
> >> nova cli using --swap works; has anyone used/tested this property
> >> recently? I'm not yet sure if this is worth filing a bug for yet.
> > 
> >>
> > --According to the codes of heat and novaclient, the above template is
> > the equivalent of
> >specifying --swap on the nova boot cli:
> > https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/shell.py#L142-L146
> > https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/nova/server.py#L822-L831
> > 
> > 
> > But don't know much about nova, and not sure how does nova behave if
> > specified different swap size on Flavor
> > 
> > 
> > and Bdm.
> 
> Hey TianTian, thanks very much for the pointers and sanity check. Yeah I
> think it is intended to work that way (e.g. the tests on the heatclient
> also cover this as per my original), I was mostly looking for 'yeah did
> this recently worked ok for me'.

Hi Marios,

This seems to work fine with master and I do see swap created with size of the
'swap_size' specified in the template. 

[fedora@test-stack-novacompute-nwownbcokzra ~]$ swapon -s
FilenameTypeSizeUsedPriority
/dev/vdbpartition   524284  0   -1


Though I did face a novaclient issue with python-novaclient==2.26.0.

The above issue has been resolved by the below commit.
https://github.com/openstack/python-novaclient/commit/0a8fbaa48083ba2e79abf67096efa59fa18b

When specifying swap_size more than that permitted by the flavor we get
'CREATE_FAILED' with the following error. So I assume it works as expected.


resources.NovaCompute: Swap drive requested is larger   
|
|   | than instance type allows. (HTTP 400) (Request-ID: 
req- |
|   | 276150f5-082d-4c00-bb73-645c59e52727) 
 


Thanks,
Rabi

> WRT the different swap size on flavor, in this case what is on the
> flavor becomes the effective maximum you can specify (and can override
> with --swap on the nova cli).
> 
> thanks! marios
> 
> > 
> > 
> >> thanks very much for reading! marios > >[1]
> >> >https://github.com/openstack/heat/blob/a1819ff0696635c516d0eb1c59fa4f70cae27d65/heat/tests/nova/test_server.py#L2446
> >> >[2]
> >> >https://review.openstack.org/#/q/I2c538161d88a51022b91b584f16c1439848e7ada,n,z
> >> >
> >> >__
> >> >OpenStack Development Mailing List (not for usage questions)
> >> >Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [mistral] Displaying wf hierarchy in CLI

[Renat Akhmerov]

> On 01 Sep 2015, at 22:21, Lingxian Kong  wrote:
> 
> To achieve that, we should record the execution/task-execution relationship 
> during an execution is running, because we have no such info currently.

Well, in DB model we, in fact, have a field pointing to parent task execution 
id (and hence we can figure out workflow execution id easily), it’s required 
because child workflow needs to communicate its result to its parent workflow 
somehow. But it’s not displayed anywhere. So we can use this field.


Renat Akhmerov
@ Mirantis Inc.

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

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

[Chen, Wei D]

Dolph,



Ignore these arbitrary query string is what we did in keystone, current 
implementation did something deliberately to ignore them 
instead of passing them into the backend driver (If these parameter go to 
backend driver we will get nothing for sure), there might be 
no model answer for this situation, but I guess there must be some 
consideration at that time, do you still remember the concerns 
around this?





Best Regards,

Dave Chen



From: Dolph Mathews [mailto:dolph.math...@gmail.com]
Sent: Wednesday, September 02, 2015 9:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [api][keystone][openstackclient] Standards for 
object name attributes and filtering



Does anyone have an example of an API outside of OpenStack that would return 
400 in this situation (arbitrary query string 
parameters)? Based on my past experience, I'd expect them to be ignored, but I 
can't think of a reason why a 400 would be a bad idea 
(but I suspect there's some prior art / discussion out there).



On Mon, Aug 31, 2015 at 10:53 AM, Ryan Brown  wrote:

On 08/27/2015 11:28 PM, Chen, Wei D wrote:
>
> I agree that return 400 is good idea, thus client user would know what 
> happened.
>

+1, I think a 400 is the sensible choice here. It'd be much more likely
to help devs catch their errors .

--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.


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





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

[openstack-dev] [Neutron] Un-addressed Port spec and implementation

[Gal Sagie]

Hello All,

The un-addressed port spec [1] was approved for Liberty.
I think this spec has good potential to provide very interesting solutions
for NFV use cases
but also for multi site connectivity and i would really want to see
it move forward with the community.

There are some issues we need to discuss regarding L2 population (both for
the reference
implementation and for any "SDN" solution), but we can iterate on them.

This email relates to a recent revert [2] that was done to prevent spoofing
possibility
due to recent work that was merged.

If i understand the problem correctly, an un-addressed port can now perform
ARP spoofing
on an address of a port that already exists in the same network and listen
to its traffic.
(a problem which becomes bigger with shared network among tenants)

One possible solution we could do to prevent this is to keep flow entries
that block the port
from pretending to have an IP that is already part of the network (or
subnet).
So there will be ARP spoofing checks that check the port is not answering
for an IP that is already
configured.
*Any thoughts/comments on that?*

Unrelated to this, i think that an un-address port should work in subnet
context when it comes
to L2 population and traffic forwarding, so that un-address port only gets
traffic for addresses
that are not found, but are on the same subnet as the un-address port.
(I understand this is a bigger challenge and is not working with the way
Neutron networks
work today, but we can iterate on this as well since its unrelated to the
security subject)

Thanks
Gal.

[1]
https://github.com/openstack/neutron-specs/blob/master/specs/liberty/unaddressed-port.rst
[2] https://review.openstack.org/#/c/218470/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] Displaying wf hierarchy in CLI

[Renat Akhmerov]

> On 31 Aug 2015, at 23:47, Joshua Harlow  wrote:
> 
> Would u guys have any use for the following being split out into its own 
> library?
> 
> https://github.com/openstack/taskflow/blob/master/taskflow/types/tree.py

Do you mean we could move this, for instance, into oslo somewhere? Taskflow 
itself is in oslo as well, of course, I rather mean “somewhere else in oslo”.

> It already has a pformat method that could be used to do your drawing of the 
> 'tree'...
> 
> http://docs.openstack.org/developer/taskflow/types.html#taskflow.types.tree.Node.pformat
> 
> Might be useful for u folks? Taskflow uses it to be able to show information 
> that is tree-like to the developer/user for similar purposes (it also 
> supports using pydot to dump things out in dot graph format):
> 
> For example http://tempsend.com/A8AA89F397/4663/car.pdf is the graph of an 
> example (in particular 
> https://github.com/openstack/taskflow/blob/master/taskflow/examples/build_a_car.py)

Yeah, that looks interesting. I think it can work out for our case. We just 
need to come to agreement on what exactly we want to display.

Thanks, Joshua.


Renat Akhmerov
@ Mirantis Inc.


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

Re: [openstack-dev] [mistral] Displaying wf hierarchy in CLI

[Lingxian Kong]

Hi, Renat,

I want to make it clear. Then, what you want to see is dependencies between
workflow executions? or task executions in one workflow? We know that we
could use a separate task or a workflow as a 'task'.

On Wed, Sep 2, 2015 at 3:33 PM, Renat Akhmerov 
wrote:

>
> On 01 Sep 2015, at 22:21, Lingxian Kong  wrote:
>
> To achieve that, we should record the execution/task-execution
> relationship during an execution is running, because we have no such info
> currently.
>
>
> Well, in DB model we, in fact, have a field pointing to parent task
> execution id (and hence we can figure out workflow execution id easily),
> it’s required because child workflow needs to communicate its result to its
> parent workflow somehow. But it’s not displayed anywhere. So we can use
> this field.
>
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [Fuel][Fuel-Library] Nominating Alex Schultz to Fuel-Library Core

[Sergii Golovatiuk]

Hi,

I would like to nominate Alex Schultz to Fuel-Library Core team. He’s been
doing a great job in writing patches. At the same time his reviews are
solid with comments for further improvements. He’s #3 reviewer and #1
contributor with 46 commits for last 90 days [1]. Additionally, Alex has
been very active in IRC providing great ideas. His ‘librarian’ blueprint
[3] made a big step towards to puppet community.

Fuel Library, please vote with +1/-1 for approval/objection. Voting will be
open until September 9th. This will go forward after voting is closed if
there are no objections.

Overall contribution:
[0] http://stackalytics.com/?user_id=alex-schultz
Fuel library contribution for last 90 days:
[1] http://stackalytics.com/report/contribution/fuel-library/90
List of reviews:
[2]
https://review.openstack.org/#/q/reviewer:%22Alex+Schultz%22+status:merged,n,z
‘Librarian activities’ in mailing list:
[3] http://lists.openstack.org/pipermail/openstack-dev/2015-July/071058.html

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] convergence rally test results (so far)

[Steven Hardy]

On Wed, Sep 02, 2015 at 04:33:36PM +1200, Robert Collins wrote:
> On 2 September 2015 at 11:53, Angus Salkeld  wrote:
> 
> > 1. limit the number of resource actions in parallel (maybe base on the
> > number of cores)
> 
> I'm having trouble mapping that back to 'and heat-engine is running on
> 3 separate servers'.

I think Angus was responding to my test feedback, which was a different
setup, one 4-core laptop running heat-engine with 4 worker processes.

In that environment, the level of additional concurrency becomes a problem
because all heat workers become so busy that creating a large stack
DoSes the Heat services, and in my case also the DB.

If we had a configurable option, similar to num_engine_workers, which
enabled control of the number of resource actions in parallel, I probably
could have controlled that explosion in activity to a more managable series
of tasks, e.g I'd set num_resource_actions to (num_engine_workers*2) or
something.

Steve

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

[openstack-dev] [Neutron] Port forwarding

[Gal Sagie]

Hello All,

I have searched and found many past efforts to implement port forwarding in
Neutron.
I have found two incomplete blueprints [1], [2] and an abandoned patch [3].

There is even a project in Stackforge [4], [5] that claims
to implement this, but the L3 parts in it seems older then current master.

I have recently came across this requirement for various use cases, one of
them is
providing feature compliance with Docker port-mapping feature (for Kuryr),
and saving floating
IP's space.
There has been many discussions in the past that require this feature, so i
assume
there is a demand to make this formal, just a small examples [6], [7], [8],
[9]

The idea in a nutshell is to support port forwarding (TCP/UDP ports) on the
external router
leg from the public network to internal ports, so user can use one Floating
IP (the external
gateway router interface IP) and reach different internal ports depending
on the port numbers.
This should happen on the network node (and can also be leveraged for
security reasons).

I think that the POC implementation in the Stackforge project shows that
this needs to be
implemented inside the L3 parts of the current reference implementation, it
will be hard
to maintain something like that in an external repository.
(I also think that the API/DB extensions should be close to the current L3
reference
implementation)

I would like to renew the efforts on this feature and propose a RFE and a
spec for this to the
next release, any comments/ideas/thoughts are welcome.
And of course if any of the people interested or any of the people that
worked on this before
want to join the effort, you are more then welcome to join and comment.

Thanks
Gal.

[1] https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding
[2] https://blueprints.launchpad.net/neutron/+spec/fip-portforwarding
[3] https://review.openstack.org/#/c/60512/
[4] https://github.com/stackforge/networking-portforwarding
[5] https://review.openstack.org/#/q/port+forwarding,n,z

[6]
https://ask.openstack.org/en/question/75190/neutron-port-forwarding-qrouter-vms/
[7] http://www.gossamer-threads.com/lists/openstack/dev/34307
[8]
http://openstack.10931.n7.nabble.com/Neutron-port-forwarding-for-router-td46639.html
[9]
http://openstack.10931.n7.nabble.com/Neutron-port-forwarding-from-gateway-to-internal-hosts-td32410.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Code review process in Fuel and related issues

[Igor Kalnitsky]

It won't work that way. You either busy on writing code / leading
feature or doing review. It couldn't be combined effectively. Any
context switch between activities requires an extra time to focus on.

On Wed, Sep 2, 2015 at 5:46 AM, Tomasz Napierala
 wrote:
>> On 01 Sep 2015, at 03:43, Igor Kalnitsky  wrote:
>>
>> Hi folks,
>>
>> So basically..
>>
>> * core reviewers won't be feature leads anymore
>> * core reviewers won't be assigned to features (or at least not full-time)
>> * core reviewers will spend time doing review and participate design meetings
>> * core reviewers will spend time triaging bugs
>>
>> Is that correct?
>>
>
> From what I understand, it is not correct. Core reviewer will still do all 
> this activities in most cases. What we are trying to achieve, is to get 
> core's attention only to reviews, that are already reviewed by SMEs and 
> peers. We
> hope this will increase the quality of code core reviewers are getting.
>
> Regards,
> --
> Tomasz 'Zen' Napierala
> Product Engineering - Poland
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [cinder][ThirdPartyCI]CloudFounders OpenvStorage CI - request to re-add the cinder driver

[Eduard Matei]

Hi,

Trying to get more attention to this ...

We had our driver removed by commit:
https://github.com/openstack/cinder/commit/f0ab819732d77a8a6dd1a91422ac183ac4894419
due to no CI.

Pls let me know if there is something wrong so we can fix it asap so we can
have the driver back in Liberty (if possible).

The CI is commenting using the name "Open vStorage CI" instead of
"CloudFounders OpenvStorage CI".

Thanks,

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

[openstack-dev] [Swift] ObjectController::async_update() latest change

[Kirubakaran Kaliannan]

Hi,

Regarding
https://github.com/openstack/swift/commit/2289137164231d7872731c2cf3d81b86f34f01a4

I am profiling each section of the swift code. Notice
ObjectController::async_update()has high latency, and tried to use threads
to parallelize the container_update. Noticed the above changes, and I
profiled the above code changes as well.

On my set up, per container async_update takes 2 to 4 millisecond and takes
9-11 ms to complete the 3 asyncupdate’s. With the above changes it came down
to 7 to 9 ms, but I am expecting this to go further below to 4ms at least.

1.  Do we have any latency number for the improvement on the above change ?
2.  Trying to understand the possibility, do we really want to wait for all
async_update()to complete ? can we just return success, once when one
async_update() is successful ?


Thanks,
-kiru

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

Re: [openstack-dev] [Blazar] Anyone interested?

[Sylvain Bauza]

Le 02/09/2015 17:50, Pierre Riteau a écrit :
On 1 Sep 2015, at 23:15, Sylvain Bauza > wrote:



Le 01/09/2015 22:31, Ildikó Váncsa a écrit :

Hi,

I'm glad to see the interest and I also support the idea of using 
the IRC channel that is already set up for further communication. 
Should we aim for a meeting/discussion there around the end of this 
week or during next week?


@Nikolay, Sylvain: Thanks for support and bringing together a list 
of action items as very first steps.


@Pierre: You wrote that you are using Blazar. Are you using it as is 
with an older version of OpenStack or you have a modified version of 
the project/code?
I'm actually really surprised to 
seehttps://www.chameleoncloud.org/docs/user-guides/bare-metal-user-guide/which 
describes quite fine how to use Blazar/Climate either using the CLI 
or by Horizon.


The latter is actually not provided within the git tree, so I guess 
Chameleon added it downstream. That's fine, maybe something we could 
upstream if Pierre and his team are okay ?


-Sylvain


We are using a modified version of Blazar (based on the latest master 
branch commit) with OpenStack Juno (RDO packaging).


The only really mandatory patch that we had to develop was for 
blazar-nova due to functions moving from oslo-incubator to oslo.i18n: 
https://github.com/ChameleonCloud/blazar-nova/commit/346627320e87c8e067db6e842935d243c9640e6e
On top of this we developed a number of patches, most of them to fix 
bugs that we discovered in Blazar, with a few to get specific features 
or behavior required for Chameleon.


We also used the code developed by Pablo 
(http://lists.openstack.org/pipermail/openstack-dev/2014-June/038506.html) 
to provide an Horizon dashboard for creating and managing leases.
We even developed a Gantt chart of physical node reservations, but 
this code reads data straight from the SQL database rather than using 
a new Blazar API, so it cannot be contributed as is.


We have always wanted to contribute back our improvements to Blazar 
and we are looking forward to it now that there is renewed interest 
from the community.
All our OpenStack code should already be available on GitHub at 
https://github.com/ChameleonCloud/




That's great work, thanks for the explanations Pierre.
Since you're looking like the Blazar maintainer while Winter was coming, 
I'd certainly consider your commitment as enough trustable for being 
backported to the master branch.


Nikolay, you told that the Blazar gate is broken, right ? I take that as 
action #0 to fix, and then we can try to backport Pierre's changes into 
the master branch.


Now, let's switch over IRC, I don't want to pollute the ML for those 
technical details.


Anyone who still wants to contribute to Blazar can join 
#openstack-blazar and yell, for sure.


-Sylvain


Pierre



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


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

Re: [openstack-dev] [glance] image-create --is-public removed?

[Neil Jerram]

Thanks, Nikhil.  I've been (repeatedly) cloning and using devstack from
scratch, on a fresh VM.  So 'the version of your glanceclient' is
whatever the latest devstack uses.

In case anyone is hitting this, it seems the correct replacement for
'--is-public=true' is '--visibility public'.

Regards,
Neil


On 02/09/15 16:03, Nikhil Komawar wrote:
> You should check the version of your glanceclient.
>
> `glance help` will give you help on most commands. Seems like you may
> have upgraded your client and now it defaults to v2 of the server API.
>
> You can track updates using the release on pypi and related
> documentation on [1]; announcements are on the openstack-announce ML.
>
> [1] http://docs.openstack.org/developer/python-glanceclient/
>
> On 9/2/15 10:42 AM, Neil Jerram wrote:
>> Was the --is-public option to 'glance image-create ...' just removed? 
>> I've been running Devstack successfully during the last week, but now
>> see this:
>>
>> glance: error: unrecognized arguments: --is-public=true
>>
>> from running this:
>>
>> wget
>> http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-disk.img -O
>> - | glance image-create --name=cirros-0.3.2-x86_64 --disk-format=qcow2 \
>>   --container-format=bare --is-public=true
>>
>> So, some questions:
>>
>> - Is it correct that this option has just been removed?
>> - Where should I be looking / tracking to see announcements of changes
>> like this?
>> - Out of interest, where is the code that implements these command
>> line operations?
>>
>> Thanks,
>> Neil
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Blazar] Anyone interested?

[Pierre Riteau]

On 1 Sep 2015, at 23:15, Sylvain Bauza  wrote:

> Le 01/09/2015 22:31, Ildikó Váncsa a écrit :
>> Hi,
>> 
>> I'm glad to see the interest and I also support the idea of using the IRC 
>> channel that is already set up for further communication. Should we aim for 
>> a meeting/discussion there around the end of this week or during next week?
>> 
>> @Nikolay, Sylvain: Thanks for support and bringing together a list of action 
>> items as very first steps.
>> 
>> @Pierre: You wrote that you are using Blazar. Are you using it as is with an 
>> older version of OpenStack or you have a modified version of the 
>> project/code?
> I'm actually really surprised to see 
> https://www.chameleoncloud.org/docs/user-guides/bare-metal-user-guide/ which 
> describes quite fine how to use Blazar/Climate either using the CLI or by 
> Horizon.
> 
> The latter is actually not provided within the git tree, so I guess Chameleon 
> added it downstream. That's fine, maybe something we could upstream if Pierre 
> and his team are okay ?
> 
> -Sylvain

We are using a modified version of Blazar (based on the latest master branch 
commit) with OpenStack Juno (RDO packaging).

The only really mandatory patch that we had to develop was for blazar-nova due 
to functions moving from oslo-incubator to oslo.i18n: 
https://github.com/ChameleonCloud/blazar-nova/commit/346627320e87c8e067db6e842935d243c9640e6e
On top of this we developed a number of patches, most of them to fix bugs that 
we discovered in Blazar, with a few to get specific features or behavior 
required for Chameleon.

We also used the code developed by Pablo 
(http://lists.openstack.org/pipermail/openstack-dev/2014-June/038506.html) to 
provide an Horizon dashboard for creating and managing leases.
We even developed a Gantt chart of physical node reservations, but this code 
reads data straight from the SQL database rather than using a new Blazar API, 
so it cannot be contributed as is.

We have always wanted to contribute back our improvements to Blazar and we are 
looking forward to it now that there is renewed interest from the community.
All our OpenStack code should already be available on GitHub at 
https://github.com/ChameleonCloud/

Pierre

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

[openstack-dev] [Neutron][horizon][neutron][L3][dvr][fwaas] FWaaS

[bharath]

Hi,

Horizon seems to be broken.

When i try to add new firewall rule , horizon broken with "'NoneType' 
object has no attribute 'id'" Error.
This was fine about 10 hours back. Seems one of the  latest commit 
broken it.



Traceback in horizon:

2015-09-02 16:15:35.337872 return nodelist.render(context)
2015-09-02 16:15:35.337877   File 
"/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 903, in 
render
2015-09-02 16:15:35.337893 bit = self.render_node(node, context)
2015-09-02 16:15:35.337899   File 
"/usr/local/lib/python2.7/dist-packages/django/template/debug.py", line 79, in 
render_node
2015-09-02 16:15:35.337903 return node.render(context)
2015-09-02 16:15:35.337908   File 
"/usr/local/lib/python2.7/dist-packages/django/template/debug.py", line 89, in 
render
2015-09-02 16:15:35.337913 output = self.filter_expression.resolve(context)
2015-09-02 16:15:35.337917   File 
"/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 647, in 
resolve
2015-09-02 16:15:35.337922 obj = self.var.resolve(context)
2015-09-02 16:15:35.337927   File 
"/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 787, in 
resolve
2015-09-02 16:15:35.337931 value = self._resolve_lookup(context)
2015-09-02 16:15:35.337936   File 
"/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 825, in 
_resolve_lookup
2015-09-02 16:15:35.337940 current = getattr(current, bit)
2015-09-02 16:15:35.337945   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/utils/html.py", line 
59, in attr_string
2015-09-02 16:15:35.337950 return flatatt(self.get_final_attrs())
2015-09-02 16:15:35.337954   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/utils/html.py", line 
42, in get_final_attrs
2015-09-02 16:15:35.337959 final_attrs['class'] = self.get_final_css()
2015-09-02 16:15:35.337964   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/utils/html.py", line 
47, in get_final_css
2015-09-02 16:15:35.337981 default = " ".join(self.get_default_classes())
2015-09-02 16:15:35.337986   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/base.py", 
line 792, in get_default_classes
2015-09-02 16:15:35.337991 if not self.url:
2015-09-02 16:15:35.337995   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/base.py", 
line 756, in url
2015-09-02 16:15:35.338000 url = self.column.get_link_url(self.datum)
2015-09-02 16:15:35.338004   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/base.py", 
line 431, in get_link_url
2015-09-02 16:15:35.338009 return self.link(datum)
2015-09-02 16:15:35.338014   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/project/firewalls/tables.py",
 line 261, in get_policy_link
2015-09-02 16:15:35.338019 kwargs={'policy_id': datum.policy.id})
2015-09-02 16:15:35.338023 AttributeError: 'NoneType' object has no attribute 
'id'


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

Re: [openstack-dev] [oslo][versionedobjects][ceilometer] explain the benefits of ceilometer+versionedobjects

[Alec Hothan (ahothan)]

On 9/1/15, 11:31 AM, "gord chung"  wrote:

>
>
>On 28/08/2015 5:18 PM, Alec Hothan (ahothan) wrote:
>>
>>
>>
>>
>> On 8/28/15, 11:39 AM, "gord chung"  wrote:
>>
>>> i should start by saying i re-read my subject line and it arguably comes
>>> off aggressive -- i should probably have dropped 'explain' :)
>>>
>>> On 28/08/15 01:47 PM, Alec Hothan (ahothan) wrote:
 On 8/28/15, 10:07 AM, "gord chung"  wrote:

> On 28/08/15 12:18 PM, Roman Dobosz wrote:
>> So imagine we have new versions of the schema for the events, alarms or
>> samples in ceilometer introduced in Mitaka release while you have all
>> your ceilo services on Liberty release. To upgrade ceilometer you'll
>> have to stop all services to avoid data corruption. With
>> versionedobjects you can do this one by one without disrupting
>> telemetry jobs.
> are versions checked for every single message? has anyone considered the
> overhead to validating each message? since ceilometer is queue based, we
> could technically just publish to a new queue when schema changes... and
> the consuming services will listen to the queue it knows of.
>
> ie. our notification service changes schema so it will now publish to a
> v2 queue, the existing collector service consumes the v1 queue until
> done at which point you can upgrade it and it will listen to v2 queue.
>
> this way there is no need to validate/convert anything and you can still
> take services down one at a time. this support doesn't exist currently
> (i just randomly thought of it) but assuming there's no flaw in my idea
> (which there may be) isn't this more efficient?
 If high performance is a concern for ceilometer (and it should) then maybe
 there might be better options than JSON?
 JSON is great for many applications but can be inappropriate for other
 demanding applications.
 There are other popular open source encoding options that yield much more
 compact wire payload, more efficient encoding/decoding and handle
 versioning to a reasonable extent.
>>> i should clarify. we let oslo.messaging serialise our dictionary how it
>>> does... i believe it's JSON. i'd be interested to switch it to something
>>> more efficient. maybe it's time we revive the msgpacks patch[1] or are
>>> there better alternatives? (hoping i didn't just unleash a storm of
>>> 'this is better' replies)
>> I'd be curious to know if there is any benchmark on the oslo serializer for 
>> msgpack and how it compares to JSON?
>> More important is to make sure we're optimizing in the right area.
>> Do we have a good understanding of where ceilometer needs to improve to 
>> scale or is it still not quite clear cut?
>
>re: serialisation, that probably isn't the biggest concern for 
>Ceilometer performance. the main items are storage -- to be addressed by 
>Gnocchi/tsdb, and polling load. i just thought i'd point out an existing 
>serialisation patch since we were on the topic :-)

Is there any data measuring the polling load on large scale deployments?
Was there a plan to reduce the polling load to an acceptable level? If yes 
could you provide any pointer if any?


>
>>
 Queue based versioning might be less runtime overhead per message but at
 the expense of a potentially complex queue version management (which can
 become tricky if you have more than 2 versions).
 I think Neutron was considering to use versioned queues as well for its
 rolling upgrade (along with versioned objects) and I already pointed out
 that managing the queues could be tricky.

 In general, trying to provide a versioning framework that allows to do
 arbitrary changes between versions is quite difficult (and often bound to
 fail).

>>> yeah, so that's what a lot of the devs are debating about right now.
>>> performance is our key driver so if we do something we think/know will
>>> negatively impact performance, it better bring a whole lot more of
>>> something else. if queue based versioning offers comparable
>>> functionalities, i'd personally be more interested to explore that route
>>> first. is there a thread/patch/log that we could read to see what
>>> Neutron discovered when they looked into it?
>> The versioning comments are buried in this mega patch if you are brave 
>> enough to dig in:
>>
>> https://review.openstack.org/#/c/190635
>>
>> The (offline) conclusion was that this was WIP and deserved more discussion 
>> (need to check back with Miguel and Ihar from the Neutron team).
>> One option considered in that discussion was to use oslo messaging topics to 
>> manage flows of messages that had different versions (and still use 
>> versionedobjects). So if you have 3 versions in your cloud you'd end up with 
>> 3 topics (and as many queues when it comes to Rabbit). What is complex is to 
>> manage the queues/topic names (how to name them), how to 

Re: [openstack-dev] How to run fw testcases which are recently moved from tempest to neutron.

[Assaf Muller]

I just go to the Neutron dir and use: tox -e api.

On Wed, Sep 2, 2015 at 11:37 AM, bharath  wrote:

> Hi ,
>
> How to run FW testcases which are under neutron using tempest?
>
> If i am trying to list cases from tempest(sudo -u stack -H testr
> list-tests neutron.api
> ), its resulting to empty list
>
>
>
> Thanks,
> bharath
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove] [heat] Multi region support

[Zane Bitter]

On 01/09/15 19:47, Angus Salkeld wrote:

On Wed, Sep 2, 2015 at 8:30 AM Lowery, Mathew > wrote:

Thank you Zane for the clarifications!

I misunderstood #2 and that led to the other misunderstandings.

Further questions:
* Are nested stacks aware of their nested-ness? In other words,
given any
nested stack (colocated with parent stack or not), can I trace it
back to
the parent stack? (On a possibly related note, I see that adopting a
stack


Yes, there is a link (url) to the parent_stack in the links section of
show stack.


That's true only for resources which derive from StackResource, and 
which are manipulated through the RPC API. Mat was, I think, asking 
specifically about OS::Heat::Stack resources, which may (or may not) be 
in remote regions and are manipulated through the ReST API. Those ones 
are not aware of their nested-ness.



is an option to reassemble a new parent stack from its regional parts in
the event that the old parent stack is lost.)
* Has this design met the users' needs? In other words, are there any
plans to make major modifications to this design?


AFAIK we have had zero feedback from the multi region feature.
No more plans, but we would obviously love feedback and suggestions
on how to improve region support.


Yeah, this has not been around so long that there has been a lot of 
feedback.


I know people want to also do multi-cloud (i.e. where the remote region 
has a different keystone). It's tricky to implement because we need 
somewhere to store the credentials... we'll possibly end up saying that 
Keystone federation is required, and then we'll only have to pass the 
keystone auth URL in addition to what we already have.


cheers,
Zane.

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

[openstack-dev] How to run fw testcases which are recently moved from tempest to neutron.

[bharath]

Hi ,

How to run FW testcases which are under neutron using tempest?

If i am trying to list cases from tempest(sudo -u stack -H testr 
list-tests neutron.api

), its resulting to empty list



Thanks,
bharath

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

Re: [openstack-dev] [Fuel] Code review process in Fuel and related issues

[Jay Pipes]

On 09/02/2015 08:45 AM, Igor Kalnitsky wrote:

I think there's plenty of examples of people in OpenStack projects
that both submit code (and lead features) that also do code review
on a daily basis.


* Do these features huge?


Yes.


* Is their code contribution huge or just small patches?


Both.


* Did they get to master before FF?


Yes.


* How many intersecting features OpenStack projects have under
development? (since often merge conflicts requires a lot of re-review)


I recognize that Fuel, like devstack, has lots of cross-project 
dependencies. That just makes things harder to handle for Fuel, but it's 
not a reason to have core reviewers not working on code or non-core 
reviewers not doing reviews.



* How often OpenStack people are busy on other activities, such as
helping fellas, troubleshooting customers, participate design meetings
and so on?


Quite often. I'm personally on IRC participating in design discussions, 
code reviews, and helping people every day. Not troubleshooting 
customers, though...



If so, do you sure they are humans then? :) I can only speak for
myself, and that's what I want to say: during 7.0 dev cycle I burned
in hell and I don't want to continue that way.


I think you mean you "burned out" :) But, yes, I hear you. I understand 
the pressure that you are under, and I sympathize with you. I just feel 
that the situation is not an either/or situation, and encouraging some 
folks to only do reviews and not participate in coding/feature 
development is a dangerous thing.


Best,
-jay


Thanks,
Igor

On Wed, Sep 2, 2015 at 3:14 PM, Jay Pipes  wrote:

On 09/02/2015 03:00 AM, Igor Kalnitsky wrote:


It won't work that way. You either busy on writing code / leading
feature or doing review. It couldn't be combined effectively. Any
context switch between activities requires an extra time to focus on.



I don't agree with the above, Igor. I think there's plenty of examples of
people in OpenStack projects that both submit code (and lead features) that
also do code review on a daily basis.

Best,
-jay


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


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



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

[openstack-dev] [neutron] pushing changes through the gate

[Armando M.]

Hi,

By now you may have seen that I have taken out your change from the gate
and given it a -2: don't despair! I am only doing it to give priority to
the stuff that needs to merge in order to get [1] into a much better shape.

If you have an important fix, please target it for RC1 or talk to me or
Doug (or Kyle when he's back from his time off), before putting it in the
gate queue. If everyone is not conscious of the other, we'll only end up
stepping on each other, and nothing moves forward.

Let's give priority to gate stabilization fixes, and targeted stuff.

Happy merging...not!

Many thanks,
Armando

[1] https://launchpad.net/neutron/+milestone/liberty-3
[2] https://launchpad.net/neutron/+milestone/liberty-rc1
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Criteria for applying vulnerability:managed tag

[Tristan Cacqueray]

Thanks you Jeremy for starting this discussion :-)

Proposed criteria works for me and they concurs with what have been
discussed in Vancouver.

My comments on the open-question below.


On 09/01/2015 06:56 PM, Jeremy Stanley wrote:
> A. Can the VMT accept deliverables in any programming language?

Any supported programming language by the openstack project should/could
also be accepted for vulnerability management.
As long as there is a way to test patch, I think the VMT can support
other languages like Go or Puppet.


> 
> B. As we expand the VMT's ring within the Big Top to encircle more
> and varied acts, are there parts of our current process we need to
> reevaluate for better fit? For example, right now we have one list
> of downstream stakeholders (primarily Linux distros and large public
> providers) we notify of upcoming coordinated disclosures, but as the
> list grows longer and the kinds of deliverables we support becomes
> more diverse some of them can have different downstream communities
> and so a single contact list may no longer make sense.
> 
The risk is to divide downstream communities, and managing different
lists sounds like overkill for now. One improvement would be to maintain
that list publicly like xen do for their pre-disclosure list:
  http://www.xenproject.org/security-policy.html


> C. Should we be considering a different VMT configuration entirely,
> to better service some under-represented subsets of the OpenStack
> community? Perhaps multiple VMTs with different specialties or a
> tiered structure with focused subteams.
> 
> D. Are there other improvements we can make so that our
> recommendations and processes are more consumable by other groups
> within OpenStack, further distributing the workload or making it
> more self-service (perhaps reducing the need for direct VMT
> oversight in more situations)?
> -- Jeremy Stanley

With a public stakeholder list, we can clarify our vmt-process to be
directly usable without vmt supervision.

Anyway, imo the five criteria proposed are good to be amended to the
vulnerability:managed tag documentation.

Again, thank you fungi :-)
Tristan



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

Re: [openstack-dev] [Heat] convergence rally test results (so far)

[Zane Bitter]

On 02/09/15 04:55, Steven Hardy wrote:

On Wed, Sep 02, 2015 at 04:33:36PM +1200, Robert Collins wrote:

On 2 September 2015 at 11:53, Angus Salkeld  wrote:


1. limit the number of resource actions in parallel (maybe base on the
number of cores)


I'm having trouble mapping that back to 'and heat-engine is running on
3 separate servers'.


I think Angus was responding to my test feedback, which was a different
setup, one 4-core laptop running heat-engine with 4 worker processes.

In that environment, the level of additional concurrency becomes a problem
because all heat workers become so busy that creating a large stack
DoSes the Heat services, and in my case also the DB.

If we had a configurable option, similar to num_engine_workers, which
enabled control of the number of resource actions in parallel, I probably
could have controlled that explosion in activity to a more managable series
of tasks, e.g I'd set num_resource_actions to (num_engine_workers*2) or
something.


I think that's actually the opposite of what we need.

The resource actions are just sent to the worker queue to get processed 
whenever. One day we will get to the point where we are overflowing the 
queue, but I guarantee that we are nowhere near that day. If we are 
DoSing ourselves, it can only be because we're pulling *everything* off 
the queue and starting it in separate greenthreads.


In an ideal world, we might only ever pull one task off that queue at a 
time. Any time the task is sleeping, we would use for processing stuff 
off the engine queue (which needs a quick response, since it is serving 
the ReST API). The trouble is that you need a *huge* number of 
heat-engines to handle stuff in parallel. In the reductio-ad-absurdum 
case of a single engine only processing a single task at a time, we're 
back to creating resources serially. So we probably want a higher number 
than 1. (Phase 2 of convergence will make tasks much smaller, and may 
even get us down to the point where we can pull only a single task at a 
time.)


However, the fewer engines you have, the more greenthreads we'll have to 
allow to get some semblance of parallelism. To the extent that more 
cores means more engines (which assumes all running on one box, but 
still), the number of cores is negatively correlated with the number of 
tasks that we want to allow.


Note that all of the greenthreads run in a single CPU thread, so having 
more cores doesn't help us at all with processing more stuff in parallel.


cheers,
Zane.

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

Re: [openstack-dev] [Ironic] Command structure for OSC plugin

[Tim Bell]

> -Original Message-
> From: Doug Hellmann [mailto:d...@doughellmann.com]
> Sent: 02 September 2015 16:21
> To: openstack-dev 
> Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin
> 
> Excerpts from Tim Bell's message of 2015-09-02 05:15:35 +:
> > That would be great to have plugins on the commands which are relevant
> to multiple projects… avoiding exposing all of the underlying projects as
> prefixes and getting more consistency would be very appreciated by the
> users.
> 
> That works in some cases, but in a lot of cases things that are superficially
> similar have important differences in the inputs they take. In those cases, 
> it's
> better to be explicit about the differences than to force the concepts 
> together
> in a way that makes OSC present only the least-common denominator
> interface.
> 

I think the difference are in the options rather than the prefixes. Thus, if I 
want to create a bare metal server, I should be able to use 'openstack create' 
rather than 'openstack ironic create'. The various implications on options etc. 
are clearly dependent on the target environment.

I would simply like to avoid that the OSC becomes a prefix, i.e. you need to 
know that ironic is for baremetal. If options are presented which are not 
supported in the desired context, they should be rejected. 

At CERN, we're using OSC as the default CLI. This is partly because the support 
for Keystone v3 API is much more advanced but also because we do not want our 
end users to know the list of OpenStack projects, only the services we are 
offering them.

Tim

> Doug
> 
> >
> > Tim
> >
> > From: Dean Troyer [mailto:dtro...@gmail.com]
> > Sent: 01 September 2015 22:47
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin
> >
> > [late catch-up]
> >
> > On Mon, Aug 24, 2015 at 2:56 PM, Doug Hellmann
> > wrote:
> > Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:
> > > On 24/08/15 18:19 +, Tim Bell wrote:
> > > >
> > > >From a user perspective, where bare metal and VMs are just different
> flavors (with varying capabilities), can we not use the same commands
> (server create/rebuild/...) ? Containers will create the same conceptual
> problems.
> > > >
> > > >OSC can provide a converged interface but if we just replace '$ ironic
> ' by '$ openstack baremetal ', this seems to be a missed
> opportunity to hide the complexity from the end user.
> > > >
> > > >Can we re-use the existing server structures ?
> >
> > I've wondered about how users would see doing this, we've done it already
> with the quota and limits commands (blurring the distinction between
> project APIs).  At some level I am sure users really do not care about some of
> our project distinctions.
> >
> > > To my knowledge, overriding or enhancing existing commands like that
> > > is not possible.
> >
> > You would have to do it in tree, by making the existing commands smart
> > enough to talk to both nova and ironic, first to find the server
> > (which service knows about something with UUID XYZ?) and then to take
> > the appropriate action on that server using the right client. So it
> > could be done, but it might lose some of the nuance between the server
> > types by munging them into the same command. I don't know what sorts
> > of operations are different, but it would be worth doing the analysis
> > to see.
> >
> > I do have an experimental plugin that hooks the server create command to
> add some options and change its behaviour so it is possible, but right now I
> wouldn't call it supported at all.  That might be something that we could
> consider doing though for things like this.
> >
> > The current model for commands calling multiple project APIs is to put
> them in openstackclient.common, so yes, in-tree.
> >
> > Overall, though, to stay consistent with OSC you would map operations
> into the current verbs as much as possible.  It is best to think in terms of 
> how
> the CLI user is thinking and what she wants to do, and not how the REST or
> Python API is written.  In this case, 'baremetal' is a type of server, a set 
> of
> attributes of a server, etc.  As mentioned earlier, containers will also have 
> a
> similar paradigm to consider.
> >
> > dt
> >
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[openstack-dev] [ CloudKitty ] New release

[Christophe Sauthier]

We are really pleased to announce that a few days ago the latest 
CloudKitty's version (0.4.1) has been released.
For those of you who don't know CloudKitty, it is an additionnal 
component for OpenStack that tackles the pricing and chargeback aspects. 
It is fully OpenSource (Apache 2.0), developped in Python and using the 
same process and librairies as the rest of the OpenStack components.
CloudKitty is designed like any other OpenStack component, providing an 
API, a client and an Horizon integration.


Using CloudKitty you are able to:
• define the price of the different services you are providing
• charge your users for the usage
• get you users the possibiliy to know in advance the price for the 
ressource they are about to launch

• get your user a report of their past usage
• and many more


If you are interested please grab the latest release directly on 
stackforge:

• https://github.com/stackforge/cloudkitty/releases
• https://github.com/stackforge/cloudkitty-dashboard/releases
• https://github.com/stackforge/python-cloudkittyclient/releases

This release is targeted at Kilo, if you want to try it out in an older 
environment you can use virtualenv or your favorite contrainers 
solution.
A docker container will be soon avaible to help people wanting to try 
CloudKitty even on older release of OpenStack.
We are currently working on getting CloudKitty integrated with the 
major Linux Distributions, meanwhile we have repositories available with 
up to date packages at http://archive.objectif-libre.com/cloudkitty/
You can find some installation instructions here :  
http://cloudkitty.readthedocs.org/en/latest/installation.html




We hope you'll like that release but here is an overview of some of the 
major enhancements that we are planning for the Liberty release:

• Keystone AuthPlugins (less duplicated configuration code)
• Keystone sessions
• Rating module rules management (validity periods, per tenant, etc)
• Rating modules enabling you to write and manage python custom code to 
do your own pricing rules
• Scalability enhancement with the introduction of asynchronous workers 
and clustering

• Addition of the CSV as a native report output file format
• Documentaiton improvement
• More code coverage and unittests
• and many more...


Feel free to join us on #cloudkitty if you have any questions or want 
to take part into that project !


The CloudKitty team




Christophe Sauthier   Mail : 
christophe.sauth...@objectif-libre.com

CEO   Mob : +33 (0) 6 16 98 63 96
Objectif LibreURL : www.objectif-libre.com
Infrastructure et Formations LinuxTwitter : @objectiflibre

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

Re: [openstack-dev] [oslo][versionedobjects][ceilometer] explain the benefits of ceilometer+versionedobjects

[gord chung]

On 02/09/2015 11:25 AM, Alec Hothan (ahothan) wrote:





On 9/1/15, 11:31 AM, "gord chung"  wrote:


re: serialisation, that probably isn't the biggest concern for
Ceilometer performance. the main items are storage -- to be addressed by
Gnocchi/tsdb, and polling load. i just thought i'd point out an existing
serialisation patch since we were on the topic :-)

Is there any data measuring the polling load on large scale deployments?
Was there a plan to reduce the polling load to an acceptable level? If yes 
could you provide any pointer if any?


i'm not sure any user has provided numbers when raising the issue -- 
just that it's 'high'. this should probably be done in a separate thread 
as i don't want it to get lost in completely unrelated subject. that 
said, an initial patch to minimise load was done in Liberty[1] and 
secondary proposal for M*[2].


conceptually, i would think only the consumers need to know about all 
the queues and even then, it should only really need to know about 
the ones it understands. the producers (polling agents) can just fire 
off to the correct versioned queue and be done... thanks for the 
above link (it'll help with discussion/spec design). 

When everything goes according to plan, any solution can work but this is 
hardly the case in production, especially at scale.  Here are a few question 
that may help in the discussion:
- how are versioned queue named?
- who creates a versioned queue (producer or consumer?) and who deletes it when 
no more entity of that version is running?
- how to make sure a producer is not producing in a queue that has no consumer 
(a messaging infra like rabbit is designed to decouple producers from consumers)
- all corner cases of entities (consumers or producers) popping up with newer 
or older version, and terminating (gracefully or not) during the 
upgrade/downgrade, what happens to the queues...

IMHO using a simple communication schema (1 topic/queue for all versions) with 
in-band message versioning is a much less complex proposition than juggling 
with versioned queues (not to say the former is simple to do). With versioned 
queues you're kind of trading off the per message versioning with per queue 
versioning but at the expense of:
- a complex queue management (if you want to do it right)
- a not less complex per queue message decoding (since the consumer needs to 
know how to decode and interpret every message depending on the version of the 
queue it comes from)
- a more difficult debug environment (harder to debug multiple queues than 1 
queue)
- and added stress on oslo messaging (due to the use of transient queues)

thanks, good items to think about when building spec. will be sure to 
add link when initial draft is ready.


[1] 
https://blueprints.launchpad.net/ceilometer/+spec/resource-metadata-caching

[2] https://review.openstack.org/#/c/209799/

--
gord


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

Re: [openstack-dev] subunit2html location on images changing

[Matt Riedemann]

On 8/26/2015 5:22 PM, Matthew Treinish wrote:

Hi Everyone,

There is a pending change up for review that will move the location subunit2html
jenkins slave script:

https://review.openstack.org/212864/

It switches from a locally installed copy to using the version packaged in
os-testr which is installed in a system venv. This was done in an effort to
unify and package up some of the tooling which was locally copied around under
the covers but are generally useful utilities. If you have a local gate hook
which is manually calling the script realize that when this change merges and
takes effect on the next round of nodepool images things will start failing. To
fix it either update the location in your hook, or an even better solution would
be to just rely on devstack-gate to do the right thing for you. For example,
calling out to:

http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/functions.sh#n571

will do the right thing.

Thanks,

Matthew Treinish



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



Some things seem to be blowing up because of this:

https://bugs.launchpad.net/openstack-gate/+bug/1491646

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Alex Schultz to Fuel-Library Core

[Aleksandr Didenko]

Hi,

+1 from me.

Regards,
Alex

On Wed, Sep 2, 2015 at 5:00 PM, Vladimir Kuklin 
wrote:

> +1 and also he is in US timezone, which  should help us cover the globe
> with Continuous Review process.
>
> On Wed, Sep 2, 2015 at 3:45 PM, Dmitry Borodaenko <
> dborodae...@mirantis.com> wrote:
>
>> Huge +1 from me, Alex has all the best qualities of a core reviewer:
>> great engineer, great communicator, diligent, and patient.
>>
>> On Wed, Sep 2, 2015 at 3:24 PM Jay Pipes  wrote:
>>
>>> I'm not a Fuel core or anything, but +1 from me. Alex has been very
>>> visible in the community and his work on librarian-puppet was a great
>>> step forward for the project.
>>>
>>> Best,
>>> -jay
>>>
>>> On 09/02/2015 04:31 AM, Sergii Golovatiuk wrote:
>>> > Hi,
>>> >
>>> > I would like to nominate Alex Schultz to Fuel-Library Core team. He’s
>>> > been doing a great job in writing patches. At the same time his reviews
>>> > are solid with comments for further improvements. He’s #3 reviewer and
>>> > #1 contributor with 46 commits for last 90 days [1]. Additionally, Alex
>>> > has been very active in IRC providing great ideas. His ‘librarian’
>>> > blueprint [3] made a big step towards to puppet community.
>>> >
>>> > Fuel Library, please vote with +1/-1 for approval/objection. Voting
>>> will
>>> > be open until September 9th. This will go forward after voting is
>>> closed
>>> > if there are no objections.
>>> >
>>> > Overall contribution:
>>> > [0] http://stackalytics.com/?user_id=alex-schultz
>>> > Fuel library contribution for last 90 days:
>>> > [1] http://stackalytics.com/report/contribution/fuel-library/90
>>> > List of reviews:
>>> > [2]
>>> >
>>> https://review.openstack.org/#/q/reviewer:%22Alex+Schultz%22+status:merged,n,z
>>> > ‘Librarian activities’ in mailing list:
>>> > [3]
>>> http://lists.openstack.org/pipermail/openstack-dev/2015-July/071058.html
>>> >
>>> > --
>>> > Best regards,
>>> > Sergii Golovatiuk,
>>> > Skype #golserge
>>> > IRC #holser
>>> >
>>> >
>>> >
>>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][Heat] instance_user fallout, keeping the 'heat-admin' user working

[Dan Prince]

On Wed, 2015-09-02 at 20:32 -0400, James Slagle wrote:
> On Wed, Sep 2, 2015 at 4:22 PM, Dan Prince 
> wrote:
> > We had an IRC discussion today about the 'heat-admin' user in
> > #tripleo.
> > 
> > Upstream Heat recently reverted the 'instance_user' config file
> > option
> > which we relied on in TripleO to standardize the default (admin)
> > user
> > on our nodes. It is my understanding that Heat would prefer not to
> > maintain this option because it causes subtle compatibility issues
> > across the OpenStack and AWS APIs and the interactions between
> > cloud
> > -init version, etc. So it was deprecated in Icehouse... and
> > recently
> > removed in [1].
> > 
> > We could just go with the default distro user (centos, fedora,
> > ubuntu,
> > etc.) but it would be really nice to standardize on a user name for
> > maintenance should anyone every spin up a cloud using multiple
> > distros
> > or something.
> > 
> > So a couple of options. We could just go on and update our
> > templates
> > like this [2]. This actually seems pretty clean to me, but it would
> > require anybody who has created custom firstboot scripts to do the
> > same
> > (we have proposed docker patches with firstboot scripts that need
> > similar updates).
> 
> Yea, that's the main reason I'm not fond of this approach. It really
> feels like cluttering up the firstboot interface, in that anyone who
> wants to plugin in their own config there has to remember to also
> include this snippet. It leads to copying/pasting around yaml, which
> I
> don't think is a great pattern going forward.
> 

Well, ideally we'll have a minimal number of first boot scripts... in
tree there are only 3 that I can see right now and the meaningful code
is actually quite small. Just this:

  user_config:
type: OS::Heat::CloudConfig
properties:
  cloud_config:
user: 'heat-admin'

Any out of tree firstboot scripts would need the same implementation
fixes though. It is those that primarily concern me. Still, if we were
to validate this somehow and failfast that could be a fair compromise.

> It would be nice to have a cleaner separation between the interfaces
> that we offer to users and those that need to be reserved/used for
> TripleO's own purposes.

Agree. The ability to compose userdata via OS::Heat::MultipartMime does
already exist somewhat. Perhaps we could fashion a better way to
include a global user config (from a  heat-admin-user-data.yaml or
something). Haven't tried this yet...

> 
> I'm not sure of a better solution though other than a native
> SoftwareDeployment resource in the templates directly that creates a
> known user and reads the ssh keys from the user data (via a script).

This seems like duplication of a feature we get for free w/ cloud-init
though right?

If we wanted to validate the user exists a script (executed via a
SoftwareDeployment) could be useful for that.

> 
> Or, what about baking in some static configuration for cloud-init
> into
> our images that creates the known user?

Agree this would work but it might be undesirable for images like
Atomic which some would like to avoid repackaging for use via TripleO.
At least that is an idea on the table with the Docker implementation...
as in we don't actually create a custom TripleO version of Atomic. It
just works out of the box with the stock version.

> 
> > Alternately, we could propose that Heat revert the instance_user
> > feature or some version of it. We've been using that for a year or
> > two
> > now and it has actually been fairly nice to set the default that
> > way.
> 
> I really liked having the one consistent user no matter the cloud
> image you deployed from as well. I'm not sure we could successfully
> persuade it to go back in though given it was deprecated in Icehouse.

Agree. I miss the old feature quite a bit. Just wanted to give the new
idea a try first before posted a revert...

> 
> > 
> > Thoughts?
> > 
> > 
> > [1] https://review.openstack.org/103928
> > 
> > [2] https://review.openstack.org/#/c/219861/
> > 
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 

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

Re: [openstack-dev] [puppet] hosting developer documentation on http://docs.openstack.org/developer/

[Matt Fischer]

+1

On Wed, Sep 2, 2015 at 12:09 PM, Emilien Macchi  wrote:

> TL;DR, I propose to move our developer documentation from wiki to
> something like http://docs.openstack.org/developer/puppet-openstack
>
> (Look at http://docs.openstack.org/developer/tempest/ for example).
>
> For now, most of our documentation is on
> https://wiki.openstack.org/wiki/Puppet but I think it would be great to
> use RST format and Gerrit so anyone could submit documentation
> contribute like we do for code.
>
> I propose a basic table of contents now:
> Puppet modules introductions
> Coding Guide
> Reviewing code
>
> I'm taking the opportunity of the puppet sprint to run this discussion
> and maybe start some work of people agrees to move on.
>
> Thanks,
> --
> Emilien Macchi
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] hosting developer documentation on http://docs.openstack.org/developer/

[Emilien Macchi]

On 09/02/2015 02:48 PM, Anita Kuno wrote:
> On 09/02/2015 02:09 PM, Emilien Macchi wrote:
>> TL;DR, I propose to move our developer documentation from wiki to 
>> something like 
>> http://docs.openstack.org/developer/puppet-openstack
> 
>> (Look at http://docs.openstack.org/developer/tempest/ for 
>> example).
> 
> Looking at the tempest example:
> http://git.openstack.org/cgit/openstack/tempest/tree/doc/source
> we see that the .rst files all live in the tempest repo in doc/source
> (with the exception of the README.rst file with is referenced from
> within doc/source when required:
> http://git.openstack.org/cgit/openstack/tempest/tree/doc/source/overview.rst)
> 
> So question: Where should the source .rst files for puppet developer
> documentation live? They will need a home.

I guess we would need a new repository for that.
It could be puppet-openstack-doc (kiss)
or something else, any suggestion is welcome.

> 
> Thanks,
> Anita.
> 
> 
>> For now, most of our documentation is on 
>> https://wiki.openstack.org/wiki/Puppet but I think it would be 
>> great to use RST format and Gerrit so anyone could submit 
>> documentation contribute like we do for code.
> 
>> I propose a basic table of contents now: Puppet modules 
>> introductions Coding Guide Reviewing code
> 
>> I'm taking the opportunity of the puppet sprint to run this 
>> discussion and maybe start some work of people agrees to move on.
> 
>> Thanks,
> 
> 
> 
>> __
> 
> 
> 
> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Emilien Macchi



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

[openstack-dev] [app-catalog] IRC Meeting Thursday September 3rd at 17:00UTC

[Christopher Aedo]

Greetings! Our next OpenStack App Catalog meeting will take place this
Thursday September 3rd at 17:00 UTC in #openstack-meeting-3

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

Please add agenda items if there's anything specific you would like to
discuss (or of course if the meeting time is not convenient for you
join us on IRC #openstack-app-catalog).

Please join us if you can!

-Christopher

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

Re: [openstack-dev] [cinder] Brocade CI

[Angela Smith]

Mike,

Brocade OpenStack CI is now complying with requirements mentioned in your mail.

1.   Reporting success/failure. (FYI, we had been doing this prior to your 
email, but the results were not visible using lastcomment script unless use the 
–m option)

2.   Link is now posted for logs in comment and in right hand results 
column, per the message format requirement.

3.   Reporting consistently on all patchsets.

4.   Recheck is working.

5.   Failed message contains wiki link, and recheck message.

6.   Brocade OpenStack CI will remain non-voting.

Thanks,
Angela

From: Angela Smith
Sent: Thursday, August 27, 2015 2:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: DL-GRP-ENG-Brocade-Openstack-CI
Subject: RE: [openstack-dev] [cinder] Brocade CI

The full results of lastcomment script are here for last 400 commits: [1][2]

[1] http://paste.openstack.org/show/430074/
[2] http://paste.openstack.org/show/430088/


From: Angela Smith
Sent: Thursday, August 27, 2015 1:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: DL-GRP-ENG-Brocade-Openstack-CI
Subject: RE: [openstack-dev] [cinder] Brocade CI

Mike,
An update on Brocade CI progress.  We are now using the format required for 
results to show in lastcomment script.
We have been consistently reporting for last 9 days.  See results here: [1].
We are still working on resolving recheck issue and adding link to wiki page in 
the failed result comment message.   Update will be sent when that is completed.
Thanks,
Angela

[1] http://paste.openstack.org/show/430074/

From: Angela Smith
Sent: Friday, August 21, 2015 1:02 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: DL-GRP-ENG-Brocade-Openstack-CI
Subject: RE: [openstack-dev] [cinder] Brocade CI

Mike,
I wanted to update you on our progress on the Brocade CI.
We are currently working on the remaining requirements of adding recheck and 
adding link to wiki page for a failed result.
Also, the CI is now consistently testing and reporting on all cinder reviews 
for the past 3 days.
Thanks,
Angela

From: Nagendra Jaladanki [mailto:nagendra.jalada...@gmail.com]
Sent: Thursday, August 13, 2015 4:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: DL-GRP-ENG-Brocade-Openstack-CI
Subject: Re: [openstack-dev] [cinder] Brocade CI

Ramy,
Thanks for providing the correct message. We will update our commit message 
accordingly.
Thanks,
Nagendra Rao

On Thu, Aug 13, 2015 at 4:43 PM, Asselin, Ramy 
> wrote:
Hi Nagendra,

Seems one of the issues is the format of the posted comments. The correct 
format is documented here [1]

Notice the format is not correct:
Incorrect: Brocade Openstack CI (non-voting) build SUCCESS logs at: 
http://144.49.208.28:8000/build_logs/2015-08-13_18-19-19/
Correct: * test-name-no-spaces http://link.to/result : [SUCCESS|FAILURE] some 
comment about the test

Ramy

[1] 
http://docs.openstack.org/infra/system-config/third_party.html#posting-result-to-gerrit

From: Nagendra Jaladanki 
[mailto:nagendra.jalada...@gmail.com]
Sent: Wednesday, August 12, 2015 4:37 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Cc: brocade-openstack...@brocade.com
Subject: Re: [openstack-dev] [cinder] Brocade CI

Mike,

Thanks for your feedback and suggestions. I had send my response yesterday but 
looks like didn't get posted on the 
lists.openstack.org. Hence posting it here again.

We reviewed your comments and following issues were identified and some of them 
are fixed and some fix plans in progress:

1) Not posting success or failure
 The Brocade CI is a non-voting CI. The CI is posting the comment for build 
sucucess or failures. The report tool is not seeing these. We are working on 
correcting this.
2) Not posting a result link to view logs.
   We could not find any cases where CI is failed to post the link to logs from 
the generated report.  If you have any specific uses where it failed to post 
logs link, please share with us. But we did see that CI not posted the comment 
at all for some review patch sets. Root causing the issue why CI not posted the 
comment at all.
3) Not consistently doing runs.
   There were planned down times and CI not posted during those periods. We 
also observed that CI was not posting the failures in some cases where CI 
failed due non openstack issues. We corrected this. Now the CI should be 
posting the results for all patch sets either success or failure.
We are also doing the following:
- Enhance the message format to be inline with other CIs.
- Closely monitoring the incoming Jenkin's request vs out going builds and 
correcting if there are any issues.

Once again thanks for your feedback and suggestions. We will 

Re: [openstack-dev] [TripleO][Heat] instance_user fallout, keeping the 'heat-admin' user working

[James Slagle]

On Wed, Sep 2, 2015 at 4:22 PM, Dan Prince  wrote:
> We had an IRC discussion today about the 'heat-admin' user in #tripleo.
>
> Upstream Heat recently reverted the 'instance_user' config file option
> which we relied on in TripleO to standardize the default (admin) user
> on our nodes. It is my understanding that Heat would prefer not to
> maintain this option because it causes subtle compatibility issues
> across the OpenStack and AWS APIs and the interactions between cloud
> -init version, etc. So it was deprecated in Icehouse... and recently
> removed in [1].
>
> We could just go with the default distro user (centos, fedora, ubuntu,
> etc.) but it would be really nice to standardize on a user name for
> maintenance should anyone every spin up a cloud using multiple distros
> or something.
>
> So a couple of options. We could just go on and update our templates
> like this [2]. This actually seems pretty clean to me, but it would
> require anybody who has created custom firstboot scripts to do the same
> (we have proposed docker patches with firstboot scripts that need
> similar updates).

Yea, that's the main reason I'm not fond of this approach. It really
feels like cluttering up the firstboot interface, in that anyone who
wants to plugin in their own config there has to remember to also
include this snippet. It leads to copying/pasting around yaml, which I
don't think is a great pattern going forward.

It would be nice to have a cleaner separation between the interfaces
that we offer to users and those that need to be reserved/used for
TripleO's own purposes.

I'm not sure of a better solution though other than a native
SoftwareDeployment resource in the templates directly that creates a
known user and reads the ssh keys from the user data (via a script).

Or, what about baking in some static configuration for cloud-init into
our images that creates the known user?

> Alternately, we could propose that Heat revert the instance_user
> feature or some version of it. We've been using that for a year or two
> now and it has actually been fairly nice to set the default that way.

I really liked having the one consistent user no matter the cloud
image you deployed from as well. I'm not sure we could successfully
persuade it to go back in though given it was deprecated in Icehouse.

>
> Thoughts?
>
>
> [1] https://review.openstack.org/103928
>
> [2] https://review.openstack.org/#/c/219861/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
-- James Slagle
--

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

Re: [openstack-dev] [kosmos][designate][lbaas] Intial Kosmos source files for review in gerrit

[Gandhi, Kunal]

A gentle reminder to please take a look at the code review and provide feedback.

Regards
Kunal

> On Aug 30, 2015, at 8:26 PM, Gandhi, Kunal  wrote:
> 
> Hi All
> 
> I have checked in the initial source files to gerrit for review.
> 
> https://review.openstack.org/#/c/218709/ 
> 
> 
> Please take a look a look at it and provide feedback.
> 
> Regards
> Kunal
> 

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

Re: [openstack-dev] [Neutron] Un-addressed Port spec and implementation

[Kevin Benton]

That patch was reverted because it relied on a non-obvious corner case to
work. A port would not get any spoofing prevention if it had no IP
addresses.

At first we reasoned that this would be okay since the only way to create a
port without IPs was if the network has no subnets and it doesn't make
sense for Neutron to do L3 protection on a network it doesn't manage L3
for. However, this was an issue once a subnet was subsequently added to the
network. A port would still be remaining without IP addresses and it
wouldn't have any spoofing prevention. We don't want these kind of corner
cases in the API so we reverted it.

>One possible solution we could do to prevent this is to keep flow entries
that block the port from pretending to have an IP that is already part of
the network (or subnet).

Three issues with this I can see right away:

   - This breaks protection for provider network scenarios where the
   provider has a router that Neutron doesn't know about.
   - It introduces a window of attack where you can send gratuitous ARP for
   all of the IP addresses which aren't in use and collect traffic to new
   ports as they come online before the ARP entries time out.
   - Each L2 agent is now going to require an ARP flow rule for every other
   port's IP/MAC on the same network. This could easily be 10,000+ of rules on
   a densely packed node (50 VMs on 200 port networks). Syncing this info will
   need a reliability mechanism to make there are no missed messages (which
   result in vulnerabilities).


Why can you just use the port security API to disable port security for the
port? If the issue is just that you want MAC spoofing prevention but
nothing else, then we need to adjust the port security API to be more
fine-grained.

On Wed, Sep 2, 2015 at 1:37 AM, Gal Sagie  wrote:

> Hello All,
>
> The un-addressed port spec [1] was approved for Liberty.
> I think this spec has good potential to provide very interesting solutions
> for NFV use cases
> but also for multi site connectivity and i would really want to see
> it move forward with the community.
>
> There are some issues we need to discuss regarding L2 population (both for
> the reference
> implementation and for any "SDN" solution), but we can iterate on them.
>
> This email relates to a recent revert [2] that was done to prevent
> spoofing possibility
> due to recent work that was merged.
>
> If i understand the problem correctly, an un-addressed port can now
> perform ARP spoofing
> on an address of a port that already exists in the same network and listen
> to its traffic.
> (a problem which becomes bigger with shared network among tenants)
>
> One possible solution we could do to prevent this is to keep flow entries
> that block the port
> from pretending to have an IP that is already part of the network (or
> subnet).
> So there will be ARP spoofing checks that check the port is not answering
> for an IP that is already
> configured.
> *Any thoughts/comments on that?*
>
> Unrelated to this, i think that an un-address port should work in subnet
> context when it comes
> to L2 population and traffic forwarding, so that un-address port only gets
> traffic for addresses
> that are not found, but are on the same subnet as the un-address port.
> (I understand this is a bigger challenge and is not working with the way
> Neutron networks
> work today, but we can iterate on this as well since its unrelated to the
> security subject)
>
> Thanks
> Gal.
>
> [1]
> https://github.com/openstack/neutron-specs/blob/master/specs/liberty/unaddressed-port.rst
> [2] https://review.openstack.org/#/c/218470/
>



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

[openstack-dev] [nova] [docs] Are cells still 'experimental'?

[Lana Brindley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi John,

I noticed while looking through some Nova docs bugs that the Config Ref
lists cells as experimental:

http://docs.openstack.org/kilo/config-reference/content/section_compute-
cells.html

Is this still true?

Thanks,
Lana

- -- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJV57atAAoJELppzVb4+KUyjzYIAIain4YZauEcMEMNYfdI74Lj
qmUO4U5kTkg7dFcsW1DJhhPvPjgsJPKRcMFofcZEB7qV+QcCbDx9g691NlB3u1dG
MEOtBq9y5o1PJMPxl8xcbHaOLm028E4f7oUrlODpQs/dlWS8vfXpOeT/CwYsqFG4
lF08/YpvNaNLBytCjbFgFqmQt5I+8gLBmyXgRl06+HflgjYsr6fQyjQzMlVfioPW
5IYg0p+Zj4B/MxRo5xCWph0e9YdeE3CBpqGB33iay06341Sh0cVi0O4QPTZ/f2tA
TbZzskHDKJoEb6kqbz4jMtzoDSr76N4+ltwMynzpCY/I8tyuV+Yj5vIWO79Wo6Q=
=hjD8
-END PGP SIGNATURE-

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

Re: [openstack-dev] [Glance] Feature Freeze Exception proposal

[Fei Long Wang]

+1 It would be nice to have it.

On 03/09/15 14:11, Nikhil Komawar wrote:
> Hi,
>
> I wanted to propose 'Single disk image OVA import' [1] feature proposal
> for exception. This looks like a decently safe proposal that should be
> able to adjust in the extended time period of Liberty. It has been
> discussed at the Vancouver summit during a work session and the proposal
> has been trimmed down as per the suggestions then; has been overall
> accepted by those present during the discussions (barring a few changes
> needed on the spec itself). It being a addition to already existing
> import task, doesn't involve API change or change to any of the core
> Image functionality as of now.
>
> Please give your vote: +1 or -1 .
>
> [1] https://review.openstack.org/#/c/194868/
>

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


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

Re: [openstack-dev] [Fuel] Nominate Evgeniy Konstantinov for fuel-docs core

[Anastasia Urlapova]

+1

On Wed, Sep 2, 2015 at 4:03 PM, Dmitry Borodaenko 
wrote:

> +1, Evgeny has been a #1 committer in fuel-docs for a while, it's great to
> see him pick up on the reviews, too.
>
> On Wed, Sep 2, 2015 at 3:24 PM Irina Povolotskaya <
> ipovolotsk...@mirantis.com> wrote:
>
>> Fuelers,
>>
>> I'd like to nominate Evgeniy Konstantinov for the fuel-docs-core team.
>> He has contributed thousands of lines of documentation to Fuel over
>> the past several months, and has been a diligent reviewer:
>>
>>
>> http://stackalytics.com/?user_id=evkonstantinov=all_type=all=fuel-docs
>>
>> I believe it's time to grant him core reviewer rights in the fuel-docs
>> repository.
>>
>> Core reviewer approval process definition:
>> https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>>
>> --
>> Best regards,
>>
>> Irina
>>
>>
>>
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Glance] Feature Freeze Exception proposal

[Nikhil Komawar]

Hi,

I wanted to propose 'Single disk image OVA import' [1] feature proposal
for exception. This looks like a decently safe proposal that should be
able to adjust in the extended time period of Liberty. It has been
discussed at the Vancouver summit during a work session and the proposal
has been trimmed down as per the suggestions then; has been overall
accepted by those present during the discussions (barring a few changes
needed on the spec itself). It being a addition to already existing
import task, doesn't involve API change or change to any of the core
Image functionality as of now.

Please give your vote: +1 or -1 .

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

-- 

Thanks,
Nikhil


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

Re: [openstack-dev] [neutron][db] reviewers: please mind the branch a script belongs to

[Vikram Choudhary]

Thanks for sharing this Ihar!

Thanks
Vikram
On Sep 3, 2015 2:13 AM, "Carl Baldwin"  wrote:

> Thanks, I learned a thing or two from the document that you linked.
> Thanks for reminding us of that.
>
> Carl
>
> On Tue, Sep 1, 2015 at 3:14 AM, Ihar Hrachyshka 
> wrote:
> > Hi reviewers,
> >
> > several days ago, a semantically expand-only migration script was merged
> into contract branch [1]. This is not a disaster, though it would be a tiny
> one if a contract-only migration script would be merged into expand branch.
> >
> > Please make sure you know the new migration strategy described in [2].
> >
> > Previously, we introduced a check that validates that we don’t mix
> down_revision heads, linking e.g. expand script to contract revision, or
> vice versa [3]. Apparently, it’s not enough.
> >
> > Ann is looking into introducing another check for semantical correctness
> of scripts. I don’t believe it may work for all complex cases we may need
> to solve manually, but at least it should be able to catch add_* operations
> in contract scripts, or drop_* operations in expand branch. Since there may
> be exceptions to general automation, we may also need a mechanism to
> disable such a sanity check for specific scripts.
> >
> > So all in all, I kindly ask everyone to become aware of how we now
> manage migration scripts, and what it implies in how we should review code
> (f.e. looking at paths as well as the code of alembic scripts). That is
> especially important before the test that Ann is looking to implement is
> not merged.
> >
> > [1]: https://bugs.launchpad.net/neutron/+bug/1490767
> > [2]:
> http://docs.openstack.org/developer/neutron/devref/alembic_migrations.html
> > [3]: https://review.openstack.org/#/c/206746/
> >
> > Thanks
> > Ihar
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Alex Schultz to Fuel-Library Core

[Anastasia Urlapova]

+1

On Thu, Sep 3, 2015 at 2:49 AM, Aleksandr Didenko 
wrote:

> Hi,
>
> +1 from me.
>
> Regards,
> Alex
>
> On Wed, Sep 2, 2015 at 5:00 PM, Vladimir Kuklin 
> wrote:
>
>> +1 and also he is in US timezone, which  should help us cover the globe
>> with Continuous Review process.
>>
>> On Wed, Sep 2, 2015 at 3:45 PM, Dmitry Borodaenko <
>> dborodae...@mirantis.com> wrote:
>>
>>> Huge +1 from me, Alex has all the best qualities of a core reviewer:
>>> great engineer, great communicator, diligent, and patient.
>>>
>>> On Wed, Sep 2, 2015 at 3:24 PM Jay Pipes  wrote:
>>>
 I'm not a Fuel core or anything, but +1 from me. Alex has been very
 visible in the community and his work on librarian-puppet was a great
 step forward for the project.

 Best,
 -jay

 On 09/02/2015 04:31 AM, Sergii Golovatiuk wrote:
 > Hi,
 >
 > I would like to nominate Alex Schultz to Fuel-Library Core team. He’s
 > been doing a great job in writing patches. At the same time his
 reviews
 > are solid with comments for further improvements. He’s #3 reviewer and
 > #1 contributor with 46 commits for last 90 days [1]. Additionally,
 Alex
 > has been very active in IRC providing great ideas. His ‘librarian’
 > blueprint [3] made a big step towards to puppet community.
 >
 > Fuel Library, please vote with +1/-1 for approval/objection. Voting
 will
 > be open until September 9th. This will go forward after voting is
 closed
 > if there are no objections.
 >
 > Overall contribution:
 > [0] http://stackalytics.com/?user_id=alex-schultz
 > Fuel library contribution for last 90 days:
 > [1] http://stackalytics.com/report/contribution/fuel-library/90
 > List of reviews:
 > [2]
 >
 https://review.openstack.org/#/q/reviewer:%22Alex+Schultz%22+status:merged,n,z
 > ‘Librarian activities’ in mailing list:
 > [3]
 http://lists.openstack.org/pipermail/openstack-dev/2015-July/071058.html
 >
 > --
 > Best regards,
 > Sergii Golovatiuk,
 > Skype #golserge
 > IRC #holser
 >
 >
 >
 __
 > OpenStack Development Mailing List (not for usage questions)
 > Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 >


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

>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com 
>> www.mirantis.ru
>> vkuk...@mirantis.com
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [puppet] hosting developer documentation on http://docs.openstack.org/developer/

[Emilien Macchi]

TL;DR, I propose to move our developer documentation from wiki to
something like http://docs.openstack.org/developer/puppet-openstack

(Look at http://docs.openstack.org/developer/tempest/ for example).

For now, most of our documentation is on
https://wiki.openstack.org/wiki/Puppet but I think it would be great to
use RST format and Gerrit so anyone could submit documentation
contribute like we do for code.

I propose a basic table of contents now:
Puppet modules introductions
Coding Guide
Reviewing code

I'm taking the opportunity of the puppet sprint to run this discussion
and maybe start some work of people agrees to move on.

Thanks,
-- 
Emilien Macchi



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

[openstack-dev] [kolla][announce] Announcing release of Liberty-3 Milestone!

[Steven Dake (stdake)]

The Kolla community is pleased to announce the release of the Kolla Liberty 3 
milestone.  This release fixes 90 bugs and implements 16 blueprints!


During Liberty 3, Kolla joined the big tent governance!  Our project can be 
found here:


http://governance.openstack.org/reference/projects/index.html


As part of the project renames happening in OpenStack Infrastructure, the 
project will be moving to the openstack git namespace September 11th [1].


Our community developed the following notable features in Liberty-3:


  *   Mult-inode deployment using Ansible with complete high availability.
  *   Ubuntu source building implemented.
  *   Compose support has been removed in favor of a new Ansible framework 
which supports multinode deployment of all core services.
  *   Implementation of a new compact build tool written in Python which allows 
for building images which is fully featured.
  *   All docker files were converted to Jinja-2 templates allowing tidy 
multi-distro support.
  *   Building behind proxy implemented.
  *   Vastly improved the documentation (The documentation still needs a lot of 
work!).
  *   Improved coverage of stable image builds in gates.
  *   Packaging Kolla with PBR python toolset.


The following services are stable and may be deployed multi-node via Ansible:

  *   glance
  *   hapoxy
  *   heat
  *   horizon
  *   keytone
  *   mariadb
  *   memcached
  *   neutron
  *   nova
  *   rabbitmq
  *   swift


Kolla's implementation is stable and Kolla is ready for evaluation by operators 
and third party projects. The Kolla community encourages individuals to 
evaluate the project and provide feedback via the mailing list or irc!


Finally, Kola has a solid crew of reviewers that are not on the core team.  We 
hope that folks interested in joining the core reviewer team will continue 
reviewing - we definitely appreciate the reviews!  Our project is highly 
diverse.  To get an idea for those contributing, check out [2].


Regards,

- The Kolla Development Team


 [1] http://lists.openstack.org/pipermail/openstack-dev/2015-August/073049.html

 [2] http://stackalytics.com/?module=kolla-group=person-day

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

Re: [openstack-dev] [puppet] hosting developer documentation on http://docs.openstack.org/developer/

[Colleen Murphy]

On Wed, Sep 2, 2015 at 11:09 AM, Emilien Macchi  wrote:

> TL;DR, I propose to move our developer documentation from wiki to
> something like http://docs.openstack.org/developer/puppet-openstack
>
> (Look at http://docs.openstack.org/developer/tempest/ for example).
>
> For now, most of our documentation is on
> https://wiki.openstack.org/wiki/Puppet but I think it would be great to
> use RST format and Gerrit so anyone could submit documentation
> contribute like we do for code.
>
> I propose a basic table of contents now:
> Puppet modules introductions
> Coding Guide
> Reviewing code
>
> I'm taking the opportunity of the puppet sprint to run this discussion
> and maybe start some work of people agrees to move on.
>
> Thanks,
> --
> Emilien Macchi
>
Please consider the Puppet Approved criteria[1] when making decisions about
documentation. In particular, we should be making sure the README contained
within the module is complete. Publishing .rst docs to docs.o.o is not a
substitute.

The READMEs and examples/ in our modules are generally inaccurate or out of
date. We should focus on enhancing the content of our docs before worrying
about the logistics of publishing them.

Colleen

[1] https://forge.puppetlabs.com/approved/criteria
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Security] Weekly meeting cancelled due to Mid-Cycle

[Clark, Robert Graham]

Security folks,

Tomorrow’s mid-cycle is cancelled due to many of us attending the Mid-cycle.

-Rob


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

[openstack-dev] [ironic] [tripleo] [kolla] Possible to support multiple compute drivers?

[Jeff Peeler]

Hi folks,

I'm currently looking at supporting Ironic in the Kolla project [1], but
was unsure if it would be possible to run separate instances of nova
compute and controller (and scheduler too?) to enable both baremetal and
libvirt type deployments. I found this mailing list post from two years ago
[2], asking the same question. The last response in the thread seemed to
indicate work was being done on the scheduler to support multiple
configurations, but the review [3] ended up abandoned.

Are the current requirements the same? Perhaps using two availability zones
would work, but I'm not clear if that works on the same host.

[1] https://review.openstack.org/#/c/219747/
[2] http://lists.openstack.org/pipermail/openstack/2013-August/000504.html
[3] https://review.openstack.org/#/c/37407/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][db] reviewers: please mind the branch a script belongs to

[Carl Baldwin]

Thanks, I learned a thing or two from the document that you linked.
Thanks for reminding us of that.

Carl

On Tue, Sep 1, 2015 at 3:14 AM, Ihar Hrachyshka  wrote:
> Hi reviewers,
>
> several days ago, a semantically expand-only migration script was merged into 
> contract branch [1]. This is not a disaster, though it would be a tiny one if 
> a contract-only migration script would be merged into expand branch.
>
> Please make sure you know the new migration strategy described in [2].
>
> Previously, we introduced a check that validates that we don’t mix 
> down_revision heads, linking e.g. expand script to contract revision, or vice 
> versa [3]. Apparently, it’s not enough.
>
> Ann is looking into introducing another check for semantical correctness of 
> scripts. I don’t believe it may work for all complex cases we may need to 
> solve manually, but at least it should be able to catch add_* operations in 
> contract scripts, or drop_* operations in expand branch. Since there may be 
> exceptions to general automation, we may also need a mechanism to disable 
> such a sanity check for specific scripts.
>
> So all in all, I kindly ask everyone to become aware of how we now manage 
> migration scripts, and what it implies in how we should review code (f.e. 
> looking at paths as well as the code of alembic scripts). That is especially 
> important before the test that Ann is looking to implement is not merged.
>
> [1]: https://bugs.launchpad.net/neutron/+bug/1490767
> [2]: 
> http://docs.openstack.org/developer/neutron/devref/alembic_migrations.html
> [3]: https://review.openstack.org/#/c/206746/
>
> Thanks
> Ihar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [TripleO][Heat] instance_user fallout, keeping the 'heat-admin' user working

[Dan Prince]

We had an IRC discussion today about the 'heat-admin' user in #tripleo.

Upstream Heat recently reverted the 'instance_user' config file option
which we relied on in TripleO to standardize the default (admin) user
on our nodes. It is my understanding that Heat would prefer not to
maintain this option because it causes subtle compatibility issues
across the OpenStack and AWS APIs and the interactions between cloud
-init version, etc. So it was deprecated in Icehouse... and recently
removed in [1].

We could just go with the default distro user (centos, fedora, ubuntu,
etc.) but it would be really nice to standardize on a user name for
maintenance should anyone every spin up a cloud using multiple distros
or something.

So a couple of options. We could just go on and update our templates
like this [2]. This actually seems pretty clean to me, but it would
require anybody who has created custom firstboot scripts to do the same
(we have proposed docker patches with firstboot scripts that need
similar updates).

Alternately, we could propose that Heat revert the instance_user
feature or some version of it. We've been using that for a year or two
now and it has actually been fairly nice to set the default that way.

Thoughts?


[1] https://review.openstack.org/103928 

[2] https://review.openstack.org/#/c/219861/

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

[openstack-dev] [Congress] Feedback on distributed architecture

[Tim Hinrichs]

I ran the basics of our new distributed architecture by Shawn from
Twitter.  Here's his response.


 We just held a Congress mid-cycle meet-up to discuss its distributed
architecture.  We decided on an architecture where the policy engine runs
in its own process; each datasource driver runs in its own process; the API
runs in its own process; and all communicate over a RabbitMQ-style message
bus.

This would enable you to choose which part of Congress you run on which
physical host.  You could run the policy engine on the same box as the
service you're using policy to protect.  You can build the datasource
driver logic into a datasource and push deltas directly to the RabbitMQ
message bus.  And of course you could run everything on a
Congress-dedicated box and ignore these details.

See any major problems with Congress's new distributed architecture, or
things you think should change?  Do you think that running the policy
engine on the same box as the service you're protecting is a good idea or a
bad one?

I suspect RabbitMQ may end up being a bottleneck but it makes sense
to deal with that when it comes up. Will you be relying on
RabbitMQ-specific features or will any given AMQP broker suffice? Which
version of AMQP will you be using?


OpenStack has a wrapper around AMQP buses, and we're using that.  We
haven't gone any further into choices about which plugin to use.

I think the choice of where to run the datasource makes sense,
though I need to give some thought to wiring up my datasources directly to
the AMQP broker instead of submitting via a well-defined REST or thrift API
with realtime payload validation, backpressure, etc. I can't tell whether
my hesitation is legit or just FUD.

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

Re: [openstack-dev] [Blazar] Anyone interested?

[Nikolay Starodubtsev]

Pierre, thanks for explanation. However it's great.

I agree with Sylvain. Let's switch to #openstack-blazar channel in IRC.



Nikolay Starodubtsev

Software Engineer

Mirantis Inc.


Skype: dark_harlequine1

2015-09-02 19:04 GMT+03:00 Sylvain Bauza :

>
>
> Le 02/09/2015 17:50, Pierre Riteau a écrit :
>
> On 1 Sep 2015, at 23:15, Sylvain Bauza  wrote:
>
> Le 01/09/2015 22:31, Ildikó Váncsa a écrit :
>
> Hi,
>
> I'm glad to see the interest and I also support the idea of using the IRC
> channel that is already set up for further communication. Should we aim for
> a meeting/discussion there around the end of this week or during next week?
>
> @Nikolay, Sylvain: Thanks for support and bringing together a list of
> action items as very first steps.
>
> @Pierre: You wrote that you are using Blazar. Are you using it as is with
> an older version of OpenStack or you have a modified version of the
> project/code?
>
> I'm actually really surprised to see
> https://www.chameleoncloud.org/docs/user-guides/bare-metal-user-guide/ which
> describes quite fine how to use Blazar/Climate either using the CLI or by
> Horizon.
>
> The latter is actually not provided within the git tree, so I guess
> Chameleon added it downstream. That's fine, maybe something we could
> upstream if Pierre and his team are okay ?
>
> -Sylvain
>
>
> We are using a modified version of Blazar (based on the latest master
> branch commit) with OpenStack Juno (RDO packaging).
>
> The only really mandatory patch that we had to develop was for blazar-nova
> due to functions moving from oslo-incubator to oslo.i18n:
> https://github.com/ChameleonCloud/blazar-nova/commit/346627320e87c8e067db6e842935d243c9640e6e
> On top of this we developed a number of patches, most of them to fix bugs
> that we discovered in Blazar, with a few to get specific features or
> behavior required for Chameleon.
>
> We also used the code developed by Pablo (
> http://lists.openstack.org/pipermail/openstack-dev/2014-June/038506.html)
> to provide an Horizon dashboard for creating and managing leases.
> We even developed a Gantt chart of physical node reservations, but this
> code reads data straight from the SQL database rather than using a new
> Blazar API, so it cannot be contributed as is.
>
> We have always wanted to contribute back our improvements to Blazar and we
> are looking forward to it now that there is renewed interest from the
> community.
> All our OpenStack code should already be available on GitHub at
> https://github.com/ChameleonCloud/
>
>
> That's great work, thanks for the explanations Pierre.
> Since you're looking like the Blazar maintainer while Winter was coming,
> I'd certainly consider your commitment as enough trustable for being
> backported to the master branch.
>
> Nikolay, you told that the Blazar gate is broken, right ? I take that as
> action #0 to fix, and then we can try to backport Pierre's changes into the
> master branch.
>
> Now, let's switch over IRC, I don't want to pollute the ML for those
> technical details.
>
> Anyone who still wants to contribute to Blazar can join #openstack-blazar
> and yell, for sure.
>
> -Sylvain
>
> Pierre
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] hosting developer documentation on http://docs.openstack.org/developer/

[Anita Kuno]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/02/2015 02:09 PM, Emilien Macchi wrote:
> TL;DR, I propose to move our developer documentation from wiki to 
> something like 
> http://docs.openstack.org/developer/puppet-openstack
> 
> (Look at http://docs.openstack.org/developer/tempest/ for 
> example).

Looking at the tempest example:
http://git.openstack.org/cgit/openstack/tempest/tree/doc/source
we see that the .rst files all live in the tempest repo in doc/source
(with the exception of the README.rst file with is referenced from
within doc/source when required:
http://git.openstack.org/cgit/openstack/tempest/tree/doc/source/overview.rst)

So question: Where should the source .rst files for puppet developer
documentation live? They will need a home.

Thanks,
Anita.

> 
> For now, most of our documentation is on 
> https://wiki.openstack.org/wiki/Puppet but I think it would be 
> great to use RST format and Gerrit so anyone could submit 
> documentation contribute like we do for code.
> 
> I propose a basic table of contents now: Puppet modules 
> introductions Coding Guide Reviewing code
> 
> I'm taking the opportunity of the puppet sprint to run this 
> discussion and maybe start some work of people agrees to move on.
> 
> Thanks,
> 
> 
> 
> __
>
>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJV50RhAAoJELmKyZugNFU0X1sIANlLUwxe8i+vlRISuPQFBzWR
a8h4VybYRz1kz64LthKbwYaX5yRGyyn5ir0BbwC4cvxaN1J8P46/hJ7lAEe3BxWL
t5hqPdL40xSNcBLLX8EaJPS1ohO9V13k/qFstbWu3pF0tXYcqRiX53X1pS7v8VpL
19qXElddTTu9Nn6NAGeJS8fL/h5N67dBC0/S2K0kEHaXQI7yRB2uvUSwOsWQTswC
s/XVuGy/wQgHESbIEaiNgk49BjMm+5bYB187hJa97SuIjsGyIcUZsz44nZcyjlbv
cAmhhjkxgtFgM2znGuYXJGb5CKfZn+1qFgNhDGxFuQhFUuxRpRyaxkGLxq1fGaw=
=rk94
-END PGP SIGNATURE-

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

Re: [openstack-dev] [openstack-announce] [release][nova] python-novaclient release 2.27.0 (liberty)

[Jeremy Stanley]

On 2015-09-02 10:55:56 -0400 (-0400), d...@doughellmann.com wrote:
> We are thrilled to announce the release of:
> 
> python-novaclient 2.27.0: Client library for OpenStack Compute API
[...]

Just as a heads up, there's some indication that this release is
currently broken by many popular service providers (behavior ranging
from 401 unauthorized errors to hanging indefinitely due, it seems,
to filtering or not supporting version detection in various ways).

https://launchpad.net/bugs/1491579

-- 
Jeremy Stanley

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

Re: [openstack-dev] [puppet] hosting developer documentation on http://docs.openstack.org/developer/

[Emilien Macchi]

On 09/02/2015 02:53 PM, Colleen Murphy wrote:
> 
> 
> On Wed, Sep 2, 2015 at 11:09 AM, Emilien Macchi  > wrote:
> 
> TL;DR, I propose to move our developer documentation from wiki to
> something like http://docs.openstack.org/developer/puppet-openstack
> 
> (Look at http://docs.openstack.org/developer/tempest/ for example).
> 
> For now, most of our documentation is on
> https://wiki.openstack.org/wiki/Puppet but I think it would be great to
> use RST format and Gerrit so anyone could submit documentation
> contribute like we do for code.
> 
> I propose a basic table of contents now:
> Puppet modules introductions
> Coding Guide
> Reviewing code
> 
> I'm taking the opportunity of the puppet sprint to run this discussion
> and maybe start some work of people agrees to move on.
> 
> Thanks,
> --
> Emilien Macchi
> 
> Please consider the Puppet Approved criteria[1] when making decisions
> about documentation. In particular, we should be making sure the README
> contained within the module is complete. Publishing .rst docs to
> docs.o.o is not a substitute.

+1 for how to use and consume our puppet modules.
But my proposal is about developer documentation which is related to
coding style, reviewing code manuals. Not how to deploy puppet-* itself,
but OpenStack things related. Tell me if I'm wrong and if it also should
live in README but I'm not sure here.

AFIK, Hunter and Cody are working on improving README doc to get modules
approved, during this sprint.

> The READMEs and examples/ in our modules are generally inaccurate or out
> of date. We should focus on enhancing the content of our docs before
> worrying about the logistics of publishing them.
> 
> Colleen 
> 
> [1] https://forge.puppetlabs.com/approved/criteria
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Emilien Macchi



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

Re: [openstack-dev] [Ironic] Command structure for OSC plugin

[Doug Hellmann]

Excerpts from Tim Bell's message of 2015-09-02 18:50:57 +:
> > -Original Message-
> > From: Doug Hellmann [mailto:d...@doughellmann.com]
> > Sent: 02 September 2015 16:21
> > To: openstack-dev 
> > Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin
> > 
> > Excerpts from Tim Bell's message of 2015-09-02 05:15:35 +:
> > > That would be great to have plugins on the commands which are relevant
> > to multiple projects… avoiding exposing all of the underlying projects as
> > prefixes and getting more consistency would be very appreciated by the
> > users.
> > 
> > That works in some cases, but in a lot of cases things that are 
> > superficially
> > similar have important differences in the inputs they take. In those cases, 
> > it's
> > better to be explicit about the differences than to force the concepts 
> > together
> > in a way that makes OSC present only the least-common denominator
> > interface.
> > 
> 
> I think the difference are in the options rather than the prefixes. Thus, if 
> I want to create a bare metal server, I should be able to use 'openstack 
> create' rather than 'openstack ironic create'. The various implications on 
> options etc. are clearly dependent on the target environment.
> 
> I would simply like to avoid that the OSC becomes a prefix, i.e. you need to 
> know that ironic is for baremetal. If options are presented which are not 
> supported in the desired context, they should be rejected. 

This is the long-standing debate over whether it's better to constrain
the inputs up front, or accept anything and then validate it and
reject bad inputs after they are presented. My UI training always
indicated that assisting to get the inputs right up front was better,
and that's what I think we're trying to do with OSC.

Having an "openstack server create" command that works for all
services that produce things that look like servers means the user
has to somehow determine which of the options are related to which
of the types of servers. We can do some work to group options in
help output, and express which are mutually exclusive, but that
only goes so far. At some point the user ends up having to know
that when "--type baremetal" is provided, the "--container-type"
option used for containers isn't valid at all. There's no way to
express that level of detail in the tools we're using right now,
in part because it results in a more complex UI.

Having an "openstack baremetal create" command is more like the
up-front constraint, because the user can use --help to discover
exactly which options are valid for a baremetal server. It shifts
that "--type baremetal" option into the command name, where the
tools we use to build OSC can let us express exactly which other
options are valid, and (implicitly) which are not.

Placing "baremetal" as the first part of the command was an intentional
choice -- we call this the "noun first" form, versus the "verb
first" form "create baremetal". We considered that the user understands
what kind of resource they're trying to issue a command on, but may
not know all of the commands available for that resource type. With
tab-completion enabled, "openstack baremetal" will give them
the list of commands for doing anything to baremetal servers. It
also means all of the commands for a given resource type are listed
together in the global help output where we list all available
subcommands.

> 
> At CERN, we're using OSC as the default CLI. This is partly because the 
> support for Keystone v3 API is much more advanced but also because we do not 
> want our end users to know the list of OpenStack projects, only the services 
> we are offering them.

Using resource type names rather than services is definitely
preferred. That falls down when we have 2 services providing similar
(or the same) resource types. For example, I could see some overlap
in command names and resource types for Cue and Zaqar.

Doug

> 
> Tim
> 
> > Doug
> > 
> > >
> > > Tim
> > >
> > > From: Dean Troyer [mailto:dtro...@gmail.com]
> > > Sent: 01 September 2015 22:47
> > > To: OpenStack Development Mailing List (not for usage questions)
> > > 
> > > Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin
> > >
> > > [late catch-up]
> > >
> > > On Mon, Aug 24, 2015 at 2:56 PM, Doug Hellmann
> > > wrote:
> > > Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:
> > > > On 24/08/15 18:19 +, Tim Bell wrote:
> > > > >
> > > > >From a user perspective, where bare metal and VMs are just different
> > flavors (with varying capabilities), can we not use the same commands
> > (server create/rebuild/...) ? Containers will create the same conceptual
> > problems.
> > > > >
> > > > >OSC can provide a converged interface but if we just replace '$ ironic
> > ' by '$ openstack baremetal ', this seems to be a 

Re: [openstack-dev] [puppet] hosting developer documentation on http://docs.openstack.org/developer/

[Iury Gregory]

I liked the idea (+1)

2015-09-02 15:09 GMT-03:00 Emilien Macchi :

> TL;DR, I propose to move our developer documentation from wiki to
> something like http://docs.openstack.org/developer/puppet-openstack
>
> (Look at http://docs.openstack.org/developer/tempest/ for example).
>
> For now, most of our documentation is on
> https://wiki.openstack.org/wiki/Puppet but I think it would be great to
> use RST format and Gerrit so anyone could submit documentation
> contribute like we do for code.
>
> I propose a basic table of contents now:
> Puppet modules introductions
> Coding Guide
> Reviewing code
>
> I'm taking the opportunity of the puppet sprint to run this discussion
> and maybe start some work of people agrees to move on.
>
> Thanks,
> --
> Emilien Macchi
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

~


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

Re: [openstack-dev] [puppet] hosting developer documentation on http://docs.openstack.org/developer/

[Gui Maluf]

I loved the idea. This could also aim the good practices of puppet workflow
development, like setting up an rspec environment, using beaker to deploy
an test it's own code, an stuff like this.

+1

On Wed, Sep 2, 2015 at 3:13 PM, Iury Gregory  wrote:

> I liked the idea (+1)
>
> 2015-09-02 15:09 GMT-03:00 Emilien Macchi :
>
>> TL;DR, I propose to move our developer documentation from wiki to
>> something like http://docs.openstack.org/developer/puppet-openstack
>>
>> (Look at http://docs.openstack.org/developer/tempest/ for example).
>>
>> For now, most of our documentation is on
>> https://wiki.openstack.org/wiki/Puppet but I think it would be great to
>> use RST format and Gerrit so anyone could submit documentation
>> contribute like we do for code.
>>
>> I propose a basic table of contents now:
>> Puppet modules introductions
>> Coding Guide
>> Reviewing code
>>
>> I'm taking the opportunity of the puppet sprint to run this discussion
>> and maybe start some work of people agrees to move on.
>>
>> Thanks,
>> --
>> Emilien Macchi
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> ~
>
>
> *Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science
> at UFCG*
> *E-mail:  iurygreg...@gmail.com *
> ~
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [Ironic] Command structure for OSC plugin

[Dean Troyer]

On Wed, Sep 2, 2015 at 2:29 PM, Doug Hellmann  wrote:

> Excerpts from Tim Bell's message of 2015-09-02 18:50:57 +:
> > I think the difference are in the options rather than the prefixes.
> Thus, if I want to create a bare metal server, I should be able to use
> 'openstack create' rather than 'openstack ironic create'. The various
> implications on options etc. are clearly dependent on the target
> environment.
> >
> > I would simply like to avoid that the OSC becomes a prefix, i.e. you
> need to know that ironic is for baremetal. If options are presented which
> are not supported in the desired context, they should be rejected.
>
> This is the long-standing debate over whether it's better to constrain
> the inputs up front, or accept anything and then validate it and
> reject bad inputs after they are presented. My UI training always
> indicated that assisting to get the inputs right up front was better,
> and that's what I think we're trying to do with OSC.
>
> Having an "openstack server create" command that works for all
> services that produce things that look like servers means the user
> has to somehow determine which of the options are related to which
> of the types of servers. We can do some work to group options in
> help output, and express which are mutually exclusive, but that
> only goes so far. At some point the user ends up having to know
> that when "--type baremetal" is provided, the "--container-type"
> option used for containers isn't valid at all. There's no way to
> express that level of detail in the tools we're using right now,
> in part because it results in a more complex UI.
>

To do this now requires manually implementing it in the commands
themselves, but I am willing to do that as I do think the end result is a
lower footprint UI.  The biggest problem we have is the help output, that
is not solved yet, but we have been clear in the documentation when options
are only applicable with or without other options also present.


> Having an "openstack baremetal create" command is more like the
> up-front constraint, because the user can use --help to discover
> exactly which options are valid for a baremetal server. It shifts
> that "--type baremetal" option into the command name, where the
> tools we use to build OSC can let us express exactly which other
> options are valid, and (implicitly) which are not.
>

We have started using multiple word nouns for disambiguation, in this case,
I would suggest 'baremetal server' as 'baremetal' is not a thing by
itself.  I think this is an acceptable compromise as it still contains
'server' as the concepts involved are fundamentally the same thing.
 'server create --type baremental' would still be my preference, even with
it being more work inside OSC/plugins.

dt

-- 

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

Re: [openstack-dev] [Neutron][horizon][neutron][L3][dvr][fwaas] FWaaS

[Eichberger, German]

Hi Bharath,

I am wondering if you can file this as a launchpad bug, please.

Thanks,
German

From: bharath >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, September 2, 2015 at 9:21 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [Neutron][horizon][neutron][L3][dvr][fwaas] FWaaS

Hi,

Horizon seems to be broken.

When i try to add new firewall rule , horizon broken with "'NoneType' object 
has no attribute 'id'" Error.
This was fine about 10 hours back. Seems one of the  latest commit broken it.


Traceback in horizon:


2015-09-02 16:15:35.337872 return nodelist.render(context)
2015-09-02 16:15:35.337877   File 
"/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 903, in 
render
2015-09-02 16:15:35.337893 bit = self.render_node(node, context)
2015-09-02 16:15:35.337899   File 
"/usr/local/lib/python2.7/dist-packages/django/template/debug.py", line 79, in 
render_node
2015-09-02 16:15:35.337903 return node.render(context)
2015-09-02 16:15:35.337908   File 
"/usr/local/lib/python2.7/dist-packages/django/template/debug.py", line 89, in 
render
2015-09-02 16:15:35.337913 output = self.filter_expression.resolve(context)
2015-09-02 16:15:35.337917   File 
"/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 647, in 
resolve
2015-09-02 16:15:35.337922 obj = self.var.resolve(context)
2015-09-02 16:15:35.337927   File 
"/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 787, in 
resolve
2015-09-02 16:15:35.337931 value = self._resolve_lookup(context)
2015-09-02 16:15:35.337936   File 
"/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 825, in 
_resolve_lookup
2015-09-02 16:15:35.337940 current = getattr(current, bit)
2015-09-02 16:15:35.337945   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/utils/html.py", line 
59, in attr_string
2015-09-02 16:15:35.337950 return flatatt(self.get_final_attrs())
2015-09-02 16:15:35.337954   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/utils/html.py", line 
42, in get_final_attrs
2015-09-02 16:15:35.337959 final_attrs['class'] = self.get_final_css()
2015-09-02 16:15:35.337964   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/utils/html.py", line 
47, in get_final_css
2015-09-02 16:15:35.337981 default = " ".join(self.get_default_classes())
2015-09-02 16:15:35.337986   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/base.py", 
line 792, in get_default_classes
2015-09-02 16:15:35.337991 if not self.url:
2015-09-02 16:15:35.337995   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/base.py", 
line 756, in url
2015-09-02 16:15:35.338000 url = self.column.get_link_url(self.datum)
2015-09-02 16:15:35.338004   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/base.py", 
line 431, in get_link_url
2015-09-02 16:15:35.338009 return self.link(datum)
2015-09-02 16:15:35.338014   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/project/firewalls/tables.py",
 line 261, in get_policy_link
2015-09-02 16:15:35.338019 kwargs={'policy_id': datum.policy.id})
2015-09-02 16:15:35.338023 AttributeError: 'NoneType' object has no attribute 
'id'



Thanks,
bharath

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

[openstack-dev] [nfv][telcowg] Issues with vIMS and SBC submissions

[Steve Gordon]

Hi Calum,

After the discussion at the end of the meeting I *believe* I have fixed the 
issues with these two - please review and check I didn't accidentally drop any 
of your changes:

* SBC: https://review.openstack.org/#/c/176301/
  - Removed the erroneously included usecases/Virtual_IMS_Core.rst (on review 
it seems this was the same as the one in 179142 below).
  - Attempted to fix the syntax of the literal block around your ASCII flow 
diagram (seemed to test ok locally...).
* vIMS: https://review.openstack.org/#/c/179142/
  - Removed the dependency on a long-abandoned draft.

Thanks,

-Steve

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

Re: [openstack-dev] [Neutron][horizon][neutron][L3][dvr][fwaas] FWaaS

[Lin Hua Cheng]

Opened a launchpad bug for tracking:
https://bugs.launchpad.net/horizon/+bug/1491637

-Lin

On Wed, Sep 2, 2015 at 2:28 PM, Eichberger, German  wrote:

> Hi Bharath,
>
> I am wondering if you can file this as a launchpad bug, please.
>
> Thanks,
> German
>
> From: bharath >
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org >>
> Date: Wednesday, September 2, 2015 at 9:21 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org >>
> Subject: [openstack-dev] [Neutron][horizon][neutron][L3][dvr][fwaas] FWaaS
>
> Hi,
>
> Horizon seems to be broken.
>
> When i try to add new firewall rule , horizon broken with "'NoneType'
> object has no attribute 'id'" Error.
> This was fine about 10 hours back. Seems one of the  latest commit broken
> it.
>
>
> Traceback in horizon:
>
>
> 2015-09-02 16:15:35.337872 return nodelist.render(context)
> 2015-09-02 16:15:35.337877   File
> "/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 903,
> in render
> 2015-09-02 16:15:35.337893 bit = self.render_node(node, context)
> 2015-09-02 16:15:35.337899   File
> "/usr/local/lib/python2.7/dist-packages/django/template/debug.py", line 79,
> in render_node
> 2015-09-02 16:15:35.337903 return node.render(context)
> 2015-09-02 16:15:35.337908   File
> "/usr/local/lib/python2.7/dist-packages/django/template/debug.py", line 89,
> in render
> 2015-09-02 16:15:35.337913 output =
> self.filter_expression.resolve(context)
> 2015-09-02 16:15:35.337917   File
> "/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 647,
> in resolve
> 2015-09-02 16:15:35.337922 obj = self.var.resolve(context)
> 2015-09-02 16:15:35.337927   File
> "/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 787,
> in resolve
> 2015-09-02 16:15:35.337931 value = self._resolve_lookup(context)
> 2015-09-02 16:15:35.337936   File
> "/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 825,
> in _resolve_lookup
> 2015-09-02 16:15:35.337940 current = getattr(current, bit)
> 2015-09-02 16:15:35.337945   File
> "/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/utils/html.py",
> line 59, in attr_string
> 2015-09-02 16:15:35.337950 return flatatt(self.get_final_attrs())
> 2015-09-02 16:15:35.337954   File
> "/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/utils/html.py",
> line 42, in get_final_attrs
> 2015-09-02 16:15:35.337959 final_attrs['class'] = self.get_final_css()
> 2015-09-02 16:15:35.337964   File
> "/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/utils/html.py",
> line 47, in get_final_css
> 2015-09-02 16:15:35.337981 default = "
> ".join(self.get_default_classes())
> 2015-09-02 16:15:35.337986   File
> "/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/base.py",
> line 792, in get_default_classes
> 2015-09-02 16:15:35.337991 if not self.url:
> 2015-09-02 16:15:35.337995   File
> "/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/base.py",
> line 756, in url
> 2015-09-02 16:15:35.338000 url = self.column.get_link_url(self.datum)
> 2015-09-02 16:15:35.338004   File
> "/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/base.py",
> line 431, in get_link_url
> 2015-09-02 16:15:35.338009 return self.link(datum)
> 2015-09-02 16:15:35.338014   File
> "/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/project/firewalls/tables.py",
> line 261, in get_policy_link
> 2015-09-02 16:15:35.338019 kwargs={'policy_id': datum.policy.id})
> 2015-09-02 16:15:35.338023 AttributeError: 'NoneType' object has no
> attribute 'id'
>
>
>
> Thanks,
> bharath
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-announce] [release][nova] python-novaclient release 2.27.0 (liberty)

[Matt Riedemann]

On 9/2/2015 3:40 PM, Jeremy Stanley wrote:

On 2015-09-02 10:55:56 -0400 (-0400), d...@doughellmann.com wrote:

We are thrilled to announce the release of:

python-novaclient 2.27.0: Client library for OpenStack Compute API

[...]

Just as a heads up, there's some indication that this release is
currently broken by many popular service providers (behavior ranging
from 401 unauthorized errors to hanging indefinitely due, it seems,
to filtering or not supporting version detection in various ways).

 https://launchpad.net/bugs/1491579



And:

https://bugs.launchpad.net/python-novaclient/+bug/1491325

We have a fix for ^ and I plan on putting in the request for 2.27.1 
tonight once the fix is merged.  That should unblock manila.


For the version discovery bug, we plan on talking about that in the nova 
meeting tomorrow.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [mistral][yaql] Addressing task result using YAQL function

[Nikolay Makhotkin]

Hi,

I also thought about that recently. So, I absolutely agree with this
proposal. It would be nice to see this feature in Liberty.

On Wed, Sep 2, 2015 at 2:17 PM, Renat Akhmerov 
wrote:

> FYI
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
> Begin forwarded message:
>
> *From: *Renat Akhmerov 
> *Subject: **[openstack-dev][mistral][yaql] Addressing task result using
> YAQL function*
> *Date: *2 Sep 2015 17:16:27 GMT+6
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
>
> Hi,
>
> I’d like to propose a few changes after transition to yaql 1.0:
>
> We already moved from using “$.__execution” in DSL to "execution()” and
> from “$.__env” to “env()” where “execution()” and “env()" are registered
> yaql functions. We had to do it because double underscored are prohibited
> in the new yaql.
>
>
> In the spirit of these changes I’m proposing a similar change for
> addressing task result in Mistral DSL.
>
> Currently we have the syntax “$.task_name” that we can use in yaql
> expressions to refer to corresponding task result. The current
> implementation is of that is kind of tricky and, IMO, conceptually wrong
> because referencing this kind of key leads to DB read operation that’s
> requried to fetch task result (it may be big as megabytes so it can’t be
> stored in workflow context all the time. In other words, we create a
> dictionary with side effect and change the initial semantics of dictionary.
> Along with mentioned trickiness of this approach it’s not convenient, for
> example, to debug the code because we can accidentally cause a DB
> operation.
>
> So the solution I’m proposing is to have an explicit yaql function called
> “res” or “result” to extract task result.
>
> *res()* - extracts the result of the current task, i.e. in “publish”
> clause.
> *res(‘task_name’)* - extracts the result of the task with the specified
> name. Can also be used in “publish” clause, if needed
>
> This approach seems more flexible (cause we can add any other functions
> w/o having to make significant changes in WF engine) and expressive because
> user won’t confuse $.task_name with addressing a regular workflow context
> variable.
>
> Of course, this to some extent breaks backwards compatibility. But we
> already changed yaql version which was necessary anyway so it seems like a
> good time to do it.
>
> I’d very much like to have your input on this.
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
>
>


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

[openstack-dev] [cinder] FFE Request - capacity-headroom

[Xin, Xiaohui]

Hi,
I would like to request feature freeze exception for the implementation of 
capacity-headroom.
It calculates virtual free memory and send notifications to the ceilometer 
together with other storage capacity stats.

Blueprint:
https://blueprints.launchpad.net/cinder/+spec/capacity-headroom

Spec:
https://review.openstack.org/#/c/170380/

Addressed by:
https://review.openstack.org/#/c/206923



I have addressed the latest comments related to active-active deployment 
according to Gorka Eguileor's comments and suggestions.
Please kindly review and evaluate it. Great Thanks!

Thanks
Xiaohui

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

[openstack-dev] [mistral][yaql] Addressing task result using YAQL function

[Renat Akhmerov]

Hi,

I’d like to propose a few changes after transition to yaql 1.0:

We already moved from using “$.__execution” in DSL to "execution()” and from 
“$.__env” to “env()” where “execution()” and “env()" are registered yaql 
functions. We had to do it because double underscored are prohibited in the new 
yaql.


In the spirit of these changes I’m proposing a similar change for addressing 
task result in Mistral DSL.

Currently we have the syntax “$.task_name” that we can use in yaql expressions 
to refer to corresponding task result. The current implementation is of that is 
kind of tricky and, IMO, conceptually wrong because referencing this kind of 
key leads to DB read operation that’s requried to fetch task result (it may be 
big as megabytes so it can’t be stored in workflow context all the time. In 
other words, we create a dictionary with side effect and change the initial 
semantics of dictionary. Along with mentioned trickiness of this approach it’s 
not convenient, for example, to debug the code because we can accidentally 
cause a DB operation. 

So the solution I’m proposing is to have an explicit yaql function called “res” 
or “result” to extract task result.

res() - extracts the result of the current task, i.e. in “publish” clause.
res(‘task_name’) - extracts the result of the task with the specified name. Can 
also be used in “publish” clause, if needed

This approach seems more flexible (cause we can add any other functions w/o 
having to make significant changes in WF engine) and expressive because user 
won’t confuse $.task_name with addressing a regular workflow context variable.

Of course, this to some extent breaks backwards compatibility. But we already 
changed yaql version which was necessary anyway so it seems like a good time to 
do it.

I’d very much like to have your input on this.

Renat Akhmerov
@ Mirantis Inc.



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

[openstack-dev] [cinder] How to link a change to the completed cinder-python3 blueprint?

[Victor Stinner]

Hi,

I'm porting Cinder to Python 3. There are discussions on my patches to 
decide how to link my changes to the cinder-python3 blueprint (syntax of 
the "Blueprint cinder-python3" line).


Mike Perez completed the blueprint on 2015-08-15. I don't understand 
why, the port is incomplete. I'm still writing patches to continue the port.


Because the blueprint is completed, launchpad is unable to find the 
blueprint when you click on the blueprint line from gerrit. Some people 
asked me to write the URL to the blueprint instead. The problem is that 
"git review" uses the topic "bp/https" instead of "bp/cinder-python3" in 
this case. I have to specify manually the topic ("git review -t 
bp/cinder-python3). The URL may also change in the future, using a name 
is more future proof.


Another question is how to mention the blueprint in the commit message. 
I already wrote 35 changes which were merged into Cinder using the 
syntax "Blueprint cinder-python3". But some people are now asking me to 
use the syntax "Implements: blueprint cinder-python3", "Partially 
implements: blueprint cinder-python3", "Implements: blueprint " or 
something else.


I suggest to continue to use "Blueprint cinder-python3", and maybe 
change the status of the blueprint to be able to find it again in launchpad.



cinder-python3 blueprint:
https://blueprints.launchpad.net/cinder/+spec/cinder-python3

My Python 3 patches for Cinder:
https://review.openstack.org/#/q/status:open+project:openstack/cinder+branch:master+topic:bp/cinder-python3,n,z


Note: I wrote an email because people started to vote -1 on my changes 
because of the syntax of the "blueprint" line in my commit message.


Victor

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

Re: [openstack-dev] [trove] Anyone using containers?

[Tom Fifield]

On 02/09/15 17:36, Thierry Carrez wrote:

Lowery, Mathew wrote:

Just curious if anyone is using containers in their deployments. If so,
in what capacity? What are the advantages, gotchas, and pain points?


This might trigger more responses on the openstack-operators mailing-list.



+1 :)

There are a few notes on using containers for deployment from the recent 
ops meetup here: 
https://etherpad.openstack.org/p/PAO-ops-containers-for-deployment



Regards,

Tom

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

Re: [openstack-dev] [mistral] Displaying wf hierarchy in CLI

[Renat Akhmerov]

> On 02 Sep 2015, at 14:56, Lingxian Kong  wrote:
> 
> I want to make it clear. Then, what you want to see is dependencies between 
> workflow executions? or task executions in one workflow? We know that we 
> could use a separate task or a workflow as a 'task'.

Dependencies between workflow executions. Dependencies between task executions 
is a different question.

But technically workflow executions are connected via task execution id. See 
[1].

[1] 
https://github.com/openstack/mistral/blob/master/mistral/db/v2/sqlalchemy/models.py#L217
 


Renat Akhmerov
@ Mirantis Inc.

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

Re: [openstack-dev] [heat] [gate] gate-heat-dsvm-functional-orig-mysql fails 100%

[Steven Hardy]

On Wed, Sep 02, 2015 at 09:07:57AM -0400, Sean Dague wrote:
> Today's gate firedrill #2 is the fact that in the last 12 hours heat's
> functional tests went to 100% failure - http://goo.gl/YeVrD0
> 
> There are current 14 heat changes in the gate, each will add 30 - 40
> minutes of delay as they fail and reset things behind them. So 7 - 10
> hours of gate delay for everyone because of these patches.
> 
> Could heat team members get engaged and get to the bottom of this one?

I think this is the change we need to land to fix it:

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

Can it be bumped to the head of the queue?

Steve

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

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Alex Schultz to Fuel-Library Core

[Vladimir Kuklin]

+1 and also he is in US timezone, which  should help us cover the globe
with Continuous Review process.

On Wed, Sep 2, 2015 at 3:45 PM, Dmitry Borodaenko 
wrote:

> Huge +1 from me, Alex has all the best qualities of a core reviewer: great
> engineer, great communicator, diligent, and patient.
>
> On Wed, Sep 2, 2015 at 3:24 PM Jay Pipes  wrote:
>
>> I'm not a Fuel core or anything, but +1 from me. Alex has been very
>> visible in the community and his work on librarian-puppet was a great
>> step forward for the project.
>>
>> Best,
>> -jay
>>
>> On 09/02/2015 04:31 AM, Sergii Golovatiuk wrote:
>> > Hi,
>> >
>> > I would like to nominate Alex Schultz to Fuel-Library Core team. He’s
>> > been doing a great job in writing patches. At the same time his reviews
>> > are solid with comments for further improvements. He’s #3 reviewer and
>> > #1 contributor with 46 commits for last 90 days [1]. Additionally, Alex
>> > has been very active in IRC providing great ideas. His ‘librarian’
>> > blueprint [3] made a big step towards to puppet community.
>> >
>> > Fuel Library, please vote with +1/-1 for approval/objection. Voting will
>> > be open until September 9th. This will go forward after voting is closed
>> > if there are no objections.
>> >
>> > Overall contribution:
>> > [0] http://stackalytics.com/?user_id=alex-schultz
>> > Fuel library contribution for last 90 days:
>> > [1] http://stackalytics.com/report/contribution/fuel-library/90
>> > List of reviews:
>> > [2]
>> >
>> https://review.openstack.org/#/q/reviewer:%22Alex+Schultz%22+status:merged,n,z
>> > ‘Librarian activities’ in mailing list:
>> > [3]
>> http://lists.openstack.org/pipermail/openstack-dev/2015-July/071058.html
>> >
>> > --
>> > Best regards,
>> > Sergii Golovatiuk,
>> > Skype #golserge
>> > IRC #holser
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] [gate] gate-heat-dsvm-functional-orig-mysql fails 100%

[Sergey Kraynev]

Sean, thank you for the raising it.

We know about this issue. It was related with glanceclient:
There is a fix, which fixes this issue -
https://review.openstack.org/#/c/219533/

If it's possible may you abandon changes in queue before this patch?

Regards,
Sergey.

On 2 September 2015 at 16:07, Sean Dague  wrote:

> Today's gate firedrill #2 is the fact that in the last 12 hours heat's
> functional tests went to 100% failure - http://goo.gl/YeVrD0
>
> There are current 14 heat changes in the gate, each will add 30 - 40
> minutes of delay as they fail and reset things behind them. So 7 - 10
> hours of gate delay for everyone because of these patches.
>
> Could heat team members get engaged and get to the bottom of this one?
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Murano] Documentation on how to Start Contributing

[Jeremy Stanley]

On 2015-09-01 15:45:22 -0700 (-0700), Vahid S Hashemian wrote:
[...]
> What is your advice on debugging a PyPi package? I'm modifying the code
> for python-muranoclient and would like to be able to debug using eclipse
> (in which I'm coding) or any other convenient means.

There are possibly better places than an OpenStack-specific mailing
list to ask general Python debugging questions. You can tell pip to
install from source in editable mode within a virtualenv and then
changes you make to the source code should be immediately testable
without needing to repackage/reinstall. Something like this
(assuming you have a recent version of virtualenv installed in your
current executable path):

git clone git://git.openstack.org/openstack/python-muranoclient.git
cd python-muranoclient
virtualenv .testing
. .testing/bin/activate
pip install -e .

>From that point on, running the murano CLI command or importing in
another script should get whatever changes you've made in your local
clone of the repository.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [heat] [gate] gate-heat-dsvm-functional-orig-mysql fails 100%

[Jeremy Stanley]

On 2015-09-02 14:26:13 +0100 (+0100), Steven Hardy wrote:
> I think this is the change we need to land to fix it:
> 
> https://review.openstack.org/#/c/219533/
> 
> Can it be bumped to the head of the queue?

It's there now with an ETA of ~25 minutes (barring any unforeseen
job failures).
-- 
Jeremy Stanley

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

Re: [openstack-dev] [horizon] URL Sanity

[Rob Cresswell (rcresswe)]

Yeah, the “legacy” thought is what’s making me second guess the effort. We’re 
still in limbo with the language focus, IMO.

Are we nearing a change in routing? I remember work being demo’d at the last 
summit, but I haven’t seen any of it since.

From: Richard Jones >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, 2 September 2015 00:32
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [horizon] URL Sanity

Interesting idea, and in general I'm for consistency. I can't speak directly to 
the network/port question, though it seems to me that if ports must be attached 
to networks then it makes sense for the URL to reflect that.

On the other hand, some could argue that the django URL routing is ... legacy 
... and shouldn't me messed with :)

On the gripping hand, thinking about this could inform future angular routing 
planning...

On 2 September 2015 at 00:39, Rob Cresswell (rcresswe) 
> wrote:
Hi all,

I recently started looking into properly implementing breadcrumbs to make 
navigation clearer, especially around nested resources (Subnets Detail page, 
for example). The idea is to use the request.path to form a logical breadcrumb 
that isn’t dependent on browser history ( 
https://review.openstack.org/#/c/129985/3/horizon/browsers/breadcrumb.py ). 
Unfortunately, this breaks down quite quickly because we use odd patterns like 
`//detail`, and `/` doesn’t 
exist.

This made me realise how much of an inconsistent mess the URL patterns are.  
I’ve started cleaning them up, so we move from these patterns:

`/admin/networks//detail` - Detail page for a Network
`/admin/networks//addsubnet` - Create page for a Subnet

To patterns in line with usual CRUD usages, such as:

`/admin/networks/` - Detail page for a Network
`/admin/networks//subnets/create` - Create page for a Subnet

This is mostly trivial, just removing extraneous words and adding consistency, 
with end goal being every panel following patterns like:

`/` - Index page
`//` - Detail page for a single resource
`//create` - Create new resource
`///update` - Update a resource

This gets a little complex around nested items. Should a Port for example, 
which has a unique ID, be reachable in Horizon by just its ID? Ports must 
always be attached to a network as I understand it. There are multiple ways to 
express this:

`/networks/ports/` - Current implementation
`/networks//ports/` - My preferred structure
`/ports/` - Another option

Does anyone have any opinions on how to handle this structuring, or if it’s 
even necessary?

Regards,
Rob

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


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

Re: [openstack-dev] [cinder] L3 low pri review queue starvation

[Tom Barron]

On 9/2/15 5:19 AM, Gorka Eguileor wrote:
> On Tue, Sep 01, 2015 at 09:30:26AM -0600, John Griffith wrote:
>> On Tue, Sep 1, 2015 at 5:57 AM, Tom Barron  wrote:
>>
>>> [Yesterday while discussing the following issue on IRC, jgriffith
>>> suggested that I post to the dev list in preparation for a discussion in
>>> Wednesday's cinder meeting.]
>>>
>>> Please take a look at the 10 "Low" priority reviews in the cinder
>>> Liberty 3 etherpad that were punted to Mitaka yesterday. [1]
>>>
>>> Six of these *never* [2] received a vote from a core reviewer. With the
>>> exception of the first in the list, which has 35 patch sets, none of the
>>> others received a vote before Friday, August 28.  Of these, none had
>>> more than -1s on minor issues, and these have been remedied.
>>>
>>> Review https://review.openstack.org/#/c/213855 "Implement
>>> manage/unmanage snapshot in Pure drivers" is a great example:
>>>
>>>* approved blueprint for a valuable feature
>>>* pristine code
>>>* passes CI and Jenkins (and by the deadline)
>>>* never reviewed
>>>
>>> We have 11 core reviewers, all of whom were very busy doing reviews
>>> during L3, but evidently this set of reviews didn't really have much
>>> chance of making it.  This looks like a classic case where the
>>> individually rational priority decisions of each core reviewer
>>> collectively resulted in starving the Low Priority review queue.
>>>
> 
> I can't speak for other cores, but in my case reviewing was mostly not
> based on my own priorities, I reviewed patches based on the already set
> priority of each patch as well as patches that I was already
> reviewing.
> 
> Some of those medium priority patches took me a lot of time to review,
> since they were not trivial (some needed some serious rework).  As for
> patches I was already reviewing, as you can imagine it wouldn't be fair
> to just ignore a patch that I've been reviewing for some time just when
> it's almost ready and the deadline is closing in.
> 

That's why I said that this situation is an outcome of individually
rational decisions.  It should be clear that none of this is intended as
a complaint about reviewers or reviewer's performance.

> Having said that I have to agree that those patches didn't have much
> chances, and I apologize for my part on that.  While it is no excuse I
> have to agree with jgriffith when he says that those patches should have
> pushed cores for reviews (even if this is clearly not the "right" way to
> manage it).

No apology required!

> 
>>> One way to remedy would be for the 11 core reviewers to devote a day or
>>> two to cleaning up this backlog of 10 outstanding reviews rather than
>>> punting all of them out to Mitaka.
>>>
>>> Thanks for your time and consideration.
>>>
>>> Respectfully,
>>>
>>> -- Tom Barron
>>>
>>> [1] https://etherpad.openstack.org/p/cinder-liberty-3-reviews
>>> [2] At the risk of stating the obvious, in this count I ignore purely
>>> procedural votes such as the final -2.
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> ​Thanks Tom, this is sadly an ongoing problem every release.  I think we
>> have a number of things we can talk about at the summit to try and
>> make some of this better.  I honestly think that if people were to
>> actually "use" launchpad instead of creating tracking etherpads
>> everywhere it would help.  What I mean is that there is a ranked
>> targeting of items in Launchpad and we should use it, core team
>> members should know that as the source of truth and things that must
>> get reviewed.
>>
> 
> I agree, we should use Launchpad's functionality to track BPs and Bugs
> targeted for each milestone, and maybe we can discuss on a workflow that
> helps us reduce starvation at the same time that helps us keep track of
> code reviewers responsible for each item.
> 
> Just spitballing here, but we could add to BP's work items and Bug's
> comments what core members will be responsible for reviewing related
> patches.  Although this means cores will have to check this on every
> review they do that has a BP or Bug number, so if there are already 2
> cores responsible for that feature they should preferably just move on
> to other patches and if there are not 2 core reviewers they should add
> themselves to LP.  This way patch owners know who they should bug for
> reviews on their patches and if there are no core reviewers for them
> they should look for some (or wait for them to "claim" that
> bug/feature).
> 
>> As far as Liberty and your patches; Yesterday was the freeze point, the
>> entire Cinder team agreed on that (yourself included both at the mid-cycle
>> meet up and at the team meeting two weeks ago when Thingee reiterated the
>> 

Re: [openstack-dev] [cinder] L3 low pri review queue starvation

[hao wang]

2015-09-02 17:19 GMT+08:00 Gorka Eguileor :
> On Tue, Sep 01, 2015 at 09:30:26AM -0600, John Griffith wrote:
>> On Tue, Sep 1, 2015 at 5:57 AM, Tom Barron  wrote:
>>
>> > [Yesterday while discussing the following issue on IRC, jgriffith
>> > suggested that I post to the dev list in preparation for a discussion in
>> > Wednesday's cinder meeting.]
>> >
>> > Please take a look at the 10 "Low" priority reviews in the cinder
>> > Liberty 3 etherpad that were punted to Mitaka yesterday. [1]
>> >
>> > Six of these *never* [2] received a vote from a core reviewer. With the
>> > exception of the first in the list, which has 35 patch sets, none of the
>> > others received a vote before Friday, August 28.  Of these, none had
>> > more than -1s on minor issues, and these have been remedied.
>> >
>> > Review https://review.openstack.org/#/c/213855 "Implement
>> > manage/unmanage snapshot in Pure drivers" is a great example:
>> >
>> >* approved blueprint for a valuable feature
>> >* pristine code
>> >* passes CI and Jenkins (and by the deadline)
>> >* never reviewed
>> >
>> > We have 11 core reviewers, all of whom were very busy doing reviews
>> > during L3, but evidently this set of reviews didn't really have much
>> > chance of making it.  This looks like a classic case where the
>> > individually rational priority decisions of each core reviewer
>> > collectively resulted in starving the Low Priority review queue.
>> >
>
> I can't speak for other cores, but in my case reviewing was mostly not
> based on my own priorities, I reviewed patches based on the already set
> priority of each patch as well as patches that I was already
> reviewing.
>
> Some of those medium priority patches took me a lot of time to review,
> since they were not trivial (some needed some serious rework).  As for
> patches I was already reviewing, as you can imagine it wouldn't be fair
> to just ignore a patch that I've been reviewing for some time just when
> it's almost ready and the deadline is closing in.
>
> Having said that I have to agree that those patches didn't have much
> chances, and I apologize for my part on that.  While it is no excuse I
> have to agree with jgriffith when he says that those patches should have
> pushed cores for reviews (even if this is clearly not the "right" way to
> manage it).
>
>> > One way to remedy would be for the 11 core reviewers to devote a day or
>> > two to cleaning up this backlog of 10 outstanding reviews rather than
>> > punting all of them out to Mitaka.
>> >
>> > Thanks for your time and consideration.
>> >
>> > Respectfully,
>> >
>> > -- Tom Barron
>> >
>> > [1] https://etherpad.openstack.org/p/cinder-liberty-3-reviews
>> > [2] At the risk of stating the obvious, in this count I ignore purely
>> > procedural votes such as the final -2.
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> Thanks Tom, this is sadly an ongoing problem every release.  I think we
>> have a number of things we can talk about at the summit to try and
>> make some of this better.  I honestly think that if people were to
>> actually "use" launchpad instead of creating tracking etherpads
>> everywhere it would help.  What I mean is that there is a ranked
>> targeting of items in Launchpad and we should use it, core team
>> members should know that as the source of truth and things that must
>> get reviewed.
>>
>
> I agree, we should use Launchpad's functionality to track BPs and Bugs
> targeted for each milestone, and maybe we can discuss on a workflow that
> helps us reduce starvation at the same time that helps us keep track of
> code reviewers responsible for each item.
>
> Just spitballing here, but we could add to BP's work items and Bug's
> comments what core members will be responsible for reviewing related
> patches.  Although this means cores will have to check this on every
> review they do that has a BP or Bug number, so if there are already 2
> cores responsible for that feature they should preferably just move on
> to other patches and if there are not 2 core reviewers they should add
> themselves to LP.  This way patch owners know who they should bug for
> reviews on their patches and if there are no core reviewers for them
> they should look for some (or wait for them to "claim" that
> bug/feature).

Like Gorka's idea here. This cloud be a better way to relieve this issue.
I hope patch owners could require cores' help via IRC or something else if there
are no core reviewers.
>
>> As far as Liberty and your patches; Yesterday was the freeze point, the
>> entire Cinder team agreed on that (yourself included both at the mid-cycle
>> meet up and at the team meeting two weeks ago when Thingee 

Re: [openstack-dev] [cinder] L3 low pri review queue starvation

[Gorka Eguileor]

On Tue, Sep 01, 2015 at 09:30:26AM -0600, John Griffith wrote:
> On Tue, Sep 1, 2015 at 5:57 AM, Tom Barron  wrote:
> 
> > [Yesterday while discussing the following issue on IRC, jgriffith
> > suggested that I post to the dev list in preparation for a discussion in
> > Wednesday's cinder meeting.]
> >
> > Please take a look at the 10 "Low" priority reviews in the cinder
> > Liberty 3 etherpad that were punted to Mitaka yesterday. [1]
> >
> > Six of these *never* [2] received a vote from a core reviewer. With the
> > exception of the first in the list, which has 35 patch sets, none of the
> > others received a vote before Friday, August 28.  Of these, none had
> > more than -1s on minor issues, and these have been remedied.
> >
> > Review https://review.openstack.org/#/c/213855 "Implement
> > manage/unmanage snapshot in Pure drivers" is a great example:
> >
> >* approved blueprint for a valuable feature
> >* pristine code
> >* passes CI and Jenkins (and by the deadline)
> >* never reviewed
> >
> > We have 11 core reviewers, all of whom were very busy doing reviews
> > during L3, but evidently this set of reviews didn't really have much
> > chance of making it.  This looks like a classic case where the
> > individually rational priority decisions of each core reviewer
> > collectively resulted in starving the Low Priority review queue.
> >

I can't speak for other cores, but in my case reviewing was mostly not
based on my own priorities, I reviewed patches based on the already set
priority of each patch as well as patches that I was already
reviewing.

Some of those medium priority patches took me a lot of time to review,
since they were not trivial (some needed some serious rework).  As for
patches I was already reviewing, as you can imagine it wouldn't be fair
to just ignore a patch that I've been reviewing for some time just when
it's almost ready and the deadline is closing in.

Having said that I have to agree that those patches didn't have much
chances, and I apologize for my part on that.  While it is no excuse I
have to agree with jgriffith when he says that those patches should have
pushed cores for reviews (even if this is clearly not the "right" way to
manage it).

> > One way to remedy would be for the 11 core reviewers to devote a day or
> > two to cleaning up this backlog of 10 outstanding reviews rather than
> > punting all of them out to Mitaka.
> >
> > Thanks for your time and consideration.
> >
> > Respectfully,
> >
> > -- Tom Barron
> >
> > [1] https://etherpad.openstack.org/p/cinder-liberty-3-reviews
> > [2] At the risk of stating the obvious, in this count I ignore purely
> > procedural votes such as the final -2.
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> ​Thanks Tom, this is sadly an ongoing problem every release.  I think we
> have a number of things we can talk about at the summit to try and
> make some of this better.  I honestly think that if people were to
> actually "use" launchpad instead of creating tracking etherpads
> everywhere it would help.  What I mean is that there is a ranked
> targeting of items in Launchpad and we should use it, core team
> members should know that as the source of truth and things that must
> get reviewed.
> 

I agree, we should use Launchpad's functionality to track BPs and Bugs
targeted for each milestone, and maybe we can discuss on a workflow that
helps us reduce starvation at the same time that helps us keep track of
code reviewers responsible for each item.

Just spitballing here, but we could add to BP's work items and Bug's
comments what core members will be responsible for reviewing related
patches.  Although this means cores will have to check this on every
review they do that has a BP or Bug number, so if there are already 2
cores responsible for that feature they should preferably just move on
to other patches and if there are not 2 core reviewers they should add
themselves to LP.  This way patch owners know who they should bug for
reviews on their patches and if there are no core reviewers for them
they should look for some (or wait for them to "claim" that
bug/feature).

> As far as Liberty and your patches; Yesterday was the freeze point, the
> entire Cinder team agreed on that (yourself included both at the mid-cycle
> meet up and at the team meeting two weeks ago when Thingee reiterated the
> deadlines).  If you noticed last week that your patches weren't going
> anywhere YOU should've wrangled up some reviews.
> 
> Furthermore, I've explained every release for the last 3 or 4 years that
> there's no silver bullet, no magic process when it come to review
> throughput.  ESPECIALLY when it comes to the 3'rd milestone.  You can try
> landing 

Re: [openstack-dev] [trove] Anyone using containers?

[Thierry Carrez]

Lowery, Mathew wrote:
> Just curious if anyone is using containers in their deployments. If so,
> in what capacity? What are the advantages, gotchas, and pain points?

This might trigger more responses on the openstack-operators mailing-list.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all] Criteria for applying vulnerability:managed tag

[Thierry Carrez]

Some out-of-context quotes and comments below:

Jeremy Stanley wrote:
> [...]
> 1. Since the vulnerability:managed governance tag applies to
> deliverables, all repos within a given deliverable must meet the
> qualifying criteria. This means that if some repos in a deliverable
> are in good enough shape to qualify, their vulnerability management
> could be held back by other repos in the same deliverable. It might
> be argued that perhaps this makes them separate deliverables (in
> which case the governance projects.yaml should get an update to
> reflect that), or maybe that we really have a use case for per-repo
> tags and that the TC needs to consider deliverable and repo tags as
> separate ideas.

If repositories forming a single deliverable have varying degrees of
maturity or support and that cannot be fixed quickly, then yes I would
argue that they do not form a coherent whole and need to be split into a
separate deliverable.

The idea behind applying tags to deliverables is to facilitate splitting
a given user-consumable product (deliverable) across multiple git
repositories. They should still make a coherent whole and have common
characteristics, otherwise they are not a single user-consumable
product, they are a bunch of repositories with various levels of quality
and support, thrown together for dubious reasons.

So if for example we can't apply the same tags to openstack/neutron and
openstack/neutron-*aas, then the *aas should probably form a separate
deliverable (called for example "neutron advanced services").

> [...]
> 5. The deliverable's repos should undergo a third-party review/audit
> looking for obvious signs of insecure design or risky implementation
> which could imply a large number of future vulnerability reports. As
> much as anything this is a measure to keep the VMT's workload down,
> since it is by necessity a group of constrained size and some of its
> processes simply can't be scaled safely. It's not been identified
> who would actually perform this review, though this is one place
> members of the OpenStack Security project-team might volunteer to
> provide their expertise and assistance.

About that one, one of the reasons we tried to have the projects audited
before inclusion was to avoid to issue a dozen OSSAs the first time a
project goes through a static code checker. So it is also about
proactively clearing the obvious stuff before it generates a spike in
VMT work.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Alex Schultz to Fuel-Library Core

[Jay Pipes]

I'm not a Fuel core or anything, but +1 from me. Alex has been very 
visible in the community and his work on librarian-puppet was a great 
step forward for the project.


Best,
-jay

On 09/02/2015 04:31 AM, Sergii Golovatiuk wrote:

Hi,

I would like to nominate Alex Schultz to Fuel-Library Core team. He’s
been doing a great job in writing patches. At the same time his reviews
are solid with comments for further improvements. He’s #3 reviewer and
#1 contributor with 46 commits for last 90 days [1]. Additionally, Alex
has been very active in IRC providing great ideas. His ‘librarian’
blueprint [3] made a big step towards to puppet community.

Fuel Library, please vote with +1/-1 for approval/objection. Voting will
be open until September 9th. This will go forward after voting is closed
if there are no objections.

Overall contribution:
[0] http://stackalytics.com/?user_id=alex-schultz
Fuel library contribution for last 90 days:
[1] http://stackalytics.com/report/contribution/fuel-library/90
List of reviews:
[2]
https://review.openstack.org/#/q/reviewer:%22Alex+Schultz%22+status:merged,n,z
‘Librarian activities’ in mailing list:
[3] http://lists.openstack.org/pipermail/openstack-dev/2015-July/071058.html

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser


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



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

[openstack-dev] [Fuel] Nominate Evgeniy Konstantinov for fuel-docs core

[Irina Povolotskaya]

Fuelers,

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

http://stackalytics.com/?user_id=evkonstantinov=all_type=all=fuel-docs

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

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

-- 
Best regards,

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

Re: [openstack-dev] [Fuel] Code review process in Fuel and related issues

[Jay Pipes]

On 09/02/2015 03:00 AM, Igor Kalnitsky wrote:

It won't work that way. You either busy on writing code / leading
feature or doing review. It couldn't be combined effectively. Any
context switch between activities requires an extra time to focus on.


I don't agree with the above, Igor. I think there's plenty of examples 
of people in OpenStack projects that both submit code (and lead 
features) that also do code review on a daily basis.


Best,
-jay

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

Re: [openstack-dev] [Fuel] Code review process in Fuel and related issues

[Igor Kalnitsky]

> I think there's plenty of examples of people in OpenStack projects
> that both submit code (and lead features) that also do code review
> on a daily basis.

* Do these features huge?
* Is their code contribution huge or just small patches?
* Did they get to master before FF?
* How many intersecting features OpenStack projects have under
development? (since often merge conflicts requires a lot of re-review)
* How often OpenStack people are busy on other activities, such as
helping fellas, troubleshooting customers, participate design meetings
and so on?

If so, do you sure they are humans then? :) I can only speak for
myself, and that's what I want to say: during 7.0 dev cycle I burned
in hell and I don't want to continue that way.

Thanks,
Igor

On Wed, Sep 2, 2015 at 3:14 PM, Jay Pipes  wrote:
> On 09/02/2015 03:00 AM, Igor Kalnitsky wrote:
>>
>> It won't work that way. You either busy on writing code / leading
>> feature or doing review. It couldn't be combined effectively. Any
>> context switch between activities requires an extra time to focus on.
>
>
> I don't agree with the above, Igor. I think there's plenty of examples of
> people in OpenStack projects that both submit code (and lead features) that
> also do code review on a daily basis.
>
> Best,
> -jay
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Fuel] Nominate Evgeniy Konstantinov for fuel-docs core

[Dmitry Borodaenko]

+1, Evgeny has been a #1 committer in fuel-docs for a while, it's great to
see him pick up on the reviews, too.

On Wed, Sep 2, 2015 at 3:24 PM Irina Povolotskaya <
ipovolotsk...@mirantis.com> wrote:

> Fuelers,
>
> I'd like to nominate Evgeniy Konstantinov for the fuel-docs-core team.
> He has contributed thousands of lines of documentation to Fuel over
> the past several months, and has been a diligent reviewer:
>
>
> http://stackalytics.com/?user_id=evkonstantinov=all_type=all=fuel-docs
>
> I believe it's time to grant him core reviewer rights in the fuel-docs
> repository.
>
> Core reviewer approval process definition:
> https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>
> --
> Best regards,
>
> Irina
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] [gate] gate-heat-dsvm-functional-orig-mysql fails 100%

[Sean Dague]

Today's gate firedrill #2 is the fact that in the last 12 hours heat's
functional tests went to 100% failure - http://goo.gl/YeVrD0

There are current 14 heat changes in the gate, each will add 30 - 40
minutes of delay as they fail and reset things behind them. So 7 - 10
hours of gate delay for everyone because of these patches.

Could heat team members get engaged and get to the bottom of this one?

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [glance] image-create --is-public removed?

[Neil Jerram]

Was the --is-public option to 'glance image-create ...' just removed?  I've 
been running Devstack successfully during the last week, but now see this:

glance: error: unrecognized arguments: --is-public=true

from running this:

wget http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-disk.img -O - | 
glance image-create --name=cirros-0.3.2-x86_64 --disk-format=qcow2 \
  --container-format=bare --is-public=true

So, some questions:

- Is it correct that this option has just been removed?
- Where should I be looking / tracking to see announcements of changes like 
this?
- Out of interest, where is the code that implements these command line 
operations?

Thanks,
Neil

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

Re: [openstack-dev] [glance] image-create --is-public removed?

[Nikhil Komawar]

You should check the version of your glanceclient.

`glance help` will give you help on most commands. Seems like you may
have upgraded your client and now it defaults to v2 of the server API.

You can track updates using the release on pypi and related
documentation on [1]; announcements are on the openstack-announce ML.

[1] http://docs.openstack.org/developer/python-glanceclient/

On 9/2/15 10:42 AM, Neil Jerram wrote:
> Was the --is-public option to 'glance image-create ...' just removed? 
> I've been running Devstack successfully during the last week, but now
> see this:
>
> glance: error: unrecognized arguments: --is-public=true
>
> from running this:
>
> wget
> http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-disk.img -O
> - | glance image-create --name=cirros-0.3.2-x86_64 --disk-format=qcow2 \
>   --container-format=bare --is-public=true
>
> So, some questions:
>
> - Is it correct that this option has just been removed?
> - Where should I be looking / tracking to see announcements of changes
> like this?
> - Out of interest, where is the code that implements these command
> line operations?
>
> Thanks,
> Neil
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil


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

Re: [openstack-dev] [mistral][yaql] Addressing task result using YAQL function

[Dmitri Zimine]

Agree, 

with one detail: make it explicit -  task(task_name). 

res - we often see folks confused by result of what (action, task, workflow) 
although we cleaned up our lingo: action-output, task-result, workflow-output…. 
but still worth being explicit.

And full result is being thought as the root context $.

Publishing to global context may be ok for now, IMO.

DZ>

On Sep 2, 2015, at 4:16 AM, Renat Akhmerov  wrote:

> Hi,
> 
> I’d like to propose a few changes after transition to yaql 1.0:
> 
> We already moved from using “$.__execution” in DSL to "execution()” and from 
> “$.__env” to “env()” where “execution()” and “env()" are registered yaql 
> functions. We had to do it because double underscored are prohibited in the 
> new yaql.
> 
> 
> In the spirit of these changes I’m proposing a similar change for addressing 
> task result in Mistral DSL.
> 
> Currently we have the syntax “$.task_name” that we can use in yaql 
> expressions to refer to corresponding task result. The current implementation 
> is of that is kind of tricky and, IMO, conceptually wrong because referencing 
> this kind of key leads to DB read operation that’s requried to fetch task 
> result (it may be big as megabytes so it can’t be stored in workflow context 
> all the time. In other words, we create a dictionary with side effect and 
> change the initial semantics of dictionary. Along with mentioned trickiness 
> of this approach it’s not convenient, for example, to debug the code because 
> we can accidentally cause a DB operation. 
> 
> So the solution I’m proposing is to have an explicit yaql function called 
> “res” or “result” to extract task result.
> 
> res() - extracts the result of the current task, i.e. in “publish” clause.
> res(‘task_name’) - extracts the result of the task with the specified name. 
> Can also be used in “publish” clause, if needed
> 
> This approach seems more flexible (cause we can add any other functions w/o 
> having to make significant changes in WF engine) and expressive because user 
> won’t confuse $.task_name with addressing a regular workflow context variable.
> 
> Of course, this to some extent breaks backwards compatibility. But we already 
> changed yaql version which was necessary anyway so it seems like a good time 
> to do it.
> 
> I’d very much like to have your input on this.
> 
> Renat Akhmerov
> @ Mirantis Inc.
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [cinder] L3 low pri review queue starvation

[Doug Hellmann]

Excerpts from Gorka Eguileor's message of 2015-09-02 11:19:02 +0200:
> On Tue, Sep 01, 2015 at 09:30:26AM -0600, John Griffith wrote:
> > On Tue, Sep 1, 2015 at 5:57 AM, Tom Barron  wrote:
> > 
> > > [Yesterday while discussing the following issue on IRC, jgriffith
> > > suggested that I post to the dev list in preparation for a discussion in
> > > Wednesday's cinder meeting.]
> > >
> > > Please take a look at the 10 "Low" priority reviews in the cinder
> > > Liberty 3 etherpad that were punted to Mitaka yesterday. [1]
> > >
> > > Six of these *never* [2] received a vote from a core reviewer. With the
> > > exception of the first in the list, which has 35 patch sets, none of the
> > > others received a vote before Friday, August 28.  Of these, none had
> > > more than -1s on minor issues, and these have been remedied.
> > >
> > > Review https://review.openstack.org/#/c/213855 "Implement
> > > manage/unmanage snapshot in Pure drivers" is a great example:
> > >
> > >* approved blueprint for a valuable feature
> > >* pristine code
> > >* passes CI and Jenkins (and by the deadline)
> > >* never reviewed
> > >
> > > We have 11 core reviewers, all of whom were very busy doing reviews
> > > during L3, but evidently this set of reviews didn't really have much
> > > chance of making it.  This looks like a classic case where the
> > > individually rational priority decisions of each core reviewer
> > > collectively resulted in starving the Low Priority review queue.
> > >
> 
> I can't speak for other cores, but in my case reviewing was mostly not
> based on my own priorities, I reviewed patches based on the already set
> priority of each patch as well as patches that I was already
> reviewing.
> 
> Some of those medium priority patches took me a lot of time to review,
> since they were not trivial (some needed some serious rework).  As for
> patches I was already reviewing, as you can imagine it wouldn't be fair
> to just ignore a patch that I've been reviewing for some time just when
> it's almost ready and the deadline is closing in.
> 
> Having said that I have to agree that those patches didn't have much
> chances, and I apologize for my part on that.  While it is no excuse I
> have to agree with jgriffith when he says that those patches should have
> pushed cores for reviews (even if this is clearly not the "right" way to
> manage it).
> 
> > > One way to remedy would be for the 11 core reviewers to devote a day or
> > > two to cleaning up this backlog of 10 outstanding reviews rather than
> > > punting all of them out to Mitaka.
> > >
> > > Thanks for your time and consideration.
> > >
> > > Respectfully,
> > >
> > > -- Tom Barron
> > >
> > > [1] https://etherpad.openstack.org/p/cinder-liberty-3-reviews
> > > [2] At the risk of stating the obvious, in this count I ignore purely
> > > procedural votes such as the final -2.
> > >
> > > __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > 
> > ​Thanks Tom, this is sadly an ongoing problem every release.  I think we
> > have a number of things we can talk about at the summit to try and
> > make some of this better.  I honestly think that if people were to
> > actually "use" launchpad instead of creating tracking etherpads
> > everywhere it would help.  What I mean is that there is a ranked
> > targeting of items in Launchpad and we should use it, core team
> > members should know that as the source of truth and things that must
> > get reviewed.
> > 
> 
> I agree, we should use Launchpad's functionality to track BPs and Bugs
> targeted for each milestone, and maybe we can discuss on a workflow that
> helps us reduce starvation at the same time that helps us keep track of
> code reviewers responsible for each item.
> 
> Just spitballing here, but we could add to BP's work items and Bug's
> comments what core members will be responsible for reviewing related
> patches.  Although this means cores will have to check this on every
> review they do that has a BP or Bug number, so if there are already 2
> cores responsible for that feature they should preferably just move on
> to other patches and if there are not 2 core reviewers they should add
> themselves to LP.  This way patch owners know who they should bug for
> reviews on their patches and if there are no core reviewers for them
> they should look for some (or wait for them to "claim" that
> bug/feature).

I know some teams are using an etherpad to track that sort of
information, because priorities change from week to week (as items are
closed out) and it's easy to add arbitrary comments to the etherpad.
Maybe one of the teams doing that can comment on its effectiveness?

Doug

Re: [openstack-dev] [oslo.messaging]

[Georgy Okrokvertskhov]

I believe in oslo.messaging routing_key is a topic.
Here is an example for ceilometer:
https://github.com/openstack/ceilometer/blob/master/ceilometer/meter/notifications.py#L212

And here is an oslo code for rabbitMQ driver:
https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/_drivers/impl_rabbit.py#L926

Routing_key is set to topic.

Thanks
Gosha

On Tue, Sep 1, 2015 at 6:27 PM, Nader Lahouti 
wrote:

> Hi,
>
> I am considering to use oslo.messaging to read messages from a rabbit
> queue. The messages are put into the queue by an external process.
> In order to do that I need to specify routing_key in addition to other
> parameters (i.e. exchange and queue,... name) for accessing the queue.  I
> was looking at the oslo.messaging API and wasn't able to find anywhere to
> specify the routing key.
>
> Is it possible to set routing_key when using oslo.messaging? if so, can
> you please point me to the document.
>
>
> Regards,
> Nader.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Command structure for OSC plugin

[Doug Hellmann]

Excerpts from Tim Bell's message of 2015-09-02 05:15:35 +:
> That would be great to have plugins on the commands which are relevant to 
> multiple projects… avoiding exposing all of the underlying projects as 
> prefixes and getting more consistency would be very appreciated by the users.

That works in some cases, but in a lot of cases things that are
superficially similar have important differences in the inputs they
take. In those cases, it's better to be explicit about the differences
than to force the concepts together in a way that makes OSC present only
the least-common denominator interface.

Doug

> 
> Tim
> 
> From: Dean Troyer [mailto:dtro...@gmail.com]
> Sent: 01 September 2015 22:47
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin
> 
> [late catch-up]
> 
> On Mon, Aug 24, 2015 at 2:56 PM, Doug Hellmann 
> > wrote:
> Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:
> > On 24/08/15 18:19 +, Tim Bell wrote:
> > >
> > >From a user perspective, where bare metal and VMs are just different 
> > >flavors (with varying capabilities), can we not use the same commands 
> > >(server create/rebuild/...) ? Containers will create the same conceptual 
> > >problems.
> > >
> > >OSC can provide a converged interface but if we just replace '$ ironic 
> > >' by '$ openstack baremetal ', this seems to be a missed 
> > >opportunity to hide the complexity from the end user.
> > >
> > >Can we re-use the existing server structures ?
> 
> I've wondered about how users would see doing this, we've done it already 
> with the quota and limits commands (blurring the distinction between project 
> APIs).  At some level I am sure users really do not care about some of our 
> project distinctions.
> 
> > To my knowledge, overriding or enhancing existing commands like that
> > is not possible.
> 
> You would have to do it in tree, by making the existing commands
> smart enough to talk to both nova and ironic, first to find the
> server (which service knows about something with UUID XYZ?) and
> then to take the appropriate action on that server using the right
> client. So it could be done, but it might lose some of the nuance
> between the server types by munging them into the same command. I
> don't know what sorts of operations are different, but it would be
> worth doing the analysis to see.
> 
> I do have an experimental plugin that hooks the server create command to add 
> some options and change its behaviour so it is possible, but right now I 
> wouldn't call it supported at all.  That might be something that we could 
> consider doing though for things like this.
> 
> The current model for commands calling multiple project APIs is to put them 
> in openstackclient.common, so yes, in-tree.
> 
> Overall, though, to stay consistent with OSC you would map operations into 
> the current verbs as much as possible.  It is best to think in terms of how 
> the CLI user is thinking and what she wants to do, and not how the REST or 
> Python API is written.  In this case, 'baremetal' is a type of server, a set 
> of attributes of a server, etc.  As mentioned earlier, containers will also 
> have a similar paradigm to consider.
> 
> dt
> 

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