[openstack-dev] [stable] Stable* wiki updates

2016-03-10 Thread Alan Pevec
Hi stable-maints,

FYI I've updated https://wiki.openstack.org/wiki/StableBranch and
https://wiki.openstack.org/wiki/StableBranchRelease now that all
policy and team information has ben included in the Project Team
Guide. Please review in case I missed something!

Cheers,
Alan

__
OpenStack Development Mailing 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][ml2][Manila] API to query segments used during port binding

2016-03-10 Thread Koderer, Marc
Hi folks,

I had a deep dive session with Bob (thx Bob).

We have a plan to solve the issue without any change of APIs or 
manila driver reworks.

The process will look like the following:

1.) In case of multi-segment/hpb Manila creates a port like Ironic ML2
would do it [1]:
  vif_type = baremetal
  binding_profile = list of sw ports
  device_owner = manila:ID

2.) Manila waits until all ports are actively bound
2.a) Neutron binds the port through the segments
2.b) A manila-neutron mech driver (a really simple one) fulfils the binding
   and sets:
 vif_details = {“share_segmentation_id" = XX,
   “share_network_type" = YY}

3.) When the port becomes active Manila has all it needs to proceed

In 2.b. the manila MD will only search for device_owner == “manila:”,
sets the needed details and fulfils the binding (~10 LOC).

We also discussed about using ML2 GW [2] or trunk port [3].
I consider the design above as simple enough to get merged smoothly
in Newton.

@Ben: Will be back for bug hunting now.

Regards
Marc

[1]: 
https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html
 

[2]: https://wiki.openstack.org/wiki/Neutron/L2-GW
[3]: https://wiki.openstack.org/wiki/Neutron/TrunkPort


> On 09 Mar 2016, at 09:25, Koderer, Marc  wrote:
> 
>> 
>> On 09 Mar 2016, at 08:43, Sukhdev Kapur > > wrote:
>> 
>> Hi Marc, 
>> 
>> I am driving the ironic-ml2 integration and introduced baremetal type for 
>> vmic_type. 
> 
> Basically that’s my plan. So in my current implementation
> I use the baremetal vnic_type [1] and add a binding profile [2].
> 
>> You can very much use the same integration here - however, I am not 
>> completely clear about your use case. 
>> Do you want neutron/ML2 to plumb the network for Manila or do you want to 
>> find out what VLAN (segmentation id) is used on the segment which connects 
>> TOR to the storage device? 
> 
> Generally I want to find the best architecture for this feature :)
> Introducing a neutron-agent that does the plumbing will mean this agent needs
> to have a connection to the storage node itself. So we will end-up in a
> storage agent with a driver model (or an agent for each storage device). On
> the other side it follows the idea that neutron takes care about networking.
> 
> From a Manila perspective the easiest solution would be to have an interface 
> to
> get the segmentation id of the lowest bound segment.
> 
>> 
>> You had this on the agenda of ML2 meeting for tomorrow and I was going to 
>> discuss this with you in the meeting. But, I noticed that you removed it 
>> from the agenda. Do you have what you need? If not, you may want to join us 
>> in the ML2 meeting tomorrow and we can discuss this use case there. 
> 
> Yeah I am sorry - I have to move the topic +1 week due to an internal meeting 
> :(
> But we can have a chat on IRC (mkoderer on freenode).
> 
> Regards
> Marc
> 
> [1]: https://review.openstack.org/#/c/283494/ 
> 
> [2]: https://review.openstack.org/#/c/284034/ 
> 
> 
> 
>> 
>> -Sukhdev
>> 
>> 
>> On Tue, Mar 1, 2016 at 1:08 AM, Koderer, Marc > > wrote:
>> 
>>> On 01 Mar 2016, at 06:22, Kevin Benton >> > wrote:
>>> 
>>> >This seems gross and backwards. It makes sense as a short term hack but 
>>> >given that we have time to design this correctly I'd prefer to get this 
>>> >information in a more straighforward way.
>>> 
>>> Well it depends on what is happening here. If Manilla is wiring up a 
>>> specific VLAN for a port, that makes it part of the port binding process, 
>>> in which case it should be an ML2 driver. Can you provide some more details 
>>> about what Manilla is doing with this info?
>> 
>> The VLAN segment ID and IP address is used in the share driver to configure 
>> the
>> corresponding interface resources within the storage. Just to give some
>> examples:
>> 
>>  - NetApp driver uses it to create a logical interface and assign it to a
>>“storage virtual machine” [1]
>>  - EMC driver does it in similar manner [2]
>> 
>> My idea was to use the same principle as ironic ml2 intregration is doing [3]
>> by setting the vnic_type to “baremetal”.
>> 
>> In Manila's current implementation storage drivers are also responsible to
>> setup the right networking setup. Would you suggest to move this part into 
>> the
>> port binding phase?
>> 
>> Regards
>> Marc
>> 
>> 
>> [1]: 
>> https://github.com/openstack/manila/blob/master/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L272
>>  
>> 

Re: [openstack-dev] [OpenStack-Dev][All][Manila] Api development question - nested urls - which approach is better?

2016-03-10 Thread Valeriy Ponomaryov
*"Option3":*

· Create access-group-entry -- POST '/access_groups/%s/entries'

· Show access-group-entry  -- GET  '/access_groups/entries/%s'

· List access-group-entries  -- GET '/access_groups/entries'

· List access-group-entries with filter by access group ID  -- GET
'/access_groups/entries?access_group_id='

And above is still sub-url.

On Fri, Mar 11, 2016 at 7:24 AM,  wrote:

> Hi All,
>
>
>
> *This is a general doubt related to taking a decision on REST API url
> construction.*
>
>
>
> In case of “nested urls”, lets say I have a relationship between
>
> two entities as below:
>
> *access_group is parent can have many access_group_entries.*
>
>
>
> Now for accessing access_group I have already created
>
>
>
> · Create access group - POST /access_groups
>
> · Show access_group – GET /access_groups/
>
> · List access_group – GET /access_groups/
>
> · Delete access_group – PUT /access_groups/
>
>
>
> That’s fine till here.
>
>
>
> Now when I work on child entity that is access_group_entry, I
>
> face a problem.
>
>
>
>
>
> Here, i have two options for url construction for access_group_entries.
>
>
>
> *Option1 :-*
>
> Considering that access_group_entry is related to access_group, it
>
> should be designed as a suburl, I go as below:
>
>
>
> · Create access-group-entry -- POST '/access_groups/%s/entries'
>  i send “access_group_id” in which entry is to be created, as part of
> url, okay. no issue. it works.
>
> · Show access-group-entry  -- GET  '/access_groups/%s/entries/%s'
>  need two variables from user, access_group_id and
> access_group_entry_id -
>
> *But I do not have access_group_id!!*
>
> as when, i say show access_group_entry  -
> i have just uuid of access_group_entry_directly.
>
> That's a problem. is it ? what to do in such case?
>
>
>
> · List access-group-entry  -- GET '/access_groups/%s/entries'>>>
> Here also its not *mandatory* that user will always give access_group_id.
>
> He might ask access_group_entry list for all access_groups in a go..
>
> hence same problem.
>
>
>
> *Option2 :-*
>
> *== *
>
> *Not creating a suburl, instead creating an independent url *
>
>
>
> RESOURCES_PATH = '/access_groups_entries'
>
> RESOURCE_PATH = '/access_groups_entries/%s'
>
>
>
> 1)Create POST '/access_groups_entries'  >> Passing access_group_id in
> body
>
> 2)Show   GET  '/access_groups_entries/%s'  directly
> access_group_entry_id here to be shown
>
>
>
> 3)List   GET '/access_groups/%s/entries' directly
> access_group_entry_id here to be shown.
>
> If access_group_id is given for filtering, will go as part of body.
>
>
>
> It solves above problem but it creates a new url for a resource
>
> which is child of a earlier created url.
>
> *Is that a problem?*
>
>
>
> Kindly suggest
>
>
>
>
>
> Thanks.
>
> Nidhi
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* Nidhi Mittal Hada (Product Engineering Service)
> *Sent:* Wednesday, March 09, 2016 10:32 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* RE: [openstack-dev] [OpenStack-Dev][All] Api development
> question
>
>
>
> Thank you Valeriy.
>
>
>
>
>
> *From:* Valeriy Ponomaryov [mailto:vponomar...@mirantis.com
> ]
> *Sent:* Tuesday, March 08, 2016 7:05 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [OpenStack-Dev][All] Api development
> question
>
>
>
> "Not found" means API you request is not registered. AFAICS, you register 
> "access_groups",
> but request "access-groups". Diff in symbols "_" and "-".
>
>
>
> On Tue, Mar 8, 2016 at 1:34 PM,  wrote:
>
>
>
>
>
> Hi all,
>
>
>
> I am working on a feature for share access in manila.
>
> For that lets say for creating the entity, I created client and server
>
> counterpart.
>
>
>
> I am stuck as my client request is not able to reach server resource
>
> I have created for it. This is client server log
>
> http://paste.openstack.org/show/489642/
>
>
>
>
>
> manila/api/v2/router.py
>
> This is my router entry
>
>
>
> from manila.api.v2 import access_groups
>
> .
>
> .
>
>
>
> self.resources["access_groups"] = access_groups.create_resource()
>
> mapper.resource("access_group", "access_groups",
>
> controller=self.resources["access_groups"],
>
> collection={"detail": "GET"},
>
> member={"defaults": "GET"})
>
>
>
>
>
> I don’t understand what mistake I have made that the request
>
> Is not getting mapped to correct resource.
>
>
>
> stack@controller:/opt/stack/manila/manila/api/v2$ ls access_groups.py
>
> access_groups.py
>
> stack@controller:/opt/stack/manila/manila/api/v2$
>
>
>
> This is access_groups.py snippet
>
> 

[openstack-dev] [Fuel] Trouble mapping the Remote PXE node

2016-03-10 Thread Akshik dbk
 Hi,

I'm using Fuel 7.0, trying to evaluate remote compute and node group


I've configured a remote PXE and I'm able to boot the node successfully onto 
the remote pxe, but while adding it to the environment and trying to configure 
interface I'm stuck with following error


fuel node --node-id 43 --network upload

DEPRECATION WARNING: /etc/fuel/client/config.yaml exists and will be used as 
the source for settings. This behavior is deprecated. Please specify the path 
to your custom settings file in the FUELCLIENT_CUSTOM_SETTINGS environment 
variable.

400 Client Error: Bad Request (Node '43': '53' network(s) are left unassigned)


the interface yams file is

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


pls. help
__
OpenStack Development Mailing 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] Compatibility of fuel plugins and fuel versions

2016-03-10 Thread Mike Scherbakov
Thank you for comments folks.
Clarifications, with the feedback incorporated:
1) We can install plugin developed against 8 to Fuel Mitaka (9). But it
won't appear in the UI as available plugin. This is what I want to fix, and
have just a warning that this plugin may not work.

2) To clarify, I'm talking about using plugin developed against 8.0-liberty
in 9.0-mitaka, e.g. in newer Fuel with newer OpenStack release deployed. I
understand that we've changed names of tasks, and now it's just impossible
to have any meaningful plugin developed against 8 which would work in
Mitaka without other task names, etc. But - do we expect renames over again
and again? Any other changes? I hope the answer is no, that we want to
stabilize an interface. I understand, that new OpenStack release may
require changes in tasks, new tasks would appear, new dependencies.
However, I assume that vast majority of components don't change that often.
So, do we have any suggestions how we can keep tasks and whatever else from
changes? Can we introduce backward compatibility here?
I'm trying to understand how hard it will be to make. As otherwise, every
plugin developer will have to learn new tasks every new release, and re-do
the work.

3) Multi-release support is kinda covered in (2) here. If plugin's code
needs little tweaks in order to support new release of Fuel, I'd suggest to
figure out how we can use inheritance and keep code for multiple Fuel
releases in one plugin repo. In current reality, when it means to fork
almost everything, I'm in a support of having a plugin branch per Fuel
release. Thanks for links to the corresponding thread and plugins v5 spec,
I'll take a careful look.

> So I don't quite understand how new"validated_against" parameter will
differ from existing "releases" list.
Alex, I meant to have different use of what we have now. Instead of
blocking a user from using a plugin in "unsupported" Fuel version, allow it
- but warn.

Thanks,


On Thu, Mar 10, 2016 at 4:50 AM Aleksandr Didenko 
wrote:

> > Good idea. That should be done despite on any decision we will take.
>
> Currently you have to specify which releases your plugin supports [0]. So
> I can take my plugin developed for 8.0 and install it on Fuel-9.0 (I
> actually did it and it worked just fine). But I won't be able to enable
> this plugin for "mitaka-9.0" release because plugin was not developed and
> tested for it, so it does not have "miraka-9.0" in "releases" list [0]. So
> I don't quite understand how new "validated_against" parameter will
> differ from existing "releases" list.
>
> Regards,
> Alex
>
> [0]
> https://github.com/openstack/fuel-plugin-external-lb/blob/68fc91a2d3360f19605180d7c3d8683227c8d5b1/metadata.yaml#L11-L21
>
>
> On Thu, Mar 10, 2016 at 10:22 AM, Bogdan Dobrelya 
> wrote:
>
>> On 10.03.2016 08:30, Mike Scherbakov wrote:
>> > Hi folks,
>> > in order to make a decision whether we need to support example plugins,
>> > and if actually need them [1], I'd suggest to discuss more common things
>> > about plugins.
>> >
>> > My thoughts:
>> > 1) This is not good, that our plugins created for Fuel 8 won't even
>> > install on Fuel 9. By default, we should assume that plugin will work at
>> > newer version of Fuel. However, for proper user experience, I suggest to
>> > create meta-field "validated_against", where plugin dev would provide
>> > versions of Fuel this plugin has been tested with. Let's say, it was
>> > tested against 7.0, 8.0. If user installs plugin in Fuel 9, I'd suggest
>> > to show a warning saying about risks and the fact that the plugin has
>> > not been tested against 9. We should not restrict intsallation against
>> > 9, though.
>>
>> Good idea. That should be done despite on any decision we will take.
>>
>> >
>> > 2) We need to keep backward compatibility of pluggable interface for a
>> > few releases. So that plugin developer can use pluggable interface of
>> > version x, which was supported in Fuel 6.1. If we still support it, it
>> > would mean (see next point) compatibility of this plugin with 6.1, 7.0,
>> > 8.0, 9.0. If we want to deprecate pluggable interface version, we should
>> > announce it, and basically follow standard process of deprecation.
>> >
>> > 3) Plugin's ability to work against multiple releases of Fuel
>> > (multi-release support). If if..else clauses to support multiple
>> > releases are fairly minimal, let's say take less that 10% of LOC, I'd
>> > suggest to have this supported. Just because it will be easier for
>> > plugin devs to support their plugin code (no code duplication, single
>> > repo for multiple releases).
>> >
>> > Thoughts?
>> >
>> > [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088211.html
>> > --
>> > Mike Scherbakov
>> > #mihgen
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> 

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-10 Thread Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
Hi Jay,

Thanks for your reply.

> Is this still an issue when you remove the resource group and create the 
> resource directly? The count of 1 might just be for testing purposes, but if 
> that's the end goal you should be able to drop the group entirely.

Unfortunately, the count of 1 is just for testing purpose and my end goal is 
that the count should be inputed as paramaters.

Regards,
Gary

-Original Message-
From: Jay Dobies [mailto:jason.dob...@redhat.com] 
Sent: Thursday, March 10, 2016 5:55 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template



On 3/9/16 4:39 PM, Zane Bitter wrote:
> On 09/03/16 05:42, Sergey Kraynev wrote:
>> Hi Gary,
>>
>>
>> First of all you don't need to use "depends_on", because using 
>> "get_attr" already create implicit dependency from rg_a.
>> About getting Null instead of real Ip address:
>> It sounds like a bug, but IMO, it's expected behavior, because I 
>> suppose it happens due to:
>>   - you create in rg_a some Server and probably it goes to active 
>> state before ip address becomes available for get_attr. It is 
>> necessary to check, but if it's try to add wait condition for this 
>> resource, then you will get created rg_a with fully available 
>> resources and I suppose IP will be available.
>
> I would have expected the IP address to be available before the server 
> becomes CREATE_COMPLETE. If it isn't then I'd consider that a bug too 
> - as you pointed out, people are relying on the dependency created by 
> get_attr to ensure that they can actually get the attribute.
>
> cheers,
> Zane.
>
>> On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) 
>>  wrote:
>>> Hi,
>>>
>>>
>>>
>>> I have 3 Heat templates using ResourceGroup. There are 2 resource 
>>> groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires 
>>> the IP address of rg_a as the paremeter of rg_b. I use 
>>> "rg_a_public_ip:
>>> {get_attr:
>>> [rg_a, rg_a_public_ip]}" to get the IP address of rg_a both in the 
>>> section of rg_b parameters (rg_b/properties/resource_def/properties) 
>>> and the section of outputs.
>>>
>>> As per my observation,  rg_a_public_ip shows "null" in the parameter 
>>> section of rg_b. while rg_a_public_ip shows the correct IP address 
>>> in the outputs section of the yaml file.
>>>
>>>
>>>
>>> My questions are:
>>>
>>> 1)  Does this behavior is expected as designed or this is a bug?
>>>
>>> 2)  What is the alternative solution for the above case(user want
>>> to get
>>> the run-time information of the instance when creating the second 
>>> resource
>>> group)  if this behavior is expected?
>>>
>>>
>>>
>>> --- a.yaml ---
>>>
>>> resources:
>>>
>>> rg_a:
>>>
>>>type: OS::Heat::ResourceGroup
>>>
>>>properties:
>>>
>>>count: 1

Is this still an issue when you remove the resource group and create the 
resource directly? The count of 1 might just be for testing purposes, but if 
that's the end goal you should be able to drop the group entirely.


>>>resource_def:
>>>
>>>type: b.yaml
>>>
>>>properties:
>>>
>>> ...
>>>
>>>
>>>
>>> rg_b:
>>>
>>> type: OS::Heat::ResourceGroup
>>>
>>> depends_on:
>>>
>>>  -rg_a
>>>
>>> properties:
>>>
>>>  count: 2
>>>
>>>  resource_def:
>>>
>>>  type: c.yaml
>>>
>>>  properties:
>>>
>>>  rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
>>>   the value is "null"
>>>
>>>  ...
>>>
>>>
>>>
>>> outputs:
>>>
>>> rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
>>> -  the value is correct.
>>>
>>> --
>>>
>>>
>>>
>>> --b.yaml  
>>>
>>> ...
>>>
>>> resources:
>>>
>>>  rg_a:
>>>
>>> type: OS::Nova::Server
>>>
>>> properties:
>>>
>>>   ...
>>>
>>> outputs:
>>>
>>>   rg_a_public_ip:
>>>
>>>   value: {get_attr: [rg_a, networks, public, 0]}
>>>
>>> --
>>>
>>>
>>>
>>> -- c.yaml 
>>>
>>> parameters:
>>>
>>> rg_a_public_ip:
>>>
>>>   type: string
>>>
>>>   description: IP of rg_a
>>>
>>> ...
>>>
>>> resources:
>>>
>>> rg_b:
>>>
>>>  type: OS::Nova::Server
>>>
>>>  properties:
>>>
>>>   ...
>>>
>>>  outputs:
>>>
>>>   ...
>>>
>>> ---
>>>
>>>
>>>
>>> Regards,
>>>
>>> Gary
>>>
>>>
>>>
>>>
>>> 
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> 

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-10 Thread Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
Hi Zane,

Thanks for your reply.
I guess you mean that IP address of rg_a should be available AS SOON AS/AFTER  
the server of rg_a becomes CREATE_COMPLETE? As Sergey pointed out, there is a 
chance that IP address might be available when the server of rg_a becomes 
CREATE_COMPLETE. Actually, IMHO, it depends on when a server becomes ACTIVE or 
CREATE_COMPLETE. It will becomes ACTIVE or CREATE_COMPLETE when the OS is boot 
up but initiation services(such as network interface starting up) has not been 
done or when both OS itself and initialization jobs such as daemon service up 
and network interface up, IP assigned.

Regards,
Gary

-Original Message-
From: Zane Bitter [mailto:zbit...@redhat.com] 
Sent: Thursday, March 10, 2016 5:40 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

On 09/03/16 05:42, Sergey Kraynev wrote:
> Hi Gary,
>
>
> First of all you don't need to use "depends_on", because using 
> "get_attr" already create implicit dependency from rg_a.
> About getting Null instead of real Ip address:
> It sounds like a bug, but IMO, it's expected behavior, because I 
> suppose it happens due to:
>   - you create in rg_a some Server and probably it goes to active 
> state before ip address becomes available for get_attr. It is 
> necessary to check, but if it's try to add wait condition for this 
> resource, then you will get created rg_a with fully available 
> resources and I suppose IP will be available.

I would have expected the IP address to be available before the server becomes 
CREATE_COMPLETE. If it isn't then I'd consider that a bug too - as you pointed 
out, people are relying on the dependency created by get_attr to ensure that 
they can actually get the attribute.

cheers,
Zane.

> On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) 
>  wrote:
>> Hi,
>>
>>
>>
>> I have 3 Heat templates using ResourceGroup. There are 2 resource 
>> groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires 
>> the IP address of rg_a as the paremeter of rg_b. I use "rg_a_public_ip: 
>> {get_attr:
>> [rg_a, rg_a_public_ip]}" to get the IP address of rg_a both in the 
>> section of rg_b parameters (rg_b/properties/resource_def/properties) 
>> and the section of outputs.
>>
>> As per my observation,  rg_a_public_ip shows "null" in the parameter 
>> section of rg_b. while rg_a_public_ip shows the correct IP address in 
>> the outputs section of the yaml file.
>>
>>
>>
>> My questions are:
>>
>> 1)  Does this behavior is expected as designed or this is a bug?
>>
>> 2)  What is the alternative solution for the above case(user want to get
>> the run-time information of the instance when creating the second 
>> resource
>> group)  if this behavior is expected?
>>
>>
>>
>> --- a.yaml ---
>>
>> resources:
>>
>> rg_a:
>>
>>type: OS::Heat::ResourceGroup
>>
>>properties:
>>
>>count: 1
>>
>>resource_def:
>>
>>type: b.yaml
>>
>>properties:
>>
>> ...
>>
>>
>>
>> rg_b:
>>
>> type: OS::Heat::ResourceGroup
>>
>> depends_on:
>>
>>  -rg_a
>>
>> properties:
>>
>>  count: 2
>>
>>  resource_def:
>>
>>  type: c.yaml
>>
>>  properties:
>>
>>  rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
>>   the value is "null"
>>
>>  ...
>>
>>
>>
>> outputs:
>>
>> rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
>> -  the value is correct.
>>
>> --
>>
>>
>>
>> --b.yaml  
>>
>> ...
>>
>> resources:
>>
>>  rg_a:
>>
>> type: OS::Nova::Server
>>
>> properties:
>>
>>   ...
>>
>> outputs:
>>
>>   rg_a_public_ip:
>>
>>   value: {get_attr: [rg_a, networks, public, 0]}
>>
>> --
>>
>>
>>
>> -- c.yaml 
>>
>> parameters:
>>
>> rg_a_public_ip:
>>
>>   type: string
>>
>>   description: IP of rg_a
>>
>> ...
>>
>> resources:
>>
>> rg_b:
>>
>>  type: OS::Nova::Server
>>
>>  properties:
>>
>>   ...
>>
>>  outputs:
>>
>>   ...
>>
>> ---
>>
>>
>>
>> Regards,
>>
>> Gary
>>
>>
>>
>>
>> _
>> _ OpenStack Development Mailing 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 

Re: [openstack-dev] [OpenStack-Dev][All][Manila] Api development question - nested urls - which approach is better?

2016-03-10 Thread nidhi.hada
Hi All,

This is a general doubt related to taking a decision on REST API url 
construction.

In case of “nested urls”, lets say I have a relationship between
two entities as below:
access_group is parent can have many access_group_entries.

Now for accessing access_group I have already created


· Create access group - POST /access_groups

· Show access_group – GET /access_groups/

· List access_group – GET /access_groups/

· Delete access_group – PUT /access_groups/

That’s fine till here.

Now when I work on child entity that is access_group_entry, I
face a problem.


Here, i have two options for url construction for access_group_entries.

Option1 :-
Considering that access_group_entry is related to access_group, it
should be designed as a suburl, I go as below:


· Create access-group-entry -- POST '/access_groups/%s/entries'   i 
send “access_group_id” in which entry is to be created, as part of url, okay. 
no issue. it works.

· Show access-group-entry  -- GET  '/access_groups/%s/entries/%s'  
need two variables from user, access_group_id and access_group_entry_id -
But I do not have access_group_id!!
as when, i say show access_group_entry  - i 
have just uuid of access_group_entry_directly.
That's a problem. is it ? what to do in such case?


· List access-group-entry  -- GET '/access_groups/%s/entries'>>> Here 
also its not mandatory that user will always give access_group_id.

He might ask access_group_entry list for all access_groups in a go..

hence same problem.

Option2 :-
==
Not creating a suburl, instead creating an independent url

RESOURCES_PATH = '/access_groups_entries'
RESOURCE_PATH = '/access_groups_entries/%s'

1)Create POST '/access_groups_entries'  >> Passing access_group_id in body
2)Show   GET  '/access_groups_entries/%s'  directly access_group_entry_id 
here to be shown

3)List   GET '/access_groups/%s/entries' directly access_group_entry_id 
here to be shown.
If access_group_id is given for filtering, will go as part of body.

It solves above problem but it creates a new url for a resource
which is child of a earlier created url.
Is that a problem?

Kindly suggest


Thanks.
Nidhi








From: Nidhi Mittal Hada (Product Engineering Service)
Sent: Wednesday, March 09, 2016 10:32 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: RE: [openstack-dev] [OpenStack-Dev][All] Api development question

Thank you Valeriy.


From: Valeriy Ponomaryov [mailto:vponomar...@mirantis.com]
Sent: Tuesday, March 08, 2016 7:05 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [OpenStack-Dev][All] Api development question

"Not found" means API you request is not registered. AFAICS, you register 
"access_groups", but request "access-groups". Diff in symbols "_" and "-".

On Tue, Mar 8, 2016 at 1:34 PM, 
> wrote:


Hi all,

I am working on a feature for share access in manila.
For that lets say for creating the entity, I created client and server
counterpart.

I am stuck as my client request is not able to reach server resource
I have created for it. This is client server log
http://paste.openstack.org/show/489642/


manila/api/v2/router.py
This is my router entry

from manila.api.v2 import access_groups
.
.

self.resources["access_groups"] = access_groups.create_resource()
mapper.resource("access_group", "access_groups",
controller=self.resources["access_groups"],
collection={"detail": "GET"},
member={"defaults": "GET"})


I don’t understand what mistake I have made that the request
Is not getting mapped to correct resource.

stack@controller:/opt/stack/manila/manila/api/v2$ ls access_groups.py
access_groups.py
stack@controller:/opt/stack/manila/manila/api/v2$

This is access_groups.py snippet
http://paste.openstack.org/show/489667/

Can someone please help in pointing, what can be probable reason of this ?
I have checked the flow from client to server, not able to catch the mistake..



Regards

Nidhi Mittal Hada
Architect | PES / COE – Kolkata India
Wipro Limited
M +91 74 3910 9883 | O +91 33 3095 
4767 | VOIP +91 33 3095 
4767



The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer 

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-10 Thread Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
Hi Sergey,

Thanks for your reply.

Thanks for your pointing out that "depends_on" is not needed when we have 
already used "get_attr".

>you create in rg_a some Server and probably it goes to active state before ip 
>address becomes available for get_attr. It is necessary to check, but if it's 
>try to add wait condition for this resource, then you will get created rg_a 
>with fully available resources and I suppose IP will be available

Do you mean that with "depends_on" functionalities, Heat will launch another 
resource group(in my case, "rg_b") as soon as the server in "rg_a" becomes 
"active" state?
Actually, in my real program code, there is  a wait condition, but it is 
located in the server template, not Resource group(in my case, it is "b.yaml), 
which is like:
-- 
rg_a_wc_notify:
type: OS::Heat::SoftwareConfig
properties:
  group: ungrouped
  config:
str_replace:
  template: |
#!/bin/bash -v
wc_notify --data-binary '{"status": "SUCCESS"}'
  params:
wc_notify: {get_attr: [master_wait_handle, curl_cli]}
--
Is it the wait condition which you mentioned in " but if it's try to add wait 
condition for this resource"? or you want this wait condition to be added to 
"a.yaml"(the template declaring resource group)?

And as per my observation, only after Heat receives the signal of "SUCCESS", 
then it try to begin launch "rg_b"(my another server in another resource group).

I am wondering whether there is a chance that, the "IP" information is 
available but Heat doesn't try to get it until the creation of the 2 resource 
groups(rg_a and rg_b) is completed?

Regards,
Gary 

-Original Message-
From: Sergey Kraynev [mailto:skray...@mirantis.com] 
Sent: Wednesday, March 09, 2016 6:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

Hi Gary,


First of all you don't need to use "depends_on", because using "get_attr" 
already create implicit dependency from rg_a.
About getting Null instead of real Ip address:
It sounds like a bug, but IMO, it's expected behavior, because I suppose it 
happens due to:
 - you create in rg_a some Server and probably it goes to active state before 
ip address becomes available for get_attr. It is necessary to check, but if 
it's try to add wait condition for this resource, then you will get created 
rg_a with fully available resources and I suppose IP will be available.

On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) 
 wrote:
> Hi,
>
>
>
> I have 3 Heat templates using ResourceGroup. There are 2 resource 
> groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires the 
> IP address of rg_a as the paremeter of rg_b. I use “rg_a_public_ip: {get_attr:
> [rg_a, rg_a_public_ip]}” to get the IP address of rg_a both in the 
> section of rg_b parameters (rg_b/properties/resource_def/properties) 
> and the section of outputs.
>
> As per my observation,  rg_a_public_ip shows “null” in the parameter 
> section of rg_b. while rg_a_public_ip shows the correct IP address in 
> the outputs section of the yaml file.
>
>
>
> My questions are:
>
> 1)  Does this behavior is expected as designed or this is a bug?
>
> 2)  What is the alternative solution for the above case(user want to get
> the run-time information of the instance when creating the second 
> resource
> group)  if this behavior is expected?
>
>
>
> --- a.yaml ---
>
> resources:
>
> rg_a:
>
>   type: OS::Heat::ResourceGroup
>
>   properties:
>
>   count: 1
>
>   resource_def:
>
>   type: b.yaml
>
>   properties:
>
>…
>
>
>
> rg_b:
>
> type: OS::Heat::ResourceGroup
>
> depends_on:
>
> -rg_a
>
> properties:
>
> count: 2
>
> resource_def:
>
> type: c.yaml
>
> properties:
>
> rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
>   the value is “null”
>
> …
>
>
>
> outputs:
>
>rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
> -  the value is correct.
>
> --
>
>
>
> --b.yaml  
>
> …
>
> resources:
>
> rg_a:
>
> type: OS::Nova::Server
>
> properties:
>
>  …
>
> outputs:
>
>  rg_a_public_ip:
>
>  value: {get_attr: [rg_a, networks, public, 0]}
>
> --
>
>
>
> -- c.yaml 
>
> parameters:
>
> rg_a_public_ip:
>
>  type: string
>
>  description: IP of rg_a
>
> …
>
> resources:
>
> rg_b:
>
> type: OS::Nova::Server
>
> properties:
>
>  …
>
> outputs:
>
>  …
>
> ---
>
>
>
> Regards,
>
> Gary
>
>
>
>
> __
>  OpenStack Development Mailing List (not for usage 

[openstack-dev] [heat] SSL(https) support for software configuration

2016-03-10 Thread Anant Patil
Hi,

There are certain gaps in SSL(https mainly) support in software
configuration and I would like to discuss it. This is in addition to
what is described in bug #1482510 [1]. I am not sure if all of this is
already thought by folks, if so do let me know.

Tools for software configuration should work by default if the Nova
instance has CA certificates installed in it at default location. Also,
there should be a way to specify the location of CA file in Nova
instance, so that the location can be passed to os-collect-config using
metadata. Since this location can be different for each VM instance, it
needs to be specified from template or env file etc. (we need to decide)

I am of the opinion that Heat should not get into installing CA
certificates or private keys. We should assume that the image has the
proper certificates and private keys baked into it, or installed by some
other means. The tools used for software configuration must be able to
communicate with heat even before the actual user-defined software
configuration kicks in. Software configurations to set up a applications
like web server may install their own certificate as part of deployment,
and that is a different case, which I don't want to cover.

Following is my assessment of tools used to notify/poll heat. We also
need to support insecure option to make it easier to test without having
valid certificates or in deployments where there could be certificates
missing.

heat-cfntools
  - Uses curl, so IMO, ca certs in default location is taken care.
  - Insecure option is already added
  - Need to add an option for CA cert (--cacert) if not in default
location. E.g. /opt/aws/bin/cfn-signal --cacert 
And we pass that down to curl command.

os-collect-config
  - Uses requests lib, system dependent default location is not searched
  - Insecure is being added [2]
  - cafile location needs to be specified from template? Each server
can have their own custom location of ca files, so there needs a way
to specify that from template. Could this be a property of nova
server? When we are preparing metadata, we can use this property to
configure ca_file.

heat-config-notify
  added cafile and insecure option [3]

Additionally, heat can use the insecure config option from heat_clients
section and use it while creating OSC's config. This setting is
overridden when template includes cafile location of server being
configured.

We can have SSL gate job with devstack running with SSL enabled and the
test image having valid CA certificates in it.

Let me know your opinion!

-- Anant

[1] https://bugs.launchpad.net/heat/+bug/1482510
[2] https://review.openstack.org/#/c/284725/
[3] https://review.openstack.org/#/c/285157/

__
OpenStack Development Mailing 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] What's Up, Doc? 11 March 2016

2016-03-10 Thread Lana Brindley
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi everyone,

This week I've been smashing some older bugs from our queue, and can now 
confirm that as a team we've closed everything older than a year! What a great 
effort, and a fabulous way to go into our release period. We have less than a 
month now before release, so I've been briefing our new release managers Brian 
and Olga, and have also spent some time speaking to various people about what 
docs will be releasing for Mitaka. Install Guide testing is now well underway, 
but we can always use more hands, so please consider getting involved. If you 
need help getting started, please contact Matt Kassawara, or any docs core.

== Progress towards Mitaka ==

26 days to go!

500 bugs closed so far for this release, which means we're about on par with 
where we were this time last release. Keep squishing those bugs!

Docs Testing
* Volunteers required!
* https://wiki.openstack.org/wiki/Documentation/MitakaDocTesting

Release Managers:
We now have two release managers for Mitaka: Brian Moss, and Olga Gusarenko. 
They'll be making sure we stay on track as we hurtle towards 7 April, and will 
be backed up by Anne, Andreas, myself, and of course our lovely core team.

== The Road to Austin ==

* Speaker acceptances have now gone out, and the schedule is available: 
https://www.openstack.org/summit/austin-2016/summit-schedule/#day=2016-04-24
* PTL nominations for Newton have now opened: 
https://wiki.openstack.org/wiki/PTL_Elections_March_2016. I'm very pleased to 
announce that I will be submitting my candidacy for docs.
* I have requested workrooms and fishbowls for the Austin Design Summit. I'll 
let you know when we get our allocation.
* You should be starting to think about booking travel and accommodation soon! 
If you need a visa to travel to the United States, there's more info here: 
https://www.openstack.org/summit/austin-2016/austin-and-travel/#visa

== Speciality Teams ==

'''HA Guide - Bogdan Dobrelya'''
No update this week.

'''Installation Guide - Matt Kassawara'''
No update this week.

'''Networking Guide - Edgar Magana'''
Progress towards the missing features and new ones for Mitaka. DSCP for QoS 
section is in good shape: https://review.openstack.org/#/c/273638/ Last 
Networking Guide meeting: 
http://eavesdrop.openstack.org/meetings/networking_guide/2016/networking_guide.2016-03-03-16.03.log.html
 Still missing a lot of attendence to the IRC meeting but we are happy with 
more contributions to the guide. Matt provided a short overview on how to 
contribute during the Neutron mid-cycle sessions

'''Security Guide - Nathaniel Dillon'''
No update this week.

'''User Guides - Joseph Robinson'''
User Guide APAC and US meetings this week - discussed merging the CLI 
reorganization patch, which was merged following the meeting. Becuase of a 
meetbot error, the APAC meeting did not take place, but I am sending a summary 
out to the mailing list, which I am still working on.

'''Ops and Arch Guides - Shilla Saebi'''
No update this week.

'''API Docs - Anne Gentle'''
No update this week.

Bug days: Work on api-site bugs: https://bugs.launchpad.net/openstack-api-site 
Work on these remaining WADL bugs which have patches: 
https://review.openstack.org/#/c/288315/ 
https://review.openstack.org/#/c/283114/ Continue to review and work on 
bootprint patch. Karin Bradshaw working on CSS updates.

'''Config Ref - Gauvain Pocentek'''
No update this week.

'''Training labs - Pranav Salunke, Roger Luethi'''
We merged support for snapshots in the KVM backend. Osbash works now on 32-bit 
i386 nodes which also makes nested virtualization (creating the whole VM 
cluster within a VM) possible. There is a new configuration file for users who 
only want an automated VM cluster setup, but no automated OpenStack 
installation. Finally, a new feature splits server log files according to 
cluster build phases, which makes it much easier to identify the origin of a 
specific log entry.

'''Training Guides - Matjaz Pancur'''
Enabled automatic bug status resolving at merge 
(https://review.openstack.org/#/c/283453/) WIP - Upstream training - add 
toolchain info for trainees (https://review.openstack.org/#/c/286941/)

'''Hypervisor Tuning Guide - Joe Topjian'''
I included a bunch of links related to NUMA and large memory pages. It'd be 
nice if the relevant information was pulled from the links and summarized. I 
also included some information about virtio-scsi.

'''UX/UI Docs Guidelines - Linette Williams'''
No update this week.

== Doc team meeting ==

Next meetings:

The APAC meeting was held this week. You can read the minutes here: 
https://wiki.openstack.org/wiki/Documentation/MeetingLogs#2016-03-09

Next meetings:
US: No meeting this week
APAC: Wednesday 23 March, 00:30 UTC

Please go ahead and add any agenda items to the meeting page here: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

- --

Keep on doc'ing!

Lana


Re: [openstack-dev] [horizon] Proposal to add Diana Whitten tohorizon-core

2016-03-10 Thread Zhenguo Niu
+1 from me, thanks for all the hard work!

On Thu, Mar 10, 2016 at 3:27 AM, Michael Krotscheck 
wrote:

> +1. Another vote in favor of ditching django altogether is good by me :)
>
> On Wed, Mar 9, 2016 at 11:25 AM Thai Q Tran  wrote:
>
>> Big +1 from me, thanks for all the hard work Diana!
>>
>>
>> - Original message -
>> From: David Lyle 
>> To: OpenStack Development Mailing List > >
>> Cc:
>> Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to
>> horizon-core
>> Date: Tue, Mar 8, 2016 2:07 PM
>>
>> I propose adding Diana Whitten[1] to horizon-core.
>>
>> Diana is an active reviewer, contributor and community member. Over
>> the past couple of releases, Diana has driven extensive changes around
>> theme-ability in Horizon and drastically increased the standardization
>> of our use of bootstrap. During this time, Diana has also provided
>> valuable reviews to keep us on the straight and narrow preventing our
>> continued abuse of defenseless web technologies.
>>
>> Please respond with comments, +1s, or objections by Friday.
>>
>> Thanks,
>> David
>>
>> [1]
>> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>>
>> __
>> OpenStack Development Mailing 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
>
>


-- 
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing 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][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Adam Young

On 03/09/2016 04:35 PM, Fei Long Wang wrote:

Hi all,

Yesterday I just found cloudkitty is using the same default port 
() which is used by Zaqar now. So I'm wondering if there is any 
rule/policy for those new services need to be aware. I googled but 
can't find anything about this. The only link I can find is 
http://docs.openstack.org/liberty/config-reference/content/firewalls-default-ports.html. 
So my question is should we document the default ports list on an 
official place given the big tent mode? Thanks.



Run it on port 443.  In Apache HTTPD. Avoid the madness.

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


Re: [openstack-dev] [tc] Question about electorate for project without gerrit contribution

2016-03-10 Thread Tony Breeds
On Thu, Mar 10, 2016 at 11:45:14PM +, Jeremy Stanley wrote:

> The electorate rolls for project-teams without any
> deliverables/repos end up being limited to the "extra-atc" entries
> for them. For example, the I18N team has done an excellent job of
> providing a curated list of active translators, rendered at:
> 
> http://governance.openstack.org/reference/projects/i18n.html#extra-atcs

Ah thank you for the clear and detailed reply.  We'll update the election
tooling to handle this case fro UX and I18N.
 
> I guess for teams with no deliverables *and* no extra ATCs, they
> probably also don't need a PTL?
> 
> Packaging-Deb is the only one I see in an especially strange state
> at the moment: it has one existing repo (the rest are phantoms which
> were never created) with two Gerrit changes, both owned by the
> team's sole code contributor (based on our traditional process of
> enumerating Gerrit change owners)... Congratulations, Monty, on your
> new de facto PTL-ship!

:D

Yours Tony.


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


Re: [openstack-dev] Reg: Configuration Management tool for Openstack.

2016-03-10 Thread Samuel Cassiba
You can also use Chef for either a small-scale or production level
deployment.

Check out https://wiki.openstack.org/wiki/Chef/GettingStarted for a bit
more context, or if you just want to jump in head-first
https://github.com/openstack/openstack-chef-repo/blob/master/README.md

On Thu, Mar 10, 2016 at 1:58 AM, Ferhat Ozkasgarli 
wrote:

> If you are new to openstack, go with packstack. You will learn the basics
> quickly  with packstack.
>
> For production scale installations, you must consider Fuel Infra from
> Mirantis.
> On Mar 8, 2016 1:06 PM, "Shinobu Kinjo"  wrote:
>
>> Good post!
>>
>>
>> http://docs.openstack.org/developer/openstack-ansible/install-guide/index.html
>>
>> So ansible?, I'm puppeter though...
>>
>> Cheers,
>> S
>>
>> On Tue, Mar 8, 2016 at 7:49 PM, Gyorgy Szombathelyi
>>  wrote:
>> > Hi,
>> >
>> > Since I think Ansible is the best config management tool, you should
>> try the openstack-ansible installer, or our Ansible based one:
>> > https://github.com/DoclerLabs/openstack
>> >
>> > Br,
>> > György
>> >
>> >> -Original Message-
>> >> From: cool dharma06 [mailto:cooldharm...@gmail.com]
>> >> Sent: 2016 március 7, hétfő 8:17
>> >> To: openstack-dev@lists.openstack.org
>> >> Subject: [openstack-dev] Reg: Configuration Management tool for
>> >> Openstack.
>> >>
>> >> Hi all,
>> >>
>> >> i have the following questions in Openstack deployment.
>> >>
>> >> 1. i need some configuration management tool for OpenStack. After some
>> >> searches i got some tools like Puppet, Ansible, Chef, Fuel and
>> tripleO. i am
>> >> confused to which one to go.
>> >>
>> >> 2. And also i checked the Github repository for openstack-puppet, i
>> think its
>> >> not active.
>> >>
>> >> Suggest some tool for openstack. i am newbie for this large scale
>> deploment
>> >> and also for configuration management.
>> >>
>> >>
>> >> thanks & regards,
>> >> cooldharma06  .. :)
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>> Email:
>> shin...@linux.com
>> GitHub:
>> shinobu-x
>> Blog:
>> Life with Distributed Computational System based on OpenSource
>>
>> __
>> OpenStack Development Mailing 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] [tripleo] Contributing to TripleO is challenging

2016-03-10 Thread James Slagle
On Fri, Mar 4, 2016 at 9:23 AM, Emilien Macchi  wrote:
> That's not the name of any Summit's talk, it's just an e-mail I wanted
> to write for a long time.
>
> It is an attempt to expose facts or things I've heard a lot; and bring
> constructive thoughts about why it's challenging to contribute in
> TripleO project.

Thanks for sharing your thoughts. I struggled a bit with responding to
be honest, as I think the points you call attention to often lead to
frustration on the side of both patch authors and reviewers.

I think these things are more anecdotal than fact based to be honest.
But, that doesn't mean that it's not a constructive conversation, so
thanks for calling out the issues.

At the core, we need a lot more investment in CI. We could use more
physical resources and more contributors. Or, we could direct some of
the capacity away from new development and put it towards CI
improvements instead. That might allow us to cover more features in
CI, which I think would have a direct impact on review velocity. There
are also some architectural changes proposed (split-stack) that will
allow us to scale CI more effectively than we have in the past.

>
>
> 1/ "I don't review this patch, we don't have CI coverage."

If a patch is obviously not covered by CI, it would go along way if
the author indicated if and how they manually tested a patch.

Often, I see a non-trivial patch that our CI does not cover. When I
try to manually test the patch, it doesn't work. Sometimes in very
obvious ways. Over time, this sort of pattern lowers confidence of
core reviewers to +2 and approve non-trivial patches that they
themselves haven't manually tested.

I know that manual testing doesn't scale.

However, right now, our CI doesn't scale to cover every possible
combination of features either.

So, if we want to keep moving forward at all, some things will have to
be manually tested. If patch authors added a comment such as "i tested
this with network isolation and it worked as expected, and it doesn't
break existing CI", that would go a long ways towards giving people
the confidence to approve it.

>
> One thing I've noticed in TripleO is that a very few people are involved
> in CI work.
> In my opinion, CI system is more critical than any feature in a product.
> Developing Software without tests is a bit like http://goo.gl/OlgFRc
> All people - specially core - in the project should be involved in CI
> work. If you are TripleO core and you don't contribute on CI, you might
> ask yourself why.

That's fair. Although it's also fair to ask the same of non-cores.

It's not just the job of core reviewers to get patches to pass CI. A
lot of times I get pinged to review patches with a sense of urgency
about them, yet they are sitting with failed CI. And it's not like
people are pinging me to help them understand and fix why the patch
has failed CI. They just want it reviewed/approved.

>
>
> 2/ "I don't review this patch, CI is broken."

Do you mean when CI is generally failing across the board?

I can honestly say that when CI is generally failing for whatever
reason (infrastructure issue, OpenStack regression, TripleO
regression), there is almost always 1 or 2 TripleO cores all over that
issue. Not everyone needs to be working on the issue at once. But, I
can honestly say I've never seen TripleO just completely red where at
least one person wasn't working on it almost exclusively.

However, if you're saying that people don't review a patch if that
specific patch has failed CI on it, then I think there is a lot of
shared responsibility there. It's not just on reviewers to see why
something has failed CI, or to try to get it to pass.

I'm less likely to review a patch if it has been sitting for several
days with a failed CI job on it. The author probably doesn't need it
landed that bad if that's the case. Often, there's not even a comment
if they looked at the failed job to see why. So, yea, I'm less likely
to review those patches honestly, and maybe that's not fair.

Just so I'm clear, I'm not saying that I ignore patches with failed
CI. I try and help new contributors or people I might not recognize
get their patches to pass CI. I recognize there is a steep learning
curve there.

But when I see patches out there from folks who are capable of at
least triaging the failure, and that hasn't been done, I'm certainly
guilty of de-prioritizing reviewing that patch. Maybe that's a bad
thing.

>
> Another thing I've noticed in TripleO is that when CI is broken, again,
> a very few people are actually working on fixing failures.

This sounds like you're talking about scenarios when all of TripleO Ci
is failing. In which case, I really disagree with your assertion that
people aren't rapidly fixing those failures.

> My experience over the last years taught me to stop my daily work when
> CI is broken and fix it asap.
>
> 3/ "I don't review it, because this feature / code is not my area".
>
> My first though is 

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

2016-03-10 Thread Mike Scherbakov
Regarding #2
> we already generate from templates required information for a plugin
developer to start development
and it is great.
So, back to what I said:
> However, we can have fpb generating template plugin, with commented code
in there. If you uncomment, you a get a comprehensive example of a working
plugin. To ensure that uncommented code would actually work, we must have a
test for it (which would uncomment - run - ensure everything deploys).
We already have great template plugins generated by fpb. Question is, how
do we ensure that this generated template actually works.

> # 3 adding real deployment test for fuel-plugins will not help here,
since change in openstack.yaml caused this problem.
True. That's why I started new thread, where I suggest that we must allow
to install older plugins into new releases of Fuel, with the warning only.

> Well, what about tomorrow? On SCF we create stable branches and master is
open for next release. You probably will want to run those tests
against Fuel 10, and FPB's master won't have that "10" release in
examples metadata.
True Igor, please see my same answer to Evgeny above - we need to change
pluggable framework to allow installation of older plugins to newer
releases of Fuel. Before we do that, I suggest to extend supported releases
list right away to Newton. No need to wait for new bug from QA.

On Thu, Mar 10, 2016 at 5:44 AM Igor Kalnitsky 
wrote:

> Well, what about tomorrow? On SCF we create stable branches and master
> is open for next release. You probably will want to run those tests
> against Fuel 10, and FPB's master won't have that "10" release in
> examples metadata. Because it's something that we usually don't want
> to release, and FPB lifecycle is untied from Fuel's.
>
> The only way to avoid that problem is to teach tests to prepare
> plugins themselves. They are like test fixtures, it's not very good
> that your rely on something that you don't maintain.
>
> On Thu, Mar 10, 2016 at 11:01 AM, Evgeniy L  wrote:
> > Mike,
> >
> > # 2 don't agree, we already generate from templates required information
> for
> > a plugin developer to start development, purpose of plugin examples is
> > different, it's used as integration tests for plugins, also QA team uses
> > them as Functional tests, they overloaded with tasks and designed to have
> > good coverage, so it will only confuse plugin developer.
> > # 3 adding real deployment test for fuel-plugins will not help here,
> since
> > change in openstack.yaml caused this problem.
> >
> > Thanks,
> >
> > On Thu, Mar 10, 2016 at 10:55 AM, Matthew Mosesohn <
> mmoses...@mirantis.com>
> > wrote:
> >>
> >> Mike,
> >>
> >> #1 - If you truly agree with that, you should weigh in here:
> >> https://review.openstack.org/#/c/287286/
> >> #2 - Requires a blueprint and new docs, but okay.
> >> #3 - Yes! We have very poor CI for fuel plugin builder. All it does is
> >> ensure it makes a plugin, not that it can be installed and deployed.
> >>
> >> On Thu, Mar 10, 2016 at 10:44 AM, Mike Scherbakov
> >>  wrote:
> >> > Folks,
> >> > here is what I think:
> >> > 1) I suggest to fix what is broken now. So that people who come across
> >> > examples would not have to deal with issues. We may debate for other
> few
> >> > days (hopefully not more), and all plugin devs will be suffering
> during
> >> > this
> >> > time. Also, according to Matt,
> >> >
> >> >> I should add that this is the only automated daily test that will
> >> >> verify
> >> > that our plugin framework actually works.
> >> > simply means that we must fix it in order to catch any possible
> >> > regressions
> >> > we may introduce later (if not already).
> >> >
> >> > 2) I like idea Ilya K. has proposed. To rephrase it (to put extra
> accent
> >> > into it and get feedback), we may not need to have example plugins.
> >> > However,
> >> > we can have fpb generating template plugin, with commented code in
> >> > there. If
> >> > you uncomment, you a get a comprehensive example of a working plugin.
> >> > To ensure that uncommented code would actually work, we must have a
> test
> >> > for
> >> > it (which would uncomment - run - ensure everything deploys).
> >> >
> >> > 3) Ideally, we need to catch issues at pre-commit stage. So I'd
> suggest
> >> > to
> >> > think if there is a way to have tests, which would run such examples
> >> > against
> >> > pluggable framework for every change to the framework, so that we can
> >> > have
> >> > -1 right away if something goes wrong.
> >> >
> >> > I've started separate thread on general thoughts about backward
> >> > compatibility and multiple releases support, which actually affects
> >> > examples: [1]
> >> >
> >> >
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088921.html
> >> >
> >> > Thanks,
> >> >
> >> > On Wed, Mar 9, 2016 at 7:59 AM Evgeniy L  wrote:
> >> >>
> >> >> Because it doesn't make much sense for 

[openstack-dev] [all][Elections] Nominations for OpenStack PTLs (Program Team Leads) are now open

2016-03-10 Thread Tony Breeds
Nominations for OpenStack PTLs (Program Team Leads) are now open and will
remain open until March 17, 23:59 UTC.

All candidates must be submitted as a text file to the openstack/election
repository as explained on the wiki[0].

In order to be an eligible candidate (and be allowed to vote) in a given PTL
election, you need to have contributed an accepted patch to one of the
corresponding program's projects[1] during the Liberty-Mitaka timeframe (March
4, 2015 00:00 UTC to March 3, 2016 23:59 UTC)

Additional information about the nomination process can be found here:
https://wiki.openstack.org/wiki/PTL_Elections_March_2016

As Tristan and I approve candidates, we will update the list of confirmed
candidates on the above wiki page.

Elections will begin at 00:00 March 18, 2016 (UTC) and run until 23:59 March
24, 2016 (UTC).

The electorate is requested to confirm their email address in gerrit,
review.openstack.org > Settings > Contact Information >  Preferred Email, prior
to March 17 (00:00 UTC), 2016 so that the emailed ballots are mailed to the
correct email address.

Happy running,
Tony.

[0] 
https://wiki.openstack.org/wiki/PTL_Elections_March_2016#How_to_submit_your_candidacy
[1]  
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=march-2016-elections


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


Re: [openstack-dev] [tc] Question about electorate for project without gerrit contribution

2016-03-10 Thread Monty Taylor

On 03/10/2016 05:45 PM, Jeremy Stanley wrote:


Packaging-Deb is the only one I see in an especially strange state
at the moment: it has one existing repo (the rest are phantoms which
were never created) with two Gerrit changes, both owned by the
team's sole code contributor (based on our traditional process of
enumerating Gerrit change owners)... Congratulations, Monty, on your
new de facto PTL-ship!

https://review.openstack.org/#/q/status:merged+project:openstack/deb-openstack-pkg-tools


I, for one, welcome my new self overlord.


__
OpenStack Development Mailing 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] [release][all][ptl] preparing to create stable/mitaka branches for libraries

2016-03-10 Thread gordon chung


On 10/03/2016 4:26 PM, Doug Hellmann wrote:
> Excerpts from gordon chung's message of 2016-03-10 13:17:25 +:
>>
>> On 09/03/2016 12:26 PM, Doug Hellmann wrote:
>>> It's time to start opening the stable branches for libraries. I've
>>> prepared a list of repositories and the proposed versions from which
>>> we will create stable/mitaka branches, and need each team to sign off on
>>> the versions. If you know you intend to release a bug fix version in
>>> the next couple of days, we can wait to avoid having to backport
>>> patches, but otherwise we should go ahead and create the branches.
>>>
>>> I will process each repository as I hear from the owning team.
>>>
>>> openstack/ceilometermiddleware 0.4.0
>>> openstack/python-ceilometerclient 2.3.0
>>
>> - ceilometermiddleware is ready to go
>> - ceilometerclient requires one last release.
>> https://review.openstack.org/#/c/291166/
>
> OK, I made a note. Let me know when you're ready.
>
>> - aodhclient will probably need it's initial tag for Mitaka as well
>> (it's a new client library)
>
> We have 3 releases on file for Mitaka already. Is 0.3.0 the best one to
> use for a stable branch, or do you intend to have another release soon?
>
> Doug

- Ceilometerclient 2.4.0 has been proposed and is ready
- aodhclient 0.3.0 is good for stable/mitaka

cheers,

-- 
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] [tc] Question about electorate for project without gerrit contribution

2016-03-10 Thread Jeremy Stanley
On 2016-03-10 22:05:00 + (+), Tristan Cacqueray wrote:
> Projects such as Openstack UX, Packaging Deb and i18n do not have active
> contributions we can collect from git repos listed as project
> deliverables. For these projects, how can the election officials
> validate PTL candidacy and what would be the electorate roll in case of
> an election ?

The electorate rolls for project-teams without any
deliverables/repos end up being limited to the "extra-atc" entries
for them. For example, the I18N team has done an excellent job of
providing a curated list of active translators, rendered at:

http://governance.openstack.org/reference/projects/i18n.html#extra-atcs

I guess for teams with no deliverables *and* no extra ATCs, they
probably also don't need a PTL?

Packaging-Deb is the only one I see in an especially strange state
at the moment: it has one existing repo (the rest are phantoms which
were never created) with two Gerrit changes, both owned by the
team's sole code contributor (based on our traditional process of
enumerating Gerrit change owners)... Congratulations, Monty, on your
new de facto PTL-ship!

https://review.openstack.org/#/q/status:merged+project:openstack/deb-openstack-pkg-tools

Obviously, we'll need the TC to step in on unusual corner cases with
inactive/newly-minted teams, such as this one.
-- 
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] [Fuel] FFE request for osnailyfacter refactoring for Puppet Master compatibility

2016-03-10 Thread Dmitry Borodaenko
Granted, merge deadlines are still as defined below: March 16 and 24.

For the record, the spec for this feature:
https://review.openstack.org/284853

The spec has positive votes from fuel-library CL and cores, so consensus
is indeed reached. Get a +1 from the fuel-python CL and I'll merge it.

-- 
Dmitry Borodaenko


On Thu, Mar 10, 2016 at 10:29:15AM -0700, Scott Brimhall wrote:
> Hi Dmitry,
> 
> We have reached design agreement on this feature as of this morning,
> March 10th.  The spec has been accepted and the test/merge plan
> presented for remaining patches by March 24 was agreed upon.  Can the
> conditional status of the FFE request be removed, please?
> 
> Thanks,
> Scott Brimhall
> 
> > On Mar 3, 2016, at 5:22 PM, Dmitry Borodaenko  
> > wrote:
> > 
> > Granted conditionally, design consensus deadline March 10, merge
> > deadline March 16 for patches that do not conflict with
> > fuel-openstack-tasks and fuel-remove-conflict-openstack, March 24 for
> > remaining patches.
> > 
> > If design consensus is not reached by March 10, the exception will be
> > revoked.
> > 
> > -- 
> > Dmitry Borodaenko
> > 
> > 
> > On Wed, Mar 02, 2016 at 07:01:02AM -0700, Scott Brimhall wrote:
> >> This is not possible to move to 10. This is a critical feature that
> >> our 2 largest customers are dependent on for deployment at the end of
> >> May. Puppet Master flat out will not work with a Fuel deployed
> >> environment without doing this unless we were to create our own
> >> composition layer, which would leave us with two separate code bases
> >> to maintain.  That isn't an option and this pretty much has to happen
> >> in 9.
> >> 
> >> ---
> >> Scott Brimhall, Cloud Architect
> >> Mirantis - Pure Play Openstack
> >> 
> >>> On Mar 2, 2016, at 02:01, Aleksandr Didenko  wrote:
> >>> 
> >>> Hi,
> >>> 
>  Merging this code is relatively non-intrusive to core Fuel Library code
>  as it is merely re-organizing the file structure of the osnailyfacter
>  module to be compatible with Puppet Master. 
> >>> 
> >>> It looks like super-intrusive to me. Modular manifests are,
> >>> actually, the core of Fuel Library. And the majority of changes we
> >>> introduce in Fuel Library are proposed for those manifests. So if
> >>> you're going to move those manifests into "osnailyfacter::*" classes
> >>> then it will basically conflict with the 90% of other patches for
> >>> Fuel Library. This may slow down development of other features as
> >>> well as bug fixing.
> >>> 
> >>> Also I see no patches on review and spec is not yet accepted. I
> >>> think starting such an intrusive feature after FF is too risky,
> >>> let's move it to 10.0.
> >>> 
> >>> Regards,
> >>> Alex
> >>> 
>  On Wed, Mar 2, 2016 at 1:21 AM, Scott Brimhall  
>  wrote:
>  Greetings,
>  
>  As you might know, we are working on integrating a 3rd party
>  configuration management platform (Puppet Master) with Fuel.
>  This integration will provide the capability for state enforcement
>  and will further enable "day 2" operations of a Fuel-deployed site.
>  We must refactor the 'osnailyfacter' module in Fuel Library to be
>  compatible with both a masterful and masterless Puppet approach.
>  
>  This change is required to enable a Puppet Master based LCM
>  solution.
>  
>  We request a FFE for this feature for 3 weeks, until Mar 24.  By that
>  time, we will provide a tested solution in accordance with the following
>  specifications [1].
>  
>  The feature includes the following components:
>  
>  1. Refactor 'osnailyfacter' Fuel Library module to be compatible with
>  Puppet Master by becoming a valid and compliant Puppet module.
>  This involves moving manifests into the proper manifests directory
>  and moving the contents into classes that can be included by Puppet
>  Master.
>  2. Update deployment tasks to update their manifest path to the new
>  location.
>  
>  Merging this code is relatively non-intrusive to core Fuel Library code
>  as it is merely re-organizing the file structure of the osnailyfacter
>  module to be compatible with Puppet Master.  Upon updating the
>  deployment tasks to reflect the new location of manifests, this feature
>  remains compatible with the masterless puppet apply approach that
>  Fuel uses while providing the ability to integrate a Puppet Master
>  based LCM solution.
>  
>  Overall, I consider this change as low risk for integrity and timeline of
>  the release and it is a critical feature for the ability to integrate an 
>  LCM
>  solution using Puppet Master.
>  
>  Please consider our request and share concerns so we can properly
>  resolve them.
>  
>  [1] 
>  

Re: [openstack-dev] [Fuel] [FFE] Unlock Settings Tab

2016-03-10 Thread Dmitry Borodaenko
Granted. Design consensus deadline for the task history part of this
feature is extended to March 11. This does not change the merge deadline
for other parts of this feature, which is still March 24.

-- 
Dmitry Borodaenko


On Fri, Mar 11, 2016 at 01:02:52AM +0300, Alexey Shtokolov wrote:
> Dmitry,
> 
> We are really close to have the consensus, but we need one more meeting
> with Fuel-Python Component Lead Igor Kalnitsky to make the final decision.
> All patches [0] are on review. The meeting is scheduled for tomorrow (03/11
> 1:30pm CET).
> Could you please grant us one more day for it?
> 
> [0] -
> https://review.openstack.org/#/q/topic:bp/store-deployment-tasks-history
> 
> --
> WBR, Alexey Shtokolov
> 
> 2016-03-04 3:13 GMT+03:00 Dmitry Borodaenko :
> 
> > Granted, merge deadline March 24, task history part of the feature is to
> > be excluded from this exception grant unless a consensus is reached by
> > March 10.
> >
> > Relevant part of the meeting log starts at:
> >
> > http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-03-03-16.00.log.html#l-198
> >
> > --
> > Dmitry Borodaenko
> >
> >
> > On Wed, Mar 02, 2016 at 06:00:40PM +0700, Vitaly Kramskikh wrote:
> > > Oh, so there is a spec. I was worried that this patch has
> > > "WIP-no-bprint-assigned-yet" string in the commit message, so I thought
> > > there is no spec for it. So the commit message should be updated to avoid
> > > such confusion.
> > >
> > > It's really good I've seen this spec. There are plans to overhaul UI data
> > > format description which we use for cluster and node settings to solve
> > some
> > > issues and implement long-awaited features like nested structures, so we
> > > might also want to deprecate our expression language and also switch to
> > > YAQL (and thus port YAQL to JS).
> > >
> > > 2016-03-02 17:17 GMT+07:00 Vladimir Kuklin :
> > >
> > > > Vitaly
> > > >
> > > > Thanks for bringing this up. Actually the spec has been on review for
> > > > almost 2 weeks: https://review.openstack.org/#/c/282695/. Essentially,
> > > > this is not introducing new DSL but replacing the existing one with
> > more
> > > > powerful extendable language which is being actively developed within
> > > > OpenStack and is already a part of other projects (Murano, Mistral),
> > which
> > > > has much more contributors, can return not only boolean but any
> > arbitrary
> > > > collections. So it means that we want to deprecate current Expression
> > > > language that you wrote and replace it with YAQL due to those reasons.
> > You
> > > > are not going to extend this Expression-based language in 3 weeks up to
> > > > level of support of extensions, method overloading, return of arbitrary
> > > > collections (e.g. we also want to calculate cross-depends and requires
> > > > fields on the fly which require for it to return list of dicts) and
> > support
> > > > of this stuff on your own, are you?
> > > >
> > > > On Wed, Mar 2, 2016 at 10:09 AM, Vitaly Kramskikh <
> > vkramsk...@mirantis.com
> > > > > wrote:
> > > >
> > > >> I think it's not a part of best practices to introduce changes like
> > > >> https://review.openstack.org/#/c/279714/ (adding yet another DSL to
> > the
> > > >> project) without a blueprint and review and discussion of the spec.
> > > >>
> > > >> 2016-03-02 2:19 GMT+07:00 Alexey Shtokolov :
> > > >>
> > > >>> Fuelers,
> > > >>>
> > > >>> I would like to request a feature freeze exception for "Unlock
> > settings
> > > >>> tab" feature [0]
> > > >>>
> > > >>> This feature being combined with Task-based deployment [1] and
> > > >>> LCM-readiness for Fuel deployment tasks [2] unlocks Basic LCM in
> > Fuel. We
> > > >>> conducted a thorough redesign of this feature and splitted it into
> > several
> > > >>> granular changes [3]-[6] to allow users to change settings on
> > deployed,
> > > >>> partially deployed, stopped or erred clusters and further run
> > redeployment
> > > >>> using a particular graph (custom or calculated based on expected
> > changes
> > > >>> stored in DB) and with new parameters.
> > > >>>
> > > >>> We need 3 weeks after FF to finish this feature.
> > > >>> Risk of not delivering it after 3 weeks is low.
> > > >>>
> > > >>> Patches on review or in progress:
> > > >>> 
> > > >>> https://review.openstack.org/#/c/284139/
> > > >>> https://review.openstack.org/#/c/279714/
> > > >>> https://review.openstack.org/#/c/286754/
> > > >>> https://review.openstack.org/#/c/286783/
> > > >>>
> > > >>> Specs:
> > > >>> https://review.openstack.org/#/c/286713/
> > > >>> https://review.openstack.org/#/c/284797/
> > > >>> https://review.openstack.org/#/c/282695/
> > > >>> https://review.openstack.org/#/c/284250/
> > > >>>
> > > >>>
> > > >>> [0] https://blueprints.launchpad.net/fuel/+spec/unlock-settings-tab
> > > >>> [1]
> > > >>>
> > 

Re: [openstack-dev] [tripleo] becoming third party CI (was: enabling third party CI)

2016-03-10 Thread Jeremy Stanley
On 2016-03-10 16:09:44 -0500 (-0500), Dan Prince wrote:
> This seems to be the week people want to pile it on TripleO. Talking
> about upstream is great but I suppose I'd rather debate major changes
> after we branch Mitaka. :/
[...]

I didn't mean to pile on TripleO, nor did I intend to imply this was
something which should happen ASAP (or even necessarily at all), but
I do want to better understand what actual benefit is currently
derived from this implementation vs. a more typical third-party CI
(which lots of projects are doing when they find their testing needs
are not met by the constraints of our generic test infrastructure).

> With regards to Jenkins restarts I think it is understood that our job
> times are long. How often do you find infra needs to restart Jenkins?

We're restarting all 8 of our production Jenkins masters weekly at a
minimum, but generally more often when things are busy (2-3 times a
week). For many months we've been struggling with a thread leak for
which their development team has not seen as a priority to even
triage our bug report effectively. At this point I think we've
mostly given up on expecting it to be solved by anything other than
our upcoming migration off of Jenkins, but that's another topic
altogether.

> And regardless of that what if we just said we didn't mind the
> destructiveness of losing a few jobs now and then (until our job
> times are under the line... say 1.5 hours or so). To be clear I'd
> be fine with infra pulling the rug on running jobs if this is the
> root cause of the long running jobs in TripleO.

For manual Jenkins restarts this is probably doable (if additional
hassle), but I don't know whether that's something we can easily
shoehorn into our orchestrated/automated restarts.

> I think the "benefits are minimal" is bit of an overstatement. The
> initial vision for TripleO CI stands and I would still like to see
> individual projects entertain the option to use us in their gates.
[...]

This is what I'd like to delve deeper into. The current
implementation isn't providing you with any mechanism to prevent
changes which fail jobs running in the tripleo-test cloud from
merging to your repos, is it? You're still having to manually
inspect the job results posted by it? How is that particularly
different from relying on third-party CI integration?

As for other projects making use of the same jobs, right now the
only convenience I'm aware of is that they can add check-tripleo
pipeline jobs in our Zuul layout file instead of having you add it
to yours (which could itself reside in a Git repo under your
control, giving you even more flexibility over those choices). In
fact, with a third-party CI using its own separate Gerrit account,
you would be able to leave clear -1/+1 votes on check results which
is not possible with the present solution.

So anyway, I'm not saying that I definitely believe the third-party
CI route will be better for TripleO, but I'm not (yet) clear on what
tangible benefit you're receiving now that you lose by switching to
that model.
-- 
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] [all][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Morgan Fainberg
On Thu, Mar 10, 2016 at 1:54 PM, Xav Paice  wrote:

>
>
> On 11 March 2016 at 10:45, Morgan Fainberg 
> wrote:
>
>>
>>
>> On Thu, Mar 10, 2016 at 1:29 PM, Xav Paice  wrote:
>>
>>>
>>>
>>> A simple list is probably enough for a quick ref - it's not a massive
>>> blocker if two projects slip up and get the same port number, and yes if
>>> they're doing subpaths and not ports then great.  Doesn't need to be a gate
>>> item.  But it helps communications if we have a list, even if that's
>>> temporary.
>>>
>>>
>> I really disagree that it doesn't need to be a gate item. It should
>> absolutely be gated on that services can run as a subpath.
>>
>
> Ah - yes I didn't make that very clear at all, did I  I don't think
> that selecting port numbers that don't conflict with other projects should
> be a gate item, simply because it's easy to change, and we're trying to
> steer away from that model.  I'm OK with that.  But yes, subpaths being
> unique should be gated otherwise we'll have all sorts of pain.
>

Fantastic! We're on the same page then. :)
__
OpenStack Development Mailing 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] [release][all][ptl][cinder] preparing to create stable/mitaka branches for libraries

2016-03-10 Thread Sean McGinnis
On Thu, Mar 10, 2016 at 04:19:55PM -0500, Doug Hellmann wrote:
> Excerpts from Sean McGinnis's message of 2016-03-09 15:53:31 -0600:
> > On Wed, Mar 09, 2016 at 12:26:18PM -0500, Doug Hellmann wrote:
> > > It's time to start opening the stable branches for libraries. I've
> > > prepared a list of repositories and the proposed versions from which
> > > we will create stable/mitaka branches, and need each team to sign off on
> > > the versions. If you know you intend to release a bug fix version in
> > > the next couple of days, we can wait to avoid having to backport
> > > patches, but otherwise we should go ahead and create the branches.
> > > 
> > > I will process each repository as I hear from the owning team.
> > > 
> > > openstack/os-brick 1.1.0
> > > openstack/python-cinderclient 1.6.0
> > 
> > Cinder is good to go for these.
> > 
> > Thanks!
> > Sean McGinnis (smcginnis)
> > 
> 
> How about "openstack/python-brick-cinderclient-ext 0.1.0"?
> 
> Doug

Thanks, that one is good to go as well.

Sean

> 
> __
> OpenStack Development Mailing 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] [sahara]FFE Request for resume EDP job

2016-03-10 Thread Sergey Lukjanov
Yup,

I'm expecting all FFEs to be merged by the EOW, otherwise we'll be
revisiting case by case with reject by default.

On Thu, Mar 10, 2016 at 1:38 PM, Doug Hellmann 
wrote:

> Excerpts from lu jander's message of 2016-03-07 14:28:21 +0800:
> > Hi folks,
> >
> > I would like to request a FFE for the feature “Resume EDP job”:
> >
> >
> >
> > BP:
> >
> https://blueprints.launchpad.net/sahara/+spec/add-suspend-resume-ability-for-edp-jobs
> > 
> >
> >
> > 
> >
> > Spec has been merged. https://review.openstack.org/#/c/198264/
> >
> >
> > Suspend EDP patch has been merged.
> > https://review.openstack.org/#/c/201448/
> > 
> >
> >
> > 
> >
> > Code Review: https://review.openstack.org/#/c/285839/
> > 
> >
> >
> >
> > code is ready for review.
> >
> >
> >
> > The Benefits for this change: after suspend job, we can resume this job.
> >
> >
> >
> > The Risk: The risk would be low for this patch, since the code of suspend
> > patch has been long time reviewed.
> >
> >
> >
> > Thanks,
> >
> > luhuichun
>
> Both https://review.openstack.org/#/c/285839/ and
> https://review.openstack.org/#/c/218638/ have -1 votes on them. We will
> be tagging RC1 next week, so if the team wants to include this feature
> you should work on getting the patches into shape tomorrow to give you
> time to test them before the release candidate is tagged.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Sincerely yours,
Sergey Lukjanov
Principal Software Engineer
Mirantis Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [sahara] Feature Freeze Exception Request for blueprint

2016-03-10 Thread Sergey Lukjanov
Hi,

I agree with Doug,

if we'll be able to have green CI and no -1's it's ok to be merged, so FFE
granted.

On Thu, Mar 10, 2016 at 1:35 PM, Doug Hellmann 
wrote:

> Excerpts from Grigoriy Roghkov's message of 2016-03-10 15:56:23 +0200:
> > Hi,
> >
> > Untill release of MapR 5.1.0 I couldn't have it added to sahara.
> > The release happened this day and 5.1.0 still can be add in Mitaka
> release.
> >
> > There are two patches to be merged:
> > https://review.openstack.org/#/c/286738/
> > https://review.openstack.org/#/c/286756/
> >
> > I want to request an FFE for these patches.
> >
> > Regards,
> > Grigoriy
>
> It looks like at least one of these patches is failing (the other
> is less clear, but I see a -1 there, too).  We will be tagging
> initial release candidates next week, so I suggest postponing the
> change if the jobs aren't passing by the end of the day Friday, to
> give you time to test them before prepping the release.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Sincerely yours,
Sergey Lukjanov
Principal Software Engineer
Mirantis Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] [FFE] Unlock Settings Tab

2016-03-10 Thread Alexey Shtokolov
Dmitry,

We are really close to have the consensus, but we need one more meeting
with Fuel-Python Component Lead Igor Kalnitsky to make the final decision.
All patches [0] are on review. The meeting is scheduled for tomorrow (03/11
1:30pm CET).
Could you please grant us one more day for it?

[0] -
https://review.openstack.org/#/q/topic:bp/store-deployment-tasks-history

--
WBR, Alexey Shtokolov

2016-03-04 3:13 GMT+03:00 Dmitry Borodaenko :

> Granted, merge deadline March 24, task history part of the feature is to
> be excluded from this exception grant unless a consensus is reached by
> March 10.
>
> Relevant part of the meeting log starts at:
>
> http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-03-03-16.00.log.html#l-198
>
> --
> Dmitry Borodaenko
>
>
> On Wed, Mar 02, 2016 at 06:00:40PM +0700, Vitaly Kramskikh wrote:
> > Oh, so there is a spec. I was worried that this patch has
> > "WIP-no-bprint-assigned-yet" string in the commit message, so I thought
> > there is no spec for it. So the commit message should be updated to avoid
> > such confusion.
> >
> > It's really good I've seen this spec. There are plans to overhaul UI data
> > format description which we use for cluster and node settings to solve
> some
> > issues and implement long-awaited features like nested structures, so we
> > might also want to deprecate our expression language and also switch to
> > YAQL (and thus port YAQL to JS).
> >
> > 2016-03-02 17:17 GMT+07:00 Vladimir Kuklin :
> >
> > > Vitaly
> > >
> > > Thanks for bringing this up. Actually the spec has been on review for
> > > almost 2 weeks: https://review.openstack.org/#/c/282695/. Essentially,
> > > this is not introducing new DSL but replacing the existing one with
> more
> > > powerful extendable language which is being actively developed within
> > > OpenStack and is already a part of other projects (Murano, Mistral),
> which
> > > has much more contributors, can return not only boolean but any
> arbitrary
> > > collections. So it means that we want to deprecate current Expression
> > > language that you wrote and replace it with YAQL due to those reasons.
> You
> > > are not going to extend this Expression-based language in 3 weeks up to
> > > level of support of extensions, method overloading, return of arbitrary
> > > collections (e.g. we also want to calculate cross-depends and requires
> > > fields on the fly which require for it to return list of dicts) and
> support
> > > of this stuff on your own, are you?
> > >
> > > On Wed, Mar 2, 2016 at 10:09 AM, Vitaly Kramskikh <
> vkramsk...@mirantis.com
> > > > wrote:
> > >
> > >> I think it's not a part of best practices to introduce changes like
> > >> https://review.openstack.org/#/c/279714/ (adding yet another DSL to
> the
> > >> project) without a blueprint and review and discussion of the spec.
> > >>
> > >> 2016-03-02 2:19 GMT+07:00 Alexey Shtokolov :
> > >>
> > >>> Fuelers,
> > >>>
> > >>> I would like to request a feature freeze exception for "Unlock
> settings
> > >>> tab" feature [0]
> > >>>
> > >>> This feature being combined with Task-based deployment [1] and
> > >>> LCM-readiness for Fuel deployment tasks [2] unlocks Basic LCM in
> Fuel. We
> > >>> conducted a thorough redesign of this feature and splitted it into
> several
> > >>> granular changes [3]-[6] to allow users to change settings on
> deployed,
> > >>> partially deployed, stopped or erred clusters and further run
> redeployment
> > >>> using a particular graph (custom or calculated based on expected
> changes
> > >>> stored in DB) and with new parameters.
> > >>>
> > >>> We need 3 weeks after FF to finish this feature.
> > >>> Risk of not delivering it after 3 weeks is low.
> > >>>
> > >>> Patches on review or in progress:
> > >>> 
> > >>> https://review.openstack.org/#/c/284139/
> > >>> https://review.openstack.org/#/c/279714/
> > >>> https://review.openstack.org/#/c/286754/
> > >>> https://review.openstack.org/#/c/286783/
> > >>>
> > >>> Specs:
> > >>> https://review.openstack.org/#/c/286713/
> > >>> https://review.openstack.org/#/c/284797/
> > >>> https://review.openstack.org/#/c/282695/
> > >>> https://review.openstack.org/#/c/284250/
> > >>>
> > >>>
> > >>> [0] https://blueprints.launchpad.net/fuel/+spec/unlock-settings-tab
> > >>> [1]
> > >>>
> https://blueprints.launchpad.net/fuel/+spec/enable-task-based-deployment
> > >>> [2]
> > >>>
> https://blueprints.launchpad.net/fuel/+spec/granular-task-lcm-readiness
> > >>> [3]
> > >>>
> https://blueprints.launchpad.net/fuel/+spec/computable-task-fields-yaql
> > >>> [4]
> > >>>
> https://blueprints.launchpad.net/fuel/+spec/store-deployment-tasks-history
> > >>> [5]
> https://blueprints.launchpad.net/fuel/+spec/custom-graph-execution
> > >>> [6]
> > >>>
> 

[openstack-dev] [tc] Question about electorate for project without gerrit contribution

2016-03-10 Thread Tristan Cacqueray
Projects such as Openstack UX, Packaging Deb and i18n do not have active
contributions we can collect from git repos listed as project
deliverables. For these projects, how can the election officials
validate PTL candidacy and what would be the electorate roll in case of
an election ?

Regards,
-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] [all][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Xav Paice
On 11 March 2016 at 10:45, Morgan Fainberg 
wrote:

>
>
> On Thu, Mar 10, 2016 at 1:29 PM, Xav Paice  wrote:
>
>>
>>
>> A simple list is probably enough for a quick ref - it's not a massive
>> blocker if two projects slip up and get the same port number, and yes if
>> they're doing subpaths and not ports then great.  Doesn't need to be a gate
>> item.  But it helps communications if we have a list, even if that's
>> temporary.
>>
>>
> I really disagree that it doesn't need to be a gate item. It should
> absolutely be gated on that services can run as a subpath.
>

Ah - yes I didn't make that very clear at all, did I  I don't think
that selecting port numbers that don't conflict with other projects should
be a gate item, simply because it's easy to change, and we're trying to
steer away from that model.  I'm OK with that.  But yes, subpaths being
unique should be gated otherwise we'll have all sorts of pain.
__
OpenStack Development Mailing 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][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Morgan Fainberg
On Thu, Mar 10, 2016 at 1:29 PM, Xav Paice  wrote:

> Remember that we're talking here about all the projects, not just
> keystone.  I can't see that we'll move everything to subpaths at any time
> soon, and until that point we still need to at least make an informal
> agreement as to which 'default' port to expect services to live on.  Even
> if that's just for devstack until we get to the subpaths nirvana.
>
> It's great that services are looking to the catalog for the locations of
> endpoints - but unless we're comfortable that every cloud is going to
> select a bunch of (different) random ports for each service until such time
> as subpaths are a reality, then we need to communicate in some way.
>
> I don't see the need for a full web service environment in devstack - all
> that would really do is limit the choices that ops can make about the best
> web server/wsgi service.  If people concentrate efforts on apache/mod_wsgi,
> those wanting to use uwsgi, nginx, gunicorn, etc are going to have a hard
> road.  There's valid choices for using other web services (in fact, there's
> some massive arguments against mod_wsgi).
>
> A simple list is probably enough for a quick ref - it's not a massive
> blocker if two projects slip up and get the same port number, and yes if
> they're doing subpaths and not ports then great.  Doesn't need to be a gate
> item.  But it helps communications if we have a list, even if that's
> temporary.
>
>
I really disagree that it doesn't need to be a gate item. It should
absolutely be gated on that services can run as a subpath.


> How about a 'default settings' list for a 'standard' reference
> environment?  When ops deviate from the list (and we will) that's a
> concious decision we make.  Should we say that the ports used in devstack
> are the default list, and if a new project wants to get into devstack then
> they need to choose a port not in use (or subpaths)?
>
> On 11 March 2016 at 05:43, Brant Knudson  wrote:
>
>>
>>
>> On Thu, Mar 10, 2016 at 8:10 AM, Thomas Herve  wrote:
>>
>>> On Thu, Mar 10, 2016 at 2:55 PM, Sean Dague  wrote:
>>> > On 03/10/2016 08:40 AM, Thomas Herve wrote:
>>> >> On Thu, Mar 10, 2016 at 2:28 PM, Chris Dent 
>>> wrote:
>>> >>> +many. It would be great if we just got rid of the runnable web
>>> >>> servers in the projects and just expose wsgi apps (the tools like
>>> >>> devstack etc mounted under whatever the available server is).
>>> >>
>>> >> Isn't devstack meant for development? Running the APIs in a WSGI
>>> >> container like Apache or uwsgi makes for a terrible debugging
>>> >> experience. Just this morning I had to prevent aodh from running in
>>> >> Apache to be able to run it standalone.
>>> >>
>>> >> Also, those apps that use WSGI still bind a different port. The fact
>>> >> that it runs in Apache doesn't really solve the URLs problem.
>>> >
>>> > But they shouldn't. I do realize it's taking a while to get there, but
>>> > this is the push to get rid of all these weird ports. The point is to
>>> > get them all on 80 in a subpath or a separate domain.
>>> >
>>> >
>>> > If projects use the pbr wsgi_script directive the wsgi script will run
>>> > on wsgi ref on the commandline if you need that for debug -
>>> >
>>> https://github.com/openstack/keystone/blob/4db54810e58ad86edb92869a608fb5630a6b99e5/setup.cfg#L75
>>> > that was built to make this simpler.
>>>
>>> Right, but if we move to everything in WSGI besides a subpath, you
>>> won't be able to switch to the script easily. Unless you actually
>>> implement that using a reverse proxy.
>>>
>>> I totally understand the will to remove those ports from the final
>>> product. I question whether it's the right choice for devstack. It
>>> would seem that at least keeping those 'weird' ports for internal
>>> consumption would be useful. It's not like we're close to use the 65K
>>> available.
>>>
>>> --
>>> Thomas
>>>
>>>
>> For some time, devstack has been running with keystone accepting on both
>> it's legacy ports (:5000 and :35357), and on subpaths (:80/identity and
>> /identity_admin). I tried to change devstack to have keystone only
>> listening on subpaths but this is failing in tempest-lib -- see the errors
>> in https://review.openstack.org/#/c/193894/. At first I thought it would
>> be best to get tempest-lib doing version discovery but this turned into a
>> lot of code since version discovery requires quite a bit of parsing and
>> searching through dicts which always requires lots of error handling and
>> test code (see reviews ending at https://review.openstack.org/#/c/263452/).
>> (You might wonder why I didn't use the code that's already in
>> keystoneclient/keystoneauth for version discovery -- it's because tempest
>> doesn't use the client libs.)
>>
>> Anyways I think the alternative that's going to be backwards compatible
>> is to have the user be able to pass in the identity endpoints for 

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Matt Fischer
On Thu, Mar 10, 2016 at 2:29 PM, Xav Paice  wrote:

> Remember that we're talking here about all the projects, not just
> keystone.  I can't see that we'll move everything to subpaths at any time
> soon, and until that point we still need to at least make an informal
> agreement as to which 'default' port to expect services to live on.  Even
> if that's just for devstack until we get to the subpaths nirvana.
>
> It's great that services are looking to the catalog for the locations of
> endpoints - but unless we're comfortable that every cloud is going to
> select a bunch of (different) random ports for each service until such time
> as subpaths are a reality, then we need to communicate in some way.
>
> I don't see the need for a full web service environment in devstack - all
> that would really do is limit the choices that ops can make about the best
> web server/wsgi service.  If people concentrate efforts on apache/mod_wsgi,
> those wanting to use uwsgi, nginx, gunicorn, etc are going to have a hard
> road.  There's valid choices for using other web services (in fact, there's
> some massive arguments against mod_wsgi).
>
> A simple list is probably enough for a quick ref - it's not a massive
> blocker if two projects slip up and get the same port number, and yes if
> they're doing subpaths and not ports then great.  Doesn't need to be a gate
> item.  But it helps communications if we have a list, even if that's
> temporary.
>
> How about a 'default settings' list for a 'standard' reference
> environment?  When ops deviate from the list (and we will) that's a
> concious decision we make.  Should we say that the ports used in devstack
> are the default list, and if a new project wants to get into devstack then
> they need to choose a port not in use (or subpaths)?
>
>
+1. This is how we would set the default values in things like the puppet
modules. It's a not a good experience if two puppet modules out of the box
collide with each other. As you said operators can make whatever choices
they want later, but lets make it a conscious decision to deviate from the
standard list rather than presenting someone standing up OpenStack a port
collision and leaving them to search for something open to use.
__
OpenStack Development Mailing 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][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Morgan Fainberg
On Thu, Mar 10, 2016 at 4:43 AM, Sean Dague  wrote:

> On 03/10/2016 07:11 AM, Tim Bell wrote:
> >
> >
> > From: Sylvain Bauza >
> > Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> >  > >
> > Date: Thursday 10 March 2016 at 10:04
> > To: "OpenStack Development Mailing List (not for usage questions)"
> >  > >
> > Subject: Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list
> >
> >
> >
> > Le 09/03/2016 23:41, Matt Fischer a écrit :
> >> This is not the first time. Monasca and Murano had a collision
> >> too[1]. When this happens the changes trickle down into automation
> >> tools also and complicates things.
> >>
> >> [1] https://bugs.launchpad.net/murano/+bug/1505785
> >
> >
> > IMHO, all that info has to be standardized in the Service Catalog.
> > That's where endpoint informations can be found for a specific
> > service type and that's the basement for cross-project communication.
> >
> > FWIW, there is one cross-project spec trying to clean-up the
> > per-project bits that are not common
> >
> https://github.com/openstack/openstack-specs/blob/master/specs/service-catalog.rst
> >
> > I'm torn between 2 opinions :
> >  - either we consider that all those endpoints are (or should be -
> > for those which aren't) manageable thru config options, and thus
> > that's not a problem we should solve. Any operator can then modify
> > the ports to make sure that two conflicting big-tent projects can
> > work together.
> >  - or, we say that it can be a concern for interoperability, and
> > then we should somehow ensure that all projects can work together.
> > Then, a documentation link isn't enough IMHO, we should rather test
> > that.
> >
> >
> > If we can make it so that there are reasonable port commonalities
> > between OpenStack clouds, this would be good. Clearly, the service
> > catalog is the master so I don’t think there is an interoperability
> > concern but having each of the projects using different ports would
> > simplify some of the smaller configurations with multiple services on a
> > single box.
> >
> > This does assume that there are less big tent projects than available
> > TCP/IP ports :-)
>
> These are HTTP services. They really shoudn't be claiming new ports,
> they should be running on a real webserver on 80 or 443.
>
>
100% Correct. Services should be looking to exist on the proper HTTP ports
instead of custom ports. The "custom" ports used in the past are legacy and
we should encourage moving away from that. The only IANA assigned port is
the keystone 35357, and that comes with a host of other issues (Linux
Ephemeral Port range); we are actively working to get keystone moved to
port 80 or 443 as the default/recommended method. There are a number of
deployers/cloud operators that already run all services on 443 (using TLS
and apache/nginx to front the service).


> There is some legacy there with the original services that we are
> churning through. It would be nice if new services *started* with
> staying on wsgi only, and stopped grabbing random ports.


++
__
OpenStack Development Mailing 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] [sahara]FFE Request for resume EDP job

2016-03-10 Thread Doug Hellmann
Excerpts from lu jander's message of 2016-03-07 14:28:21 +0800:
> Hi folks,
> 
> I would like to request a FFE for the feature “Resume EDP job”:
> 
> 
> 
> BP:
> https://blueprints.launchpad.net/sahara/+spec/add-suspend-resume-ability-for-edp-jobs
> 
> 
> 
> 
> 
> Spec has been merged. https://review.openstack.org/#/c/198264/
> 
> 
> Suspend EDP patch has been merged.
> https://review.openstack.org/#/c/201448/
> 
> 
> 
> 
> 
> Code Review: https://review.openstack.org/#/c/285839/
> 
> 
> 
> 
> code is ready for review.
> 
> 
> 
> The Benefits for this change: after suspend job, we can resume this job.
> 
> 
> 
> The Risk: The risk would be low for this patch, since the code of suspend
> patch has been long time reviewed.
> 
> 
> 
> Thanks,
> 
> luhuichun

Both https://review.openstack.org/#/c/285839/ and
https://review.openstack.org/#/c/218638/ have -1 votes on them. We will
be tagging RC1 next week, so if the team wants to include this feature
you should work on getting the patches into shape tomorrow to give you
time to test them before the release candidate is tagged.

Doug

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


Re: [openstack-dev] [Murano] [FFE] Support TOSCA definitions for applications

2016-03-10 Thread Doug Hellmann
Excerpts from Serg Melikyan's message of 2016-03-07 12:19:33 -0800:
> I have no objection regarding granting this FFE.
> 
> This feature is developed as a plugin for Murano, placed in contrib
> folder and is not going to affect our main codebase in any way, so I
> am pretty sure that it's safe to grant this FFE.
> 
> If there are not objections, I propose to consider FFE granted.

Keep in mind that we will be tagging initial release candidates next
week. Since that second patch is still failing CI, it's at risk of not
making it into your release, and we wouldn't want to add it after the
first release candidate (really, after RC1 *only* bug fixes should be
merged).

Doug

> 
> On Thu, Mar 3, 2016 at 9:46 AM, Tetiana Lashchova
>  wrote:
> > Hi all,
> >
> > I would like to request a feature freeze exception for "Support TOSCA
> > definitions for applications" [1].
> > The spec is already merged [2], patch is on review [3] and the task is
> > almost finished.
> > I am looking forward for your decision about considering this change for a
> > FFE.
> >
> > [1] https://blueprints.launchpad.net/murano/+spec/support-tosca-format
> > [2] https://review.openstack.org/#/c/194422/
> > [3] https://review.openstack.org/#/c/243872/
> >
> > Thanks,
> > Tetiana
> >
> > __
> > OpenStack Development Mailing 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] [sahara] Feature Freeze Exception Request for blueprint

2016-03-10 Thread Doug Hellmann
Excerpts from Grigoriy Roghkov's message of 2016-03-10 15:56:23 +0200:
> Hi,
> 
> Untill release of MapR 5.1.0 I couldn't have it added to sahara.
> The release happened this day and 5.1.0 still can be add in Mitaka release.
> 
> There are two patches to be merged:
> https://review.openstack.org/#/c/286738/
> https://review.openstack.org/#/c/286756/
> 
> I want to request an FFE for these patches.
> 
> Regards,
> Grigoriy

It looks like at least one of these patches is failing (the other
is less clear, but I see a -1 there, too).  We will be tagging
initial release candidates next week, so I suggest postponing the
change if the jobs aren't passing by the end of the day Friday, to
give you time to test them before prepping the release.

Doug

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


Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Xav Paice
On 10 March 2016 at 10:35, Fei Long Wang  wrote:

> The only link I can find is
> http://docs.openstack.org/liberty/config-reference/content/firewalls-default-ports.html.
> So my question is should we document the default ports list on an official
> place given the big tent mode? Thanks.
>


Maybe what we should do is just keep the documentation up to date by adding
more projects to that list?
__
OpenStack Development Mailing 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][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Xav Paice
Remember that we're talking here about all the projects, not just
keystone.  I can't see that we'll move everything to subpaths at any time
soon, and until that point we still need to at least make an informal
agreement as to which 'default' port to expect services to live on.  Even
if that's just for devstack until we get to the subpaths nirvana.

It's great that services are looking to the catalog for the locations of
endpoints - but unless we're comfortable that every cloud is going to
select a bunch of (different) random ports for each service until such time
as subpaths are a reality, then we need to communicate in some way.

I don't see the need for a full web service environment in devstack - all
that would really do is limit the choices that ops can make about the best
web server/wsgi service.  If people concentrate efforts on apache/mod_wsgi,
those wanting to use uwsgi, nginx, gunicorn, etc are going to have a hard
road.  There's valid choices for using other web services (in fact, there's
some massive arguments against mod_wsgi).

A simple list is probably enough for a quick ref - it's not a massive
blocker if two projects slip up and get the same port number, and yes if
they're doing subpaths and not ports then great.  Doesn't need to be a gate
item.  But it helps communications if we have a list, even if that's
temporary.

How about a 'default settings' list for a 'standard' reference
environment?  When ops deviate from the list (and we will) that's a
concious decision we make.  Should we say that the ports used in devstack
are the default list, and if a new project wants to get into devstack then
they need to choose a port not in use (or subpaths)?

On 11 March 2016 at 05:43, Brant Knudson  wrote:

>
>
> On Thu, Mar 10, 2016 at 8:10 AM, Thomas Herve  wrote:
>
>> On Thu, Mar 10, 2016 at 2:55 PM, Sean Dague  wrote:
>> > On 03/10/2016 08:40 AM, Thomas Herve wrote:
>> >> On Thu, Mar 10, 2016 at 2:28 PM, Chris Dent 
>> wrote:
>> >>> +many. It would be great if we just got rid of the runnable web
>> >>> servers in the projects and just expose wsgi apps (the tools like
>> >>> devstack etc mounted under whatever the available server is).
>> >>
>> >> Isn't devstack meant for development? Running the APIs in a WSGI
>> >> container like Apache or uwsgi makes for a terrible debugging
>> >> experience. Just this morning I had to prevent aodh from running in
>> >> Apache to be able to run it standalone.
>> >>
>> >> Also, those apps that use WSGI still bind a different port. The fact
>> >> that it runs in Apache doesn't really solve the URLs problem.
>> >
>> > But they shouldn't. I do realize it's taking a while to get there, but
>> > this is the push to get rid of all these weird ports. The point is to
>> > get them all on 80 in a subpath or a separate domain.
>> >
>> >
>> > If projects use the pbr wsgi_script directive the wsgi script will run
>> > on wsgi ref on the commandline if you need that for debug -
>> >
>> https://github.com/openstack/keystone/blob/4db54810e58ad86edb92869a608fb5630a6b99e5/setup.cfg#L75
>> > that was built to make this simpler.
>>
>> Right, but if we move to everything in WSGI besides a subpath, you
>> won't be able to switch to the script easily. Unless you actually
>> implement that using a reverse proxy.
>>
>> I totally understand the will to remove those ports from the final
>> product. I question whether it's the right choice for devstack. It
>> would seem that at least keeping those 'weird' ports for internal
>> consumption would be useful. It's not like we're close to use the 65K
>> available.
>>
>> --
>> Thomas
>>
>>
> For some time, devstack has been running with keystone accepting on both
> it's legacy ports (:5000 and :35357), and on subpaths (:80/identity and
> /identity_admin). I tried to change devstack to have keystone only
> listening on subpaths but this is failing in tempest-lib -- see the errors
> in https://review.openstack.org/#/c/193894/. At first I thought it would
> be best to get tempest-lib doing version discovery but this turned into a
> lot of code since version discovery requires quite a bit of parsing and
> searching through dicts which always requires lots of error handling and
> test code (see reviews ending at https://review.openstack.org/#/c/263452/).
> (You might wonder why I didn't use the code that's already in
> keystoneclient/keystoneauth for version discovery -- it's because tempest
> doesn't use the client libs.)
>
> Anyways I think the alternative that's going to be backwards compatible is
> to have the user be able to pass in the identity endpoints for v2 and v3
> and have tempest use those if provided. I haven't had time to propose this
> yet.
>
> My preference would be to have the keystone processes running separately
> under uwsgi or gunicorn, then httpd proxies to that from /identity and
> /identity_admin (and :5000 and :35357 for legacy). Hopefully this would be

Re: [openstack-dev] [tripleo] becoming third party CI (was: enabling third party CI)

2016-03-10 Thread Dan Prince
On Thu, 2016-03-10 at 13:45 -0500, Paul Belanger wrote:
> On Thu, Mar 10, 2016 at 05:32:15PM +, Jeremy Stanley wrote:
> > 
> > On 2016-03-10 09:50:03 -0500 (-0500), Emilien Macchi wrote:
> > [...]
> > > 
> > > OpenStack Infra provides an easy way to plug CI systems and some
> > > CIs (Nova, Neutron, Cinder, etc) already gate on some third party
> > > systems. I was wondering if we would not be interested to
> > > investigate this area and maybe ask to our third party drivers
> > > contributors (Bigswitch, Nuage, Midonet, Cisco, Netapp, etc) to
> > > run on their own hardware TripleO CI jobs running their specific
> > > environment to enable the drivers. This CI would be plugged to
> > > TripleO CI, and would provide awesome feedback.
> > [...]
> > 
> > It's also worth broadening the discussion to reassess whether the
> > existing TripleO CI should itself follow our third-party
> > integration
> > model instead of the current implementation relying on our main
> > community Zuul/Nodepool/Jenkins servers. When this was first
> > implemented, there was a promise of adding more regions for
> > robustness and of being able to use the surplus resources
> > maintained
> > in the TripleO CI clouds to augment our generic CI workload. It's
> > been years now and these things have not really come to pass; if
> > anything, that system and its operators are still struggling to
> > keep
> > a single region up and operational and providing enough resources
> > to
> > handle the current TripleO test load.
> > 
> > The majority of unplanned whole-provider outages we've experienced
> > in Nodepool have been from the TripleO cloud going completely
> > offline (sometimes for a week or more straight), by far the
> > longest-running jobs we have are running there (which substantially
> > hampers our ability to do things like gracefully restart our
> > Jenkins
> > masters without aborting running jobs), and ultimately the benefits
> > to TripleO for this model are very minimal anyway (different
> > pipelines means the jobs aren't effectively even voting, much less
> > gating).
> > 
> > I'm not trying to slam the TripleO cloud operators, I think they're
> > doing an amazing job given the limitations they're working under
> > and
> > much of their work has provided inspiration for our Infra-Cloud
> > project too. They're helpful and responsive and a joy to
> > collaborate
> > with, but ultimately I think TripleO might actually realize more
> > benefit from adding a Zuul/Nodepool/Jenkins of their own to this
> > (we've massively streamlined the Puppet for maintaining these
> > recently and have very thorough deployment and operational
> > documentation) rather than dealing with the issues which arise from
> > being half-integrated into one they don't control.
> > 
> > I've been meaning to bring that up for discussion for a while, just
> > keep forgetting, but this thread seems like a good segue into the
> > topic.
> I tend to agree here, I think a lot of great work has been done to
> allow new 3rd
> party CI system to come online.  Especially considering we have the
> puppet-openstackci[1] module.
> 
> However, I would also like to see tripleO move more inline with our
> existing CI
> tooling, if possible.  I know that wouldn't happen over night, but
> would at
> least give better insight into how the CI is working.

TripleO uses more of OpenStack tooling than just about any project I
know of. We do have some unique requirements related to the fact that
our CI actually PXE boots instances in a cloud. Something like this:

http://blog.nemebean.com/tags/quintupleo

We have plans on the table to potentially split our Heat stack (or make
it more configurable) such that we can test the configuration side on
normal cloud instances. I'm all for the effort in this and it would get
us closer to what I think you are talking about is "normal".

Like it our not our CI does catch things that nobody else is catching.
Quirky deployment things happen and until someone gets nested virt
working on commodity cloud servers (well) I think we have a case for
our own CI cloud.

> 
> Now that we have the infracloud too, it might be worth talking about
> doing the
> samething with TripleO hardware, again if possible. There is likely
> corner cases
> where it wouldn't work, but would be interesting to talk about it.

The corner case would be does it allow us to PXE boot an instance (thus
allowing provisioning via Ironic, etc.).

We could certainly entertain the option of creating our own OVB cloud
and managing it alongside of infracloud if that is what you are asking.
 I don't think it is the best fit for TripleO today given our unique
requirements at the moment.

Dan


> 
> [1] https://github.com/openstack-infra/puppet-openstackci
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> 

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

2016-03-10 Thread Doug Hellmann
Excerpts from gordon chung's message of 2016-03-10 13:17:25 +:
> 
> On 09/03/2016 12:26 PM, Doug Hellmann wrote:
> > It's time to start opening the stable branches for libraries. I've
> > prepared a list of repositories and the proposed versions from which
> > we will create stable/mitaka branches, and need each team to sign off on
> > the versions. If you know you intend to release a bug fix version in
> > the next couple of days, we can wait to avoid having to backport
> > patches, but otherwise we should go ahead and create the branches.
> >
> > I will process each repository as I hear from the owning team.
> >
> > openstack/ceilometermiddleware 0.4.0
> > openstack/python-ceilometerclient 2.3.0
> 
> - ceilometermiddleware is ready to go
> - ceilometerclient requires one last release. 
> https://review.openstack.org/#/c/291166/

OK, I made a note. Let me know when you're ready.

> - aodhclient will probably need it's initial tag for Mitaka as well 
> (it's a new client library)

We have 3 releases on file for Mitaka already. Is 0.3.0 the best one to
use for a stable branch, or do you intend to have another release soon?

Doug

> 
> thanks for the support, Doug.
> 
> cheers,
> 

__
OpenStack Development Mailing 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] [release][all][ptl][cinder] preparing to create stable/mitaka branches for libraries

2016-03-10 Thread Doug Hellmann
Excerpts from Sean McGinnis's message of 2016-03-09 15:53:31 -0600:
> On Wed, Mar 09, 2016 at 12:26:18PM -0500, Doug Hellmann wrote:
> > It's time to start opening the stable branches for libraries. I've
> > prepared a list of repositories and the proposed versions from which
> > we will create stable/mitaka branches, and need each team to sign off on
> > the versions. If you know you intend to release a bug fix version in
> > the next couple of days, we can wait to avoid having to backport
> > patches, but otherwise we should go ahead and create the branches.
> > 
> > I will process each repository as I hear from the owning team.
> > 
> > openstack/os-brick 1.1.0
> > openstack/python-cinderclient 1.6.0
> 
> Cinder is good to go for these.
> 
> Thanks!
> Sean McGinnis (smcginnis)
> 

How about "openstack/python-brick-cinderclient-ext 0.1.0"?

Doug

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


Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

2016-03-10 Thread Fei Long Wang


On 10/03/16 06:26, Doug Hellmann wrote:
> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
>
> I will process each repository as I hear from the owning team.
>
> openstack/ceilometermiddleware 0.4.0
> openstack/django_openstack_auth 2.2.0
> openstack/glance_store 0.13.0
> openstack/ironic-lib 1.1.0
> openstack/keystoneauth 2.3.0
> openstack/keystonemiddleware 4.3.0
> openstack/os-brick 1.1.0
> openstack/os-client-config 1.16.0
> openstack/pycadf 2.1.0
> openstack/python-barbicanclient 4.0.0
> openstack/python-brick-cinderclient-ext 0.1.0
> openstack/python-ceilometerclient 2.3.0
> openstack/python-cinderclient 1.6.0
> openstack/cliff 2.0.0
> openstack/python-designateclient 2.0.0
> openstack/python-glanceclient 2.0.0
> openstack/python-heatclient 1.0.0
> openstack/python-ironic-inspector-client 1.5.0
> openstack/python-ironicclient 1.2.0
> openstack/python-keystoneclient 2.3.1
> openstack/python-manilaclient 1.8.0
> openstack/python-neutronclient 4.1.1
> openstack/python-novaclient 3.3.0
> openstack/python-saharaclient 0.13.0
> openstack/python-swiftclient 3.0.0
> openstack/python-troveclient 2.1.0
> openstack/python-zaqarclient 1.0.0
The zaqarclient looks good. Thanks, Doug.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
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] [glance]Why vm boots from the cirros image so slow?

2016-03-10 Thread Ian Cordasco
-Original Message-
From: Zhi Chang 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: March 10, 2016 at 00:54:26
To: openstack-dev 
Subject:  [openstack-dev] [glance]Why vm boots from the cirros image so slow?

> There is a question confuses me a long time. I create a vm by using the 
> "cirros" image. Why  
> the vm was so slow?

The "cirros" image shouldn't be terribly slow. It's a very tiny operating 
system that shouldn't require a lot of resources. It's simple and great for our 
typical use case of verifying that glance and nova are working together well 
and nova is booting images properly.

> In the VNC console, I see these info says "further output written to 
> /dev/tty0". And the  
> vm hangs a long time. What does the vm doing at that time??

I was talking to a coworker earlier today and some versions of the cirros image 
attempt to generate a random number which can cause it to hang.

> Besides, could someone tell me the history of the image name "cirros"?

I suspect someone who actually works on the CirrOS project would know better 
(https://launchpad.net/cirros).

--  
Ian Cordasco


__
OpenStack Development Mailing 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] becoming third party CI (was: enabling third party CI)

2016-03-10 Thread Dan Prince
This seems to be the week people want to pile it on TripleO. Talking
about upstream is great but I suppose I'd rather debate major changes
after we branch Mitaka. :/

Anyways, might as well get into it now. replies inline


On Thu, 2016-03-10 at 17:32 +, Jeremy Stanley wrote:
> On 2016-03-10 09:50:03 -0500 (-0500), Emilien Macchi wrote:
> [...]
> > 
> > OpenStack Infra provides an easy way to plug CI systems and some
> > CIs (Nova, Neutron, Cinder, etc) already gate on some third party
> > systems. I was wondering if we would not be interested to
> > investigate this area and maybe ask to our third party drivers
> > contributors (Bigswitch, Nuage, Midonet, Cisco, Netapp, etc) to
> > run on their own hardware TripleO CI jobs running their specific
> > environment to enable the drivers. This CI would be plugged to
> > TripleO CI, and would provide awesome feedback.
> [...]
> 
> It's also worth broadening the discussion to reassess whether the
> existing TripleO CI should itself follow our third-party integration
> model instead of the current implementation relying on our main
> community Zuul/Nodepool/Jenkins servers. When this was first
> implemented, there was a promise of adding more regions for
> robustness and of being able to use the surplus resources maintained
> in the TripleO CI clouds to augment our generic CI workload. It's
> been years now and these things have not really come to pass; if
> anything, that system and its operators are still struggling to keep
> a single region up and operational and providing enough resources to
> handle the current TripleO test load.

Yeah. We actually lost a region of hardware this last year too.

I think there is a distinction between our cloud being up and trunk
being broken. Now we've had some troubles with both over the last
couple years but in general I think our CI cloud (which provides
instances) has been up 98 maybe even 99% of the time. To be honest I've
not been tracking our actual uptime for bragging rights but I think the
actual cloud (which is connected to nodepool) has a good uptime.

We have been dealing with a lot of trunk breakages however. This is
something that occurs because we are not a gate... and it is related to
the fact that we have limited resources, and a long job wall time. So
taking a step away from the common infrastructure pipelines which do
act as an upstream gate would likely only make this worse for us.

To be fair the last outage you refer to occurred over the course of
days because we made a config change only to discover the breakage days
later (because nodepool caches the keystone endpoints). We are learning
and we do timebox our systems administration a bit more than most pure
administrators but I think the general uptime of our cloud has been
good.

> 
> The majority of unplanned whole-provider outages we've experienced
> in Nodepool have been from the TripleO cloud going completely
> offline (sometimes for a week or more straight), by far the
> longest-running jobs we have are running there (which substantially
> hampers our ability to do things like gracefully restart our Jenkins
> masters without aborting running jobs), and ultimately the benefits
> to TripleO for this model are very minimal anyway (different
> pipelines means the jobs aren't effectively even voting, much less
> gating).

With regards to Jenkins restarts I think it is understood that our job
times are long. How often do you find infra needs to restart Jenkins?
And regardless of that what if we just said we didn't mind the
destructiveness of losing a few jobs now and then (until our job times
are under the line... say 1.5 hours or so). To be clear I'd be fine
with infra pulling the rug on running jobs if this is the root cause of
the long running jobs in TripleO.

I think the "benefits are minimal" is bit of an overstatement. The
initial vision for TripleO CI stands and I would still like to see
individual projects entertain the option to use us in their gates.
Perhaps the strongest community influences are within Heat, Ironic, and
Puppet. The ability to manage the interaction with Heat, Ironic, and
Puppet in the common infrastructure is a clear benefit and there are
members of these communities that I think would agree.

> 
> I'm not trying to slam the TripleO cloud operators, I think they're
> doing an amazing job given the limitations they're working under and
> much of their work has provided inspiration for our Infra-Cloud
> project too. They're helpful and responsive and a joy to collaborate
> with, but ultimately I think TripleO might actually realize more
> benefit from adding a Zuul/Nodepool/Jenkins of their own to this
> (we've massively streamlined the Puppet for maintaining these
> recently and have very thorough deployment and operational
> documentation) rather than dealing with the issues which arise from
> being half-integrated into one they don't control.


We've actually move most of our daily management tasks for TripleO into

Re: [openstack-dev] [Neutron] Ihar as *-aas core reviewer

2016-03-10 Thread Paul Michali
+1 Great addition!



On Thu, Mar 10, 2016 at 12:14 PM Doug Wiegley 
wrote:

> The cleanup was my fault. I had removed folks that were added initially
> just for the initial *aas split. Welcome back.  :-)
>
> Thanks,
> doug
>
> > On Mar 10, 2016, at 2:33 AM, Ihar Hrachyshka 
> wrote:
> >
> > Sean M. Collins  wrote:
> >
> >> I probably speak for all FwaaS cores when I say - "Welcome!”
> >
> > …back! Thanks.
> >
> >>
> >> Frankly I had just assumed he had core privileges for our repo anyway
> >> via an inherited ACL.
> >
> > Full disclosure: I had all -*aas core privileges before [not thru
> inherited ACLs though]. It’s just that lately I lost some of them, probably
> due to some cleanup.
> >
> > To all: it’s not my plan to abuse the powers for anything that is not
> required for general success of the current stadium. If I ever decide to
> get more involved into a specific *-aas subproject strategically, I will
> get back to the corresponding *-aas team for additional approval before I
> use the powers for anything beyond those immediate goals set by PTL.
> >
> > 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


[openstack-dev] [all][api] New API Guidelines Ready for Cross Project Review

2016-03-10 Thread Everett Toews
Hi All,

The following API guideline is ready for final review. It will be merged on 
March 18, if there's no further feedback.

1. Header non-proliferation guideline
https://review.openstack.org/#/c/280381/

Cheers,
Everett
__
OpenStack Development Mailing 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] Branch miss-match between server and client in Kilo

2016-03-10 Thread Adrian Otto
Hi there Janki. Thanks for catching that. I think we can address this by 
creating a branch for the client that aligns with kilo. I’ve triaged the magnum 
bug on this, and I’m willing to help drive it to resolution together.

Regards,

Adrian

On Mar 9, 2016, at 8:16 PM, Janki Chhatbar 
> wrote:

Hi All

Greetings for the day!

I have noticed that while installing OpenStack Kilo using DevStack, the server 
components cloned are stable/kilo whereas the client components cloned are 
master. This leads to errors in installation or commands miss-match. For eg.

In tacker,
tacker git repo is stable/kilo which points to incorrect git repo URL. I have 
filled a  bug and proposed a patch for this 
(https://bugs.launchpad.net/tacker/+bug/1555130)

In Magnum,
magnum stable/kilo clones python-magnumclient master which leads to command 
mismatch (https://bugs.launchpad.net/magnum/+bug/1509273).


  1.  Does this affect all other services?
  2.  Does this mean that the branch needs to be changed for all the service's 
clients? The change will be in /devstack/lib/{service} file in "GITBRANCH" 
variable.

 If changes are required, I am willing to work on those.

Thanking you

Janki Chhatbar
OpenStack | SDN | Docker
(+91) 9409239106
simplyexplainedblog.wordpress.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-dev] [release][all][ptl] Release countdown for week R-3, Mar 14-18

2016-03-10 Thread Doug Hellmann
Focus
-

Project teams following the cycle-with-milestone model should be
preparing their first Mitaka release candidate this week. The first
release candidate should be tagged (using X.Y.Z.0rc1) as soon as
the pressure to unfreeze master is stronger than the cost of
backporting bugfixes, generally when all known critical bugs have
been fixed. We will create stable branches from the release candidate
tag points.

Project teams following the cycle-with-intermediary model should
ensure they have at least one Mitaka release, and determine whether
they will need another release before the end of the Mitaka cycle.

Any features for which a feature freeze exception was granted but
that haven't landed should be candidates for putting off until
Newton.

All project teams should be working on release-critical bugs.

General Notes
-

The global requirements list is frozen. If you need to change a
dependency, for example to include a bug fix in one of our libraries
or an upstream library, please provide enough detail in the change
request to allow the requirements review team to evaluate the change.

User-facing strings are frozen to allow the translation team time
to finish their work.

Release Actions
---

We have started creating the stable/mitaka branches for libraries.
Please follow-up to the mailing list thread [1] to acknowledge and
approve the version number to use to create the branch. That list
only includes projects with the release:managed tag, but other
projects can post on the thread to request their own branches.

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-March/088853.html

Important Dates
---

Final release candidates: R-1, Mar 28-1
Mitaka final release: Apr 4-8

Mitaka release schedule: http://releases.openstack.org/mitaka/schedule.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] [glance] Glance Mitaka: Passing the torch

2016-03-10 Thread Ronald Bradford
I am not involved in Glance, however this was well worth reading for the
experiences during the cycle, not just as a PTL but as a team and the
communication of improving the software development process.




On Wed, Mar 9, 2016 at 11:47 PM, Bhandaru, Malini K <
malini.k.bhand...@intel.com> wrote:

> Flavio, Glance and OpenStack benefited during your reign or period of
> humble service.
> Will miss you at the helm. Also thank you for anointing/attracting two new
> solid cores: Brian and Sabari
> Malini
>
>
> -Original Message-
> From: Tom Fifield [mailto:t...@openstack.org]
> Sent: Wednesday, March 09, 2016 7:55 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [glance] Glance Mitaka: Passing the torch
>
> A beautiful post, sir. Thank you for everything!
>
> On 09/03/16 22:15, Flavio Percoco wrote:
> >
> > Greetings,
> >
> > I'm not going to run for Glance's PTL position for the Newton timeframe.
> >
> > There are many motivations behind this choice. Some of them I'm
> > willing to discuss in private if people are interested but I'll go as
> > far as saying there are personal and professional reasons for me to
> > not run again.
> >
> > As I've always done in my past cycles as PTL, I'd like to take some
> > time to summarize what's happened in the past cycle not only for the
> > new PTL to know what's coming up but for the community to know how
> > things went.
> >
> > Before I even start, I'd like to thank everyone in the Glance community.
> > I truly
> > believe this was a great cycle for the project and the community has
> > gotten stronger. None of this would have been possible without the
> > help of all of you and for that, I'm deeply in debt with you all. It
> > does not just take an employer to get someone to contribute to a
> > project. Being paid, for those who are, to do Open Source is not
> > enough. It takes passion, motivation and a lot of patience to analyze
> > a technology, think out of the box and look for ways it can be
> > improved either by fixing bugs or by implementing new features. The
> > amount of time and dedication this process requires is probably worth
> > way more than what we get back from it.
> >
> > Now, with all that being said, here's Glance Mitaka for all of you:
> >
> > Completed Features
> > ==
> >
> > I think I've mentioned this already but I'm proud of it so I'll say it
> > again.
> > The prioritization and scheduling of Glance Mitaka went so well that
> > we managed to release M-3 without any feature freeze exception (FFE)
> > request. This doesn't mean all the features were implemented. In fact,
> > at least 4 were pushed back to Newton. However, the team communicated,
> > reviewed, sprinted and coded in such a way that we were able to
> > re-organize the schedule to avoid wasting time on things we new
> > weren't going to make it. This required transparency and hard
> > decisions but that's part of the job, right?
> >
> > * [0] CIM Namespace Metadata
> > * [1] Support download from and upload to Cinder volumes
> > * [2] Glance db purge utility
> > * [3] Deprecate Glance v3 API
> > * [4] Implement trusts for Glance
> > * [5] Migrate the HTTP Store to Use Requests
> > * [6] Glance Image Signing and Verification
> > * [7] Supporting OVF Single Disk Image Upload
> > * [8] Prevention of Unauthorized errors during upload/download in
> > Swift driver
> > * [9] Add filters using an ‘in’ operator
> >
> > [0]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/cim-namespace-metadata-definitions.html
> >
> > [1]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/cinder-store-upload-download.html
> >
> > [2]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/database-purge.html
> >
> > [3]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/deprecate-v3-api.html
> >
> > [4]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/glance-trusts.html
> >
> > [5]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/http-store-on-requests.html
> >
> > [6]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/image-signing-and-verification-support.html
> >
> > [7]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/ovf-lite.html
> >
> > [8]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/prevention-of-401-in-swift-driver.html
> >
> > [9]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/v2-add-filters-with-in-operator.html
> >
> >
> > If the above doesn't sound impressive to you, let me fill you in with
> > some extra info about Glance's community.
> >
> > Community
> > =
> >
> > Glance's community currently has 12 core members, 3 of which joined
> > during Mitaka and 2 of those 3 members joined at the end of 

Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka

2016-03-10 Thread Ronald Bradford
I attended the first day of the bugsmash event in New York and I have some
general feedback for future organizers of these types of events.  Hopefully
others can also share their experiences.

These comments are for the benefit of making the event better the next
time. As I attended only one location and one of three days, the experience
may have been vastly different elsewhere.

Connectivity.  The University location blocked IRC, git and gerrit ports.
One should be prepared for this situation when talking about the use of IRC
(but not being able to demonstrate your local client for example).  Knowing
how to adjust devstack to use https was something we needed to do.  I was
told you could communicate with gerrit over https but never got to see
that.  Having a reference to this, say the wiki would be great.


Prerequisites:  It would likely be more ideal if your focus is on fixing
bugs rather then talking about the process of how to contribute to fixing
bugs in OpenStack then stating that installing devstack as a pre-requisite.
At NYC almost all attendees have never installed devstack, so a good
portion of the day was getting this setup.  As such it was requested by
some devstack cores to propose this in docs, and hence
http://docs-draft.openstack.org/54/290854/1/check/gate-devstack-publish-docs/d6e9b5b//doc/build/html/guides/first-time.html
via https://review.openstack.org/#/c/290854/.   Again, this was just our
experience but this guide is for the absolute first time devstack user, and
it's detailed for that purpose.

Approach: There are multiple ways to consider addressing bugs, do you even
need devstack, or do you just use the code and unit tests. I think it's
important to cultivate the varied approaches and provide demonstrations of
each.  Which way to do you start, again it depends.   I feel that given the
NYC audience (and this may also not reflect others), that a live demo of
devstack, looking at screen logs, restarting a service, even changing
something (say a logging format, or a line of code) will show the audience
the impact of using devstack and validating manually the impact of your
code change.  Demonstrating unit tests, and other tox environments such as
pep8 is also a solid grounding in fixing bugs well and consistently.

Audience: The NYC event lacked any prep information (e.g. a surveymonkey)
of the level of attendee, this could have facilitated splitting the first
day into different tracks based on skills level.  For a 3 day event,
perhaps advertising day 1 specifically as getting your environment ready,
informs people.

Baseline:  At our event one of the outcomes was for a few cloud images to
be spun up with devstack and code. This solves some of the connectivity
issues, and also solves this first day getting started.  It enables it to
be potential more a homework task.  I think is a great way, having a public
cloud image and devstack and sample code base.  It serves as the basis of
demo land, can be cloned for attendees at any location.

My 2 cents to making this type of event even better next time.







Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford 
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Thu, Jan 28, 2016 at 4:11 AM, Wang, Shane  wrote:

> *Save the Date:*
> *Global OpenStack Bug Smash*
> *Wednesday-Friday, March 2-4, 2016*
> *RSVP by Friday, February 19*
>
> How can you help make the OpenStack Mitaka release stable and bug-free
> while having fun with your peers? Join Intel, Rackspace, Mirantis, IBM, HP,
> Huawei, CESI and others in a global bug smash across four continents as we
> work together. Then, join us later in April in Austin, Texas, U.S.A. at the
> OpenStack Summit to get re-acquainted & celebrate our accomplishments!
>
> *OUR GOAL*
> Our key goal is to collaborate round-the-clock and around the world to fix
> as many bugs as possible across the wide range of OpenStack projects. In
> the process, we’ll also help onboard and grow the number of OpenStack
> developers, and increase our collective knowledge of OpenStack tools and
> processes. To ease collaboration among all of the participants and ensure
> that core reviews can be conducted promptly, we will use the IRC channel,
> the mailing list, and Gerrit and enlist core reviewers in the event.
>
> *GET INVOLVED*
> Simply choose a place near you—and register by Friday, February 19.
> Registration is free, and we encourage you to invite others who may be
> interested.
>
>
>- Australia
>- China
>- India
>
>
>- Russia
>- United Kingdom
>- United States
>
>
> Visit the link below for additional details:
> *https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka*
> 
>
> Come make the Mitaka release a grand success through your contributions,
> and ease the 

Re: [openstack-dev] [tc] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506

2016-03-10 Thread Matt Riedemann



On 3/9/2016 3:14 PM, Matt Riedemann wrote:



On 3/9/2016 2:15 PM, Amrith Kumar wrote:

Thanks Matt.

Agreed on 1, 2, 3, and 4. The reason for #5 is that there are other
changes (for which we have FFE's) which will be merged and a new
version of the client requested.

Specifically, this change

https://review.openstack.org/290177

Thanks,

-amrith


-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
Sent: Wednesday, March 09, 2016 2:53 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] [trove][stable] proboscis tests
randomly
failing in stable branches; bug 1538506



On 3/9/2016 1:34 PM, Amrith Kumar wrote:

Matt,

We discussed this at the Trove meeting. Here's my current understanding

of the situation:


1. Your change https://review.openstack.org/#/c/290048/ which reverts

the trove client side of the change should be merged.


2. This change (the Trove API side)

https://review.openstack.org/#/c/245845/ should also be reverted. I'm
assuming that you'll submit a change for this as well for completeness.

I can submit a change for this.



3. We need to blacklist python-troveclient 2.1.0 on Liberty, this is
your change https://review.openstack.org/#/c/290021/

4. We need to blacklist python-troveclient 2.1.0 on master, this is

currently *NOT* what your change https://review.openstack.org/290168
does.
I disagree with the approach of just increasing the minimum requirement
from 1.2.0 to >=2.1.0.

I'm OK with blacklisting 2.1.0 on master and can make that change in the
same patch.



5. We need to request a new python-troveclient. Whether it should be

called 2.1.1 or 2.2.0, I'm not positive. My thought is 2.1.1. But out of
an abundance of caution, I'm going to look to #openstack-
release/#openstack-infra for guidance on this.

There are no other changes to python-troveclient since 2.1.0 was
released:

user@xubuntu:~/git/python-troveclient$ git log --oneline --no-merges
2.1.0..
user@xubuntu:~/git/python-troveclient$


So 2.1.1 is fine.



Thanks,

-amrith


-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
Sent: Wednesday, March 09, 2016 12:42 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly
failing in stable branches; bug 1538506



On 3/9/2016 8:54 AM, Amrith Kumar wrote:

Matt,

As I understand it, you have 4 changes up for review.

   Change [1] seeks to revert the change [6] to
python-troveclient

on

   master and reinstate the slave_of parameter.

   Change [2] is doing for stable/liberty, the same things that

were

   done for master in [9] on master, and [7] on Kilo earlier.

   Change [3] is looking to blacklist python-troveclient 2.1.0 on
   stable/liberty.

   Change [4] is looking to bump the minimum python-troveclient

version

   on master to 2.1.0.


Right, and there was actually another for that beat me to this:

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



Here are three questions I have:

(1) Wouldn't backward compatibility also require that you revert the
other change that removed slave_of on the server [5] ? After all,
just like a python client that calls create() with slave_of, a REST
client could call the endpoint with slave_of. What is the policy for
REST API backward compatibility?


I guess it depends on the Trove team. In Nova, backward compatibility
in the API is serious business and that's why we have left all sorts
of warts in the v2.0 API and couldn't remove them. But with the v2.1
API and microversions, we're able to move the API forward (Ironic
also has microversions, and I think cinder/neutron/keystone are
working on adding that support).

So if maintaining backward compatibility in the trove API is
important to the trove team and it's users, then yes the API change
should probably be reverted. For anyone doing CD with Trove, they are
already broken, but people upgrading from liberty to mitaka could save

themselves the break.




(2) Wouldn't [4] just block 2.1.0 in global-requirements on master
(mitaka)?


I'm not sure I understand, [4] here bumps the minimum required
version of python-troveclient to be 2.1.0, not block it. As noted in
the review, I don't know that it's really necessary to bump to 2.1.0
iff we land and release [1].



(3) Something, potentially your patch set [2], should also fix the
test that is invoking create() with slave_of, no?


[2] is stable/liberty which still has slave_of in the create API, so
I don't think that needs to be fixed in stable/liberty.



-amrith

[1] https://review.openstack.org/290048/
[2] https://review.openstack.org/290023/
[3] https://review.openstack.org/290021/
[4] https://review.openstack.org/290168/
[5] https://review.openstack.org/#/c/245845/
[6] https://review.openstack.org/#/c/245738/
[7] https://review.openstack.org/#/c/246735/

On 03/08/2016 08:24 PM, Matt Riedemann wrote:



On 3/8/2016 4:44 PM, Matt Riedemann wrote:



On 3/8/2016 

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

2016-03-10 Thread Dean Troyer
On Wed, Mar 9, 2016 at 11:26 AM, Doug Hellmann 
wrote:

> openstack/os-client-config 1.16.0
> openstack/cliff 2.0.0
>

I believe these are good to go as-is.

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] [all][infra] Switching images for testing

2016-03-10 Thread Paul Belanger
On Wed, Mar 09, 2016 at 04:41:43PM +0100, Andreas Jaeger wrote:
> We're migrating already since Friday jobs using the so-called
> bare-trusty images to ubuntu-trusty images.
> 
> These images are used for for most of unit and functional tests, for
> documentation etc. Devstack is still run on devstack-trusty nodes for
> now, but will also move at a later date.
> 
> A direct benefit of this change is that bare-trusty images are only
> available on Rackspace clouds, while the new ubuntu-trusty images are
> available in all clouds that the CI systems use. This allows a better
> load balancing for these.
> 
> We still have to convert some jobs and solve a few problems with
> specific jobs before we can make a general announcement and explain
> new possibilities that this change will bring projects.
> 
> For now, if jobs suddenly fail, please check - as usual - the log
> files and if there is anything strange happening that always worked,
> please raise it on the #openstack-infra IRC channel.
> 
> One note: We converted some names of jobs as well, so intead of
> gate-REPO-tox-ENVIRONMENT we change these to
> gate-REPO-tox-nodb-ENVIRONMENT if no MySQL/PostgreSQL databases are
> needed and otherwise to gate-REPO-tox-db-ENVIRONMENT. As final step,
> we will rename the nodb variant as default variant. Open changes are
> [1] and [2].
> 
> A more detailed announcement will come once this change is done.
> 
> Andreas
> 
> [1] https://review.openstack.org/289785
> [2] https://review.openstack.org/289848

I just want to say thank you again to Andreas for taking point in the rename
process.  Excellent work!

__
OpenStack Development Mailing 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] becoming third party CI (was: enabling third party CI)

2016-03-10 Thread Paul Belanger
On Thu, Mar 10, 2016 at 05:32:15PM +, Jeremy Stanley wrote:
> On 2016-03-10 09:50:03 -0500 (-0500), Emilien Macchi wrote:
> [...]
> > OpenStack Infra provides an easy way to plug CI systems and some
> > CIs (Nova, Neutron, Cinder, etc) already gate on some third party
> > systems. I was wondering if we would not be interested to
> > investigate this area and maybe ask to our third party drivers
> > contributors (Bigswitch, Nuage, Midonet, Cisco, Netapp, etc) to
> > run on their own hardware TripleO CI jobs running their specific
> > environment to enable the drivers. This CI would be plugged to
> > TripleO CI, and would provide awesome feedback.
> [...]
> 
> It's also worth broadening the discussion to reassess whether the
> existing TripleO CI should itself follow our third-party integration
> model instead of the current implementation relying on our main
> community Zuul/Nodepool/Jenkins servers. When this was first
> implemented, there was a promise of adding more regions for
> robustness and of being able to use the surplus resources maintained
> in the TripleO CI clouds to augment our generic CI workload. It's
> been years now and these things have not really come to pass; if
> anything, that system and its operators are still struggling to keep
> a single region up and operational and providing enough resources to
> handle the current TripleO test load.
> 
> The majority of unplanned whole-provider outages we've experienced
> in Nodepool have been from the TripleO cloud going completely
> offline (sometimes for a week or more straight), by far the
> longest-running jobs we have are running there (which substantially
> hampers our ability to do things like gracefully restart our Jenkins
> masters without aborting running jobs), and ultimately the benefits
> to TripleO for this model are very minimal anyway (different
> pipelines means the jobs aren't effectively even voting, much less
> gating).
> 
> I'm not trying to slam the TripleO cloud operators, I think they're
> doing an amazing job given the limitations they're working under and
> much of their work has provided inspiration for our Infra-Cloud
> project too. They're helpful and responsive and a joy to collaborate
> with, but ultimately I think TripleO might actually realize more
> benefit from adding a Zuul/Nodepool/Jenkins of their own to this
> (we've massively streamlined the Puppet for maintaining these
> recently and have very thorough deployment and operational
> documentation) rather than dealing with the issues which arise from
> being half-integrated into one they don't control.
> 
> I've been meaning to bring that up for discussion for a while, just
> keep forgetting, but this thread seems like a good segue into the
> topic.
I tend to agree here, I think a lot of great work has been done to allow new 3rd
party CI system to come online.  Especially considering we have the
puppet-openstackci[1] module.

However, I would also like to see tripleO move more inline with our existing CI
tooling, if possible.  I know that wouldn't happen over night, but would at
least give better insight into how the CI is working.

Now that we have the infracloud too, it might be worth talking about doing the
samething with TripleO hardware, again if possible. There is likely corner cases
where it wouldn't work, but would be interesting to talk about it.

[1] https://github.com/openstack-infra/puppet-openstackci

__
OpenStack Development Mailing 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] [release][all][ptl] preparing to create stable/mitaka branches for libraries

2016-03-10 Thread Jim Rollenhagen
On Wed, Mar 09, 2016 at 12:26:18PM -0500, Doug Hellmann wrote:
> openstack/ironic-lib 1.1.0
> openstack/python-ironic-inspector-client 1.5.0
> openstack/python-ironicclient 1.2.0

+1, thanks Doug :)

// jim

__
OpenStack Development Mailing 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] Mitaka release planning

2016-03-10 Thread Armando M.
On 3 March 2016 at 12:05, Armando M.  wrote:

> Hi Neutrinos,
>
> Mitaka-3 is out [1] and we should be focussing on rc1. This is the time
> where we switch gear:
>
>- Test M-3, find issues and target them for RC1 [2];
>- Apply/agree for FFE status for pending features on the postmortem
>[3];
>- For features that get FFE granted, I'll be moving targeting them to
>RC1. Those that get denied will be pushed back to N as soon as it opens up.
>- Be mindful of the gate. Watch its state and make sure that you
>approve/merge only changes that are targeted for RC1. Anything else should
>be pushed back, especially trivial, and cosmetic fixes.
>- RC1 is for critical and high bug fixes (release blockers or gate
>failures) and FFE changes only. Anything else should be left untargeted.
>- Remember to tie loose ends, testing and docs are paramount to allow
>our users to enjoy our new features reliably.
>
> When in doubt, reach out!
>

You have one more day to comment/provide feedback on [1], before we close
Mitaka for good. Some items still miss documentation (not even as a patch
up for review). For this reason, they will be marked incomplete for Mitaka.
An example is Flavors [2]. If I got it wrong, please let me know.

[1] https://review.openstack.org/#/c/286413/
[2] https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framework


>
> Cheers,
> Armando
>
> [1] https://launchpad.net/neutron/+milestone/mitaka-3
> [2] https://launchpad.net/neutron/+milestone/mitaka-rc1
> [3] https://review.openstack.org/#/c/286413/
>
__
OpenStack Development Mailing 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] KVM Forum 2016: Call For Participation

2016-03-10 Thread Daniel P. Berrange
=
KVM Forum 2016: Call For Participation
August 24-26, 2016 - Westin Harbor Castle - Toronto, Canada

(All submissions must be received before midnight May 1, 2016)
=

KVM Forum is an annual event that presents a rare opportunity
for developers and users to meet, discuss the state of Linux
virtualization technology, and plan for the challenges ahead. 
We invite you to lead part of the discussion by submitting a speaking
proposal for KVM Forum 2016.

At this highly technical conference, developers driving innovation
in the KVM virtualization stack (Linux, KVM, QEMU, libvirt) can
meet users who depend on KVM as part of their offerings, or to
power their data centers and clouds.

KVM Forum will include sessions on the state of the KVM
virtualization stack, planning for the future, and many
opportunities for attendees to collaborate. As we celebrate ten years
of KVM development in the Linux kernel, KVM continues to be a
critical part of the FOSS cloud infrastructure.

This year, KVM Forum is joining LinuxCon and ContainerCon in Toronto, 
Canada. Selected talks from KVM Forum will be presented on Wednesday
August 24 to the full audience of LinuxCon and ContainerCon. Also,
attendees of KVM Forum will have access to all of the LinuxCon and
ContainerCon talks on Wednesday.

http://events.linuxfoundation.org/cfp

Suggested topics:

KVM and Linux
* Scaling and optimizations
* Nested virtualization
* Linux kernel performance improvements
* Resource management (CPU, I/O, memory)
* Hardening and security
* VFIO: SR-IOV, GPU, platform device assignment
* Architecture ports

QEMU
* Management interfaces: QOM and QMP
* New devices, new boards, new architectures
* Scaling and optimizations
* Desktop virtualization and SPICE
* Virtual GPU
* virtio and vhost, including non-Linux or non-virtualized uses
* Hardening and security
* New storage features
* Live migration and fault tolerance
* High availability and continuous backup
* Real-time guest support
* Emulation and TCG
* Firmware: ACPI, UEFI, coreboot, u-Boot, etc.
* Testing

Management and infrastructure
* Managing KVM: Libvirt, OpenStack, oVirt, etc.
* Storage: glusterfs, Ceph, etc.
* Software defined networking: Open vSwitch, OpenDaylight, etc.
* Network Function Virtualization
* Security
* Provisioning
* Performance tuning


===
SUBMITTING YOUR PROPOSAL
===
Abstracts due: May 1, 2016

Please submit a short abstract (~150 words) describing your presentation
proposal. Slots vary in length up to 45 minutes. Also include the proposal
type -- one of:
- technical talk
- end-user talk

Submit your proposal here:
http://events.linuxfoundation.org/cfp
Please only use the categories "presentation" and "panel discussion"

You will receive a notification whether or not your presentation proposal
was accepted by May 27, 2016.

Speakers will receive a complimentary pass for the event. In the instance
that your submission has multiple presenters, only the primary speaker for a
proposal will receive a complementary event pass. For panel discussions, all
panelists will receive a complimentary event pass.

TECHNICAL TALKS

A good technical talk should not just report on what has happened over
the last year; it should present a concrete problem and how it impacts
the user and/or developer community. Whenever applicable, focus on
work that needs to be done, difficulties that haven't yet been solved,
and on decisions that other developers should be aware of. Summarizing
recent developments is okay but it should not be more than a small
portion of the overall talk.

END-USER TALKS

One of the big challenges as developers is to know what, where and how
people actually use our software. We will reserve a few slots for end
users talking about their deployment challenges and achievements.

If you are using KVM in production you are encouraged submit a speaking
proposal. Simply mark it as an end-user talk. As an end user, this is a
unique opportunity to get your input to developers.

HANDS-ON / BOF SESSIONS

We will reserve some time for people to get together and discuss
strategic decisions as well as other topics that are best solved within
smaller groups.

These sessions will be announced during the event. If you are interested
in organizing such a session, please add it to the list at

  http://www.linux-kvm.org/page/KVM_Forum_2016_BOF

Let people you think might be interested know about it, and encourage
them to add their names to the wiki page as well. Please try to
add your ideas to the list before KVM Forum starts.


PANEL DISCUSSIONS

If you are proposing a panel discussion, please make sure that you list
all of your potential panelists in your abstract. We will request full
biographies if a panel is accepted.


===
HOTEL / TRAVEL
===

This year's event will take place at the Westin Harbour Castle Toronto.
For 

Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem: Inside VM "fuel-master"

2016-03-10 Thread Igor Marnat
Samer,
great it works for you! :) Please don't hesitate to get in touch with the
team in #fuel-dev if needed.

Regards,
Igor Marnat

On Wed, Mar 9, 2016 at 4:38 PM, Samer Machara <
samer.mach...@telecom-sudparis.eu> wrote:

> Hi,
>  I already have VirtualBox 5.0; I run the script again, and now everything
> is working well.
>  I finish the setup. Hurrah! finally, I'm going to work.
>
> Thanks
>
> --
>
> Message: 15
> Date: Wed, 9 Mar 2016 11:16:33 +0100 (CET)
> From: Samer Machara 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [Fuel] [Openstack] Instalation Problem:
> Inside VM "fuel-master"
> Message-ID:
> <
> 56040978.58779783.1457518593738.javamail.zim...@telecom-sudparis.eu>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
> Someone can tell me what is this problem about? And how to solve it?
> Thanks.
> Samer Machara
>
>
>
>
> Some information about my system:
> OS: ubuntu 14.04 LTS
> Memory: 3,8GiB
> Processor: Intel? Core?2 Quad CPU Q9550 @ 2.83GHz ? 4
> OS type: 64-bit
> Disk 140,2GB
> VirtualBox Version: 4.3.36_Ubuntu
> Checking for 'expect'... OK
> Checking for 'xxd'... OK
> Checking for "VBoxManage"... OK
> Checking for VirtualBox Extension Pack... OK
> Checking if SSH client installed... OK
> Checking if ipconfig or ifconfig installed... OK
> config.sh
> # Section for custom configuration
> vm_slave_memory_default=512
> vm_slave_memory_mb[1]=512
> vm_slave_memory_mb[2]=512
> vm_slave_memory_mb[3]=512
>
>
> - Original Message -
>
> From: "Igor Marnat" 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Sent: Friday, March 4, 2016 3:12:21 PM
> Subject: Re: [openstack-dev] [Fuel] [Openstack] Instalation
> Problem:VBoxManage: error: Guest not running [ubuntu14.04]
>
> Samer, Maksim,
> I'd rather say that script started fuel-master already (VM "fuel-master"
> has been successfully started.), didn't find running guests, (VBoxManage:
> error: Guest not running) but it can try to start them afterwards.
>
> Samer,
> - how many VMs are there running besides fuel-master?
> - is it still showing "Waiting for product VM to download files. Please do
> NOT abort the script..." ?
> - for how long did you wait since the message above?
>
>
> Regards,
> Igor Marnat
>
> On Fri, Mar 4, 2016 at 5:04 PM, Maksim Malchuk < mmalc...@mirantis.com >
> wrote:
>
>
>
> Hi Sames,
>
> VBoxManage: error: Guest not running
>
> looks line the problem with VirtualBox itself or settings for the
> 'fuel-master' VM, it can't boot it.
> Open the VirtualBox Manger (GUI), select the 'fuel-master' VM and start it
> manually - it should show you what is exactly happens.
>
>
> On Fri, Mar 4, 2016 at 4:41 PM, Samer Machara <
> samer.mach...@telecom-sudparis.eu > wrote:
>
> 
>
>
>
> Hello, everyone.
> I'm new with Fuel. I'm trying to follow the QuickStart Guide (
> https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html
> ), but I have the following Error:
>
>
> Waiting for VM "fuel-master" to power on...
> VM "fuel-master" has been successfully started.
> VBoxManage: error: Guest not running
> VBoxManage: error: Guest not running
> ...
> VBoxManage: error: Guest not running
> Waiting for product VM to download files. Please do NOT abort the script...
>
>
> I hope you can help me.
>
> Thanks in advance
>
>
>
>
> Some information about my system:
> OS: ubuntu 14.04 LTS
> Memory: 3,8GiB
> Processor: Intel? Core?2 Quad CPU Q9550 @ 2.83GHz ? 4
> OS type: 64-bit
> Disk 140,2GB
> VirtualBox Version: 4.3.36_Ubuntu
> Checking for 'expect'... OK
> Checking for 'xxd'... OK
> Checking for "VBoxManage"... OK
> Checking for VirtualBox Extension Pack... OK
> Checking if SSH client installed... OK
> Checking if ipconfig or ifconfig installed... OK
>
>
>
>
>
> I modify the config.sh to adapt my hardware configuration
> ...
> # Master node settings
> if [ "$CONFIG_FOR" = "4GB" ]; then
> vm_master_memory_mb=1024
> vm_master_disk_mb=2
> ...
> # The number of nodes for installing OpenStack on
> elif [ "$CONFIG_FOR" = "4GB" ]; then
> cluster_size=3
> ...
> # Slave node settings. This section allows you to define CPU count for
> each slave node.
> elif [ "$CONFIG_FOR" = "4GB" ]; then
> vm_slave_cpu_default=1
> vm_slave_cpu[1]=1
> vm_slave_cpu[2]=1
> vm_slave_cpu[3]=1
> ...
> # This section allows you to define RAM size in MB for each slave node.
> elif [ "$CONFIG_FOR" = "4GB" ]; then
> vm_slave_memory_default=1024
>
>
> vm_slave_memory_mb[1]=512
> vm_slave_memory_mb[2]=512
> vm_slave_memory_mb[3]=512
> ...
> # Nodes with combined roles may require more disk space.
> if [ "$CONFIG_FOR" = "4GB" ]; then
> vm_slave_first_disk_mb=2
> vm_slave_second_disk_mb=2
> vm_slave_third_disk_mb=2
> ...
>
>
> I found someone that had a 

Re: [openstack-dev] [Horizon] Javascript linting and documentation

2016-03-10 Thread Michael Krotscheck
On Wed, Mar 9, 2016 at 4:15 PM Richard Jones  wrote:

>
> We already have a "lintq" npm task that does this, which most of us use.
> The problem is that we then ignore all the legitimate code linting warnings.
>

I think we both agree that some form of jsdoc linting is useful, yes? You'd
prefer for it to be in the doc builder, while I'm ambivalent about where
those checks happen. How about this: Let's keep the checks in there, and
once a replacement is in place, we can turn it off.

In the meantime, they do provide a benefit - for one, I know that Matt
Borland is working on digging into those warnings.


> My perspective on this is if the documentation builder can produce
> documentation that is useful then it's enforcing exactly enough checks on
> the input.
>

It sounds like we don't actually know what this documentation builder is
going to enforce. In fact, it may be more strict and/or less configurable
than eslint. I'm not comfortable turning off a rule if we don't know what
kind of a future we'll get; could you investigate and report back with your
findings?


> For example, the jsdoc linter currently forces us to write @returns
> statements in our docs for angular methods that have no return value, and
> never will (i.e. module.config()) or is otherwise not exposed to developers
> and not interesting (i.e. the return from service or controller
> construction).
>

Given javascript's flexible return types, many IDE's look to the jsdoc to
guess at what the returned type for a method is. This drives things like
code hinting, sanity checks, and tab completion. Explicitly declaring the
return type, even if it's {void}, has a concrete benefit.

And yes, I find it annoying too, but I put up with it for the beauty of
Command-Space-Oh-That's-What-I-Can-Do-Here.


> I mentioned this in passing in the meeting, but most of our JS
> documentation has been written to ngdoc syntax, and that's potentially a
> good thing since it provides much greater hinting to the doc generators
> about how to present and organise the output, but also influences things
> like @returns usefulness.
>

I remember you saying that ngdoc doesn't actually work, so I'm a bit
confused as to why we're writing documentation to that standard. Could you
clarify?


> We just have to find the right tool (or, more likely, create, since I've
> been looking for a while and haven't found a suitable tool) that uses the
> information we're coding into our comments.
>

Awesome. So once this tool is completed, let's come back to this
conversation! I don't think we can continue without really knowing what the
tradeoffs will be.

Michael
__
OpenStack Development Mailing 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] Javascript linting and documentation

2016-03-10 Thread Michael Krotscheck
On Wed, Mar 9, 2016 at 12:45 PM Tripp, Travis S 
wrote:

> The problem is that the warnings are so great that is really hard to read.
>

If all the warnings were fixed - I know Matt Borland's working on that -
would we be having this conversation?

Michael
__
OpenStack Development Mailing 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] becoming third party CI (was: enabling third party CI)

2016-03-10 Thread Jeremy Stanley
On 2016-03-10 09:50:03 -0500 (-0500), Emilien Macchi wrote:
[...]
> OpenStack Infra provides an easy way to plug CI systems and some
> CIs (Nova, Neutron, Cinder, etc) already gate on some third party
> systems. I was wondering if we would not be interested to
> investigate this area and maybe ask to our third party drivers
> contributors (Bigswitch, Nuage, Midonet, Cisco, Netapp, etc) to
> run on their own hardware TripleO CI jobs running their specific
> environment to enable the drivers. This CI would be plugged to
> TripleO CI, and would provide awesome feedback.
[...]

It's also worth broadening the discussion to reassess whether the
existing TripleO CI should itself follow our third-party integration
model instead of the current implementation relying on our main
community Zuul/Nodepool/Jenkins servers. When this was first
implemented, there was a promise of adding more regions for
robustness and of being able to use the surplus resources maintained
in the TripleO CI clouds to augment our generic CI workload. It's
been years now and these things have not really come to pass; if
anything, that system and its operators are still struggling to keep
a single region up and operational and providing enough resources to
handle the current TripleO test load.

The majority of unplanned whole-provider outages we've experienced
in Nodepool have been from the TripleO cloud going completely
offline (sometimes for a week or more straight), by far the
longest-running jobs we have are running there (which substantially
hampers our ability to do things like gracefully restart our Jenkins
masters without aborting running jobs), and ultimately the benefits
to TripleO for this model are very minimal anyway (different
pipelines means the jobs aren't effectively even voting, much less
gating).

I'm not trying to slam the TripleO cloud operators, I think they're
doing an amazing job given the limitations they're working under and
much of their work has provided inspiration for our Infra-Cloud
project too. They're helpful and responsive and a joy to collaborate
with, but ultimately I think TripleO might actually realize more
benefit from adding a Zuul/Nodepool/Jenkins of their own to this
(we've massively streamlined the Puppet for maintaining these
recently and have very thorough deployment and operational
documentation) rather than dealing with the issues which arise from
being half-integrated into one they don't control.

I've been meaning to bring that up for discussion for a while, just
keep forgetting, but this thread seems like a good segue into the
topic.
-- 
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] [Fuel] FFE request for osnailyfacter refactoring for Puppet Master compatibility

2016-03-10 Thread Scott Brimhall
Hi Dmitry,

We have reached design agreement on this feature as of this morning, March 
10th.  The spec has been accepted and the test/merge plan presented for 
remaining patches by March 24 was agreed upon.  Can the conditional status of 
the FFE request be removed, please?

Thanks,
Scott Brimhall

> On Mar 3, 2016, at 5:22 PM, Dmitry Borodaenko  
> wrote:
> 
> Granted conditionally, design consensus deadline March 10, merge
> deadline March 16 for patches that do not conflict with
> fuel-openstack-tasks and fuel-remove-conflict-openstack, March 24 for
> remaining patches.
> 
> If design consensus is not reached by March 10, the exception will be
> revoked.
> 
> -- 
> Dmitry Borodaenko
> 
> 
> On Wed, Mar 02, 2016 at 07:01:02AM -0700, Scott Brimhall wrote:
>> This is not possible to move to 10. This is a critical feature that
>> our 2 largest customers are dependent on for deployment at the end of
>> May. Puppet Master flat out will not work with a Fuel deployed
>> environment without doing this unless we were to create our own
>> composition layer, which would leave us with two separate code bases
>> to maintain.  That isn't an option and this pretty much has to happen
>> in 9.
>> 
>> ---
>> Scott Brimhall, Cloud Architect
>> Mirantis - Pure Play Openstack
>> 
>>> On Mar 2, 2016, at 02:01, Aleksandr Didenko  wrote:
>>> 
>>> Hi,
>>> 
 Merging this code is relatively non-intrusive to core Fuel Library code
 as it is merely re-organizing the file structure of the osnailyfacter
 module to be compatible with Puppet Master. 
>>> 
>>> It looks like super-intrusive to me. Modular manifests are,
>>> actually, the core of Fuel Library. And the majority of changes we
>>> introduce in Fuel Library are proposed for those manifests. So if
>>> you're going to move those manifests into "osnailyfacter::*" classes
>>> then it will basically conflict with the 90% of other patches for
>>> Fuel Library. This may slow down development of other features as
>>> well as bug fixing.
>>> 
>>> Also I see no patches on review and spec is not yet accepted. I
>>> think starting such an intrusive feature after FF is too risky,
>>> let's move it to 10.0.
>>> 
>>> Regards,
>>> Alex
>>> 
 On Wed, Mar 2, 2016 at 1:21 AM, Scott Brimhall  
 wrote:
 Greetings,
 
 As you might know, we are working on integrating a 3rd party
 configuration management platform (Puppet Master) with Fuel.
 This integration will provide the capability for state enforcement
 and will further enable "day 2" operations of a Fuel-deployed site.
 We must refactor the 'osnailyfacter' module in Fuel Library to be
 compatible with both a masterful and masterless Puppet approach.
 
 This change is required to enable a Puppet Master based LCM
 solution.
 
 We request a FFE for this feature for 3 weeks, until Mar 24.  By that
 time, we will provide a tested solution in accordance with the following
 specifications [1].
 
 The feature includes the following components:
 
 1. Refactor 'osnailyfacter' Fuel Library module to be compatible with
 Puppet Master by becoming a valid and compliant Puppet module.
 This involves moving manifests into the proper manifests directory
 and moving the contents into classes that can be included by Puppet
 Master.
 2. Update deployment tasks to update their manifest path to the new
 location.
 
 Merging this code is relatively non-intrusive to core Fuel Library code
 as it is merely re-organizing the file structure of the osnailyfacter
 module to be compatible with Puppet Master.  Upon updating the
 deployment tasks to reflect the new location of manifests, this feature
 remains compatible with the masterless puppet apply approach that
 Fuel uses while providing the ability to integrate a Puppet Master
 based LCM solution.
 
 Overall, I consider this change as low risk for integrity and timeline of
 the release and it is a critical feature for the ability to integrate an 
 LCM
 solution using Puppet Master.
 
 Please consider our request and share concerns so we can properly
 resolve them.
 
 [1] 
 https://blueprints.launchpad.net/fuel/+spec/fuel-refactor-osnailyfacter-for-puppet-master-compatibility
 
 ---
 Best Regards,
 
 Scott Brimhall
 Systems Architect
 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: 

Re: [openstack-dev] [Neutron] Ihar as *-aas core reviewer

2016-03-10 Thread Doug Wiegley
The cleanup was my fault. I had removed folks that were added initially just 
for the initial *aas split. Welcome back.  :-)

Thanks,
doug

> On Mar 10, 2016, at 2:33 AM, Ihar Hrachyshka  wrote:
> 
> Sean M. Collins  wrote:
> 
>> I probably speak for all FwaaS cores when I say - "Welcome!”
> 
> …back! Thanks.
> 
>> 
>> Frankly I had just assumed he had core privileges for our repo anyway
>> via an inherited ACL.
> 
> Full disclosure: I had all -*aas core privileges before [not thru inherited 
> ACLs though]. It’s just that lately I lost some of them, probably due to some 
> cleanup.
> 
> To all: it’s not my plan to abuse the powers for anything that is not 
> required for general success of the current stadium. If I ever decide to get 
> more involved into a specific *-aas subproject strategically, I will get back 
> to the corresponding *-aas team for additional approval before I use the 
> powers for anything beyond those immediate goals set by PTL.
> 
> 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] [Infra] upcoming review.openstack.org IP address change

2016-03-10 Thread Yolanda Robla Mota

Hello from Infra.

It's that time again... on Monday, April 11, 2016 20:00 UTC, the
OpenStack Project Infrastructure team is increasing the memory on
the server which review.openstack.org runs, and that means a new
virtual machine instance with new IP addresses assigned by our
service provider. The new IP addresses will be as follows:

IPv4 -> 104.130.246.91
IPv6 -> 2001:4800:7819:103:be76:4eff:fe05:8525

They will replace these current production IP addresses:

IPv4 -> 104.130.159.134
IPv6 -> 2001:4800:7818:102:be76:4eff:fe05:9b12

We understand that some users may be running from egress-filtered
networks with port 29418/tcp explicitly allowed to the current
review.openstack.org IP addresses, and so are providing this
information as far in advance as we can to allow them time to update
their firewalls accordingly.

Note that some users dealing with egress filtering may find it
easier to switch their local configuration to use Gerrit's REST API
via HTTPS instead, and the current release of git-review has support
for that workflow as well.
http://lists.openstack.org/pipermail/openstack-dev/2014-September/045385.html

We will follow up with final confirmation n subsequent announcements.


--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hpe.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] [docs] [api] Why WADL when you can Swagger

2016-03-10 Thread Anne Gentle
On Thu, Mar 10, 2016 at 8:03 AM, Sean Dague  wrote:

> Ok, I'm responding very late to this thread because other bits of the
> release cycle had attention.
>
> A couple of questions.
>
> 1) why are we using the JSON version of the specification instead of the
> YAML one -
>
> https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#format
>
> One of the reasons this is a bit of a hot button issue for me is beyond
> YAML being a bit more readable, it allows *comments* in the file. The
> lack of comments support in JSON makes it really problematic to do
> anything except completely obvious things that will only ever be
> consumed by a computer. Some of these APIs are big, and being able to
> provide annotations to API spec developers is really important.
>

Good question. It's because the migration makes JSON for now, but when I
edit migrated files in http://editor.swagger.io/#/, I import the JSON into
a web-based editor that lets me edit YAML.

The JSON is what's displayed with fairy-slipper but certainly for editing
purposes YAML is preferred. However it's an interesting point about
comments and interchangeability. I'd like a research spike on that.


>
> 2) What is the tox target I can use to build the HTML out of swagger for
> a single project? So that we can iterate here.
>

I added you as a reviewer to https://review.openstack.org/#/c/286659/ as
our interim "just give me HTML" replacement while continuing to work on
this spec with the infra team to figure out how to serve HTML built from
fairy-slipper RST and Swagger files.
https://review.openstack.org/#/c/276484/


>
> 3) What is the current best thinking about microversion specification.
>
> This is the #1 current issue with our API reference site, as we've now
> got 3 (and soon 4) APIs doing this, but 0 support on the API site to
> display this information. If we don't have a near term path forward I
> think we're going to just have to dump all the tools and just go to
> editing the HTML directly.
>
>
I think we'll need a Swagger file per microversion and then work in the
fairy-slipper UI to make each display. Russell Sim the original
fairy-slipper dev, wanted to work on this but he doesn't have time for this
project any more. Considering how far he brought it, I'm super grateful,
but also we need to apply some more devs to solve the display. Karen
Bradshaw has been working on fairy-slipper and we would all welcome more
developers. Can put that fit-n-finish on until we get infra builds sorted.

Let me know if you have more questions after poking around more, thanks for
asking.

Thanks,
Anne


>
>
> On 02/12/2016 04:45 PM, Anne Gentle wrote:
> > Hi all,
> > I wanted to give an update on the efforts to provide improved
> > application developer information on developer.openstack.org
> > . Wrangling this much valuable
> > information and gathering it in a way that helps people is no simple
> > matter. So. We move forward one step at a time.
> >
> > What's new?
> > 
> > This week, with every build of the api-site, we are now running
> > fairy-slipper to migrate from WADL to Swagger for API reference
> > information. Those migrated Swagger files are then copied to
> > developer.openstack.org/draft/swagger
> > .
> >
> > We know that not all files migrate smoothly. We'd love to get teams
> > looking at these migrated files. Thank you to those of you already
> > submitting fixes!
> >
> > In addition, the infra team is reviewing a spec now so that we can serve
> > API reference information from the developer.openstack.org
> >  site:
> > https://review.openstack.org/#/c/276484/
> >
> > Why are we doing all this?
> > --
> > The overall vision is still intact in the original specifications
> > [1][2], however we need to do a lot of web design and front end work to
> > get where we want to be.
> >
> > What can I do?
> > 
> > Check out these Swagger files.
> >
> http://developer.openstack.org/draft/swagger/blockstorage-v1-swagger.json
> >
> http://developer.openstack.org/draft/swagger/blockstorage-v2-swagger.json
> > http://developer.openstack.org/draft/swagger/clustering-v1-swagger.json
> > http://developer.openstack.org/draft/swagger/compute-v2.1-swagger.json
> >
> http://developer.openstack.org/draft/swagger/data-processing-v1.1-swagger.json
> > http://developer.openstack.org/draft/swagger/database-v1-swagger.json
> >
> http://developer.openstack.org/draft/swagger/identity-admin-v2-swagger.json
> >
> http://developer.openstack.org/draft/swagger/identity-extensions-v2-swagger.json
> >
> http://developer.openstack.org/draft/swagger/identity-extensions-v3-swagger.json
> > http://developer.openstack.org/draft/swagger/identity-v2-swagger.json
> > http://developer.openstack.org/draft/swagger/identity-v3-swagger.json
> > 

Re: [openstack-dev] [Neutron] Ihar as *-aas core reviewer

2016-03-10 Thread Eichberger, German
+1

Glad to have Ihar in *aaS. Much needed help!

Thanks,
German




On 3/10/16, 7:34 AM, "Brandon Logan"  wrote:

>I had the same assumption!  Either way, welcome Ihar, your skills and
>wisdom will be a great benefit.
>
>Thanks,
>Brandon
>
>On Thu, 2016-03-10 at 10:33 +0100, Ihar Hrachyshka wrote:
>> Sean M. Collins  wrote:
>> 
>> > I probably speak for all FwaaS cores when I say - "Welcome!”
>> 
>> …back! Thanks.
>> 
>> >
>> > Frankly I had just assumed he had core privileges for our repo anyway
>> > via an inherited ACL.
>> 
>> Full disclosure: I had all -*aas core privileges before [not thru inherited  
>> ACLs though]. It’s just that lately I lost some of them, probably due to  
>> some cleanup.
>> 
>> To all: it’s not my plan to abuse the powers for anything that is not  
>> required for general success of the current stadium. If I ever decide to  
>> get more involved into a specific *-aas subproject strategically, I will  
>> get back to the corresponding *-aas team for additional approval before I  
>> use the powers for anything beyond those immediate goals set by PTL.
>> 
>> 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] [all][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Brant Knudson
On Thu, Mar 10, 2016 at 8:10 AM, Thomas Herve  wrote:

> On Thu, Mar 10, 2016 at 2:55 PM, Sean Dague  wrote:
> > On 03/10/2016 08:40 AM, Thomas Herve wrote:
> >> On Thu, Mar 10, 2016 at 2:28 PM, Chris Dent 
> wrote:
> >>> +many. It would be great if we just got rid of the runnable web
> >>> servers in the projects and just expose wsgi apps (the tools like
> >>> devstack etc mounted under whatever the available server is).
> >>
> >> Isn't devstack meant for development? Running the APIs in a WSGI
> >> container like Apache or uwsgi makes for a terrible debugging
> >> experience. Just this morning I had to prevent aodh from running in
> >> Apache to be able to run it standalone.
> >>
> >> Also, those apps that use WSGI still bind a different port. The fact
> >> that it runs in Apache doesn't really solve the URLs problem.
> >
> > But they shouldn't. I do realize it's taking a while to get there, but
> > this is the push to get rid of all these weird ports. The point is to
> > get them all on 80 in a subpath or a separate domain.
> >
> >
> > If projects use the pbr wsgi_script directive the wsgi script will run
> > on wsgi ref on the commandline if you need that for debug -
> >
> https://github.com/openstack/keystone/blob/4db54810e58ad86edb92869a608fb5630a6b99e5/setup.cfg#L75
> > that was built to make this simpler.
>
> Right, but if we move to everything in WSGI besides a subpath, you
> won't be able to switch to the script easily. Unless you actually
> implement that using a reverse proxy.
>
> I totally understand the will to remove those ports from the final
> product. I question whether it's the right choice for devstack. It
> would seem that at least keeping those 'weird' ports for internal
> consumption would be useful. It's not like we're close to use the 65K
> available.
>
> --
> Thomas
>
>
For some time, devstack has been running with keystone accepting on both
it's legacy ports (:5000 and :35357), and on subpaths (:80/identity and
/identity_admin). I tried to change devstack to have keystone only
listening on subpaths but this is failing in tempest-lib -- see the errors
in https://review.openstack.org/#/c/193894/. At first I thought it would be
best to get tempest-lib doing version discovery but this turned into a lot
of code since version discovery requires quite a bit of parsing and
searching through dicts which always requires lots of error handling and
test code (see reviews ending at https://review.openstack.org/#/c/263452/).
(You might wonder why I didn't use the code that's already in
keystoneclient/keystoneauth for version discovery -- it's because tempest
doesn't use the client libs.)

Anyways I think the alternative that's going to be backwards compatible is
to have the user be able to pass in the identity endpoints for v2 and v3
and have tempest use those if provided. I haven't had time to propose this
yet.

My preference would be to have the keystone processes running separately
under uwsgi or gunicorn, then httpd proxies to that from /identity and
/identity_admin (and :5000 and :35357 for legacy). Hopefully this would be
over a unix socket talking uwsgi protocol or whatever the process and httpd
support. Note that devstack already has a TLS-proxy deployment option
that's similar. I've been hoping to have time to propose the keystone
devstack deployment use this but I'm easily distracted.

- Brant
__
OpenStack Development Mailing 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] The #openstack-packaging channel requires an invite?

2016-03-10 Thread Jeremy Stanley
On 2016-03-10 14:48:50 + (+), Kiall Mac Innes wrote:
> For anyone who may try doing this again in the future, don't set the
> invite only flag (+i), and
> then the +f #openstack-stable will trigger a redirect to the new channel.

This was intentional. It was left without -i for a period of time
(months) so people rejoining would get transparently redirected, but
to officially shut down the old channel name and prompt people to
update their configuration to reflect the new channel it's at some
point necessary to make it blatantly obvious it's no longer used.
Making it invite-only seemed to be the only simple solution to
preventing anyone from using that channel name indefinitely.
-- 
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] [nova] patches that improve code quality

2016-03-10 Thread Ed Leafe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/10/2016 03:35 AM, Markus Zoeller wrote:

> Agreed, bug reports are *not* a way to document technical debt. 
> They should be used for documenting faulty behavior which can hit 
> downstream consumers.
> 
> I also have the feeling that refactorings get less attention than 
> bug fixes and features. Matt already pointed to the numbers of
> open reviews which compete for attention. One way to make those 
> refactoring patches more visible and queryable could be to use a 
> topic "refactoring" for them. Reviewers can then search for them if
> they decide to switch their focus to resolving technical debt.

I think a specless blueprint would cover most of these situations.
This would show that it is not a bug, but an implementation of a
feature, where the feature is "code that doesn't suck as much".

I would recommend identifying these areas and submitting code *early*
in the release cycle, where the impact of refactoring won't hold up a
release. At the end of the cycle there is just too much pressure to
get features in before the freeze that no one wants to make that
harder by merging code that might conflict with those changes.

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJW4ZwoAAoJEKMgtcocwZqL8MwQAJKugI/FOFWCYptWnQbGI3t/
5bXnckt3w2FFU6jtdzRlQwDaKDUTGaEDyer0iuQi6OX1b/kpaDujymDFpP8kWNnn
ujIS5wOkX8tF3fYM58AxRgv3DENolShovFUpFvaa2jPnAl/ibORTTWY2oS9EH0z1
XJyOZt3O17cob3NqFj2Ao1NHD42v/LoJ1NjS3l6//EphJMUix5lRJUI9n00I+mCn
AFokz+JPRi2ePq6mGXf9MS4qCGGV+UZ7h1JxPmlIuJVZJ3/vypiWBwr+Rk6mWbHh
HDwFIGx6mynQvzNC1wOcMpk+n62arDEtW1y2kTcGhxYybr7kLQ+UkX8EaPfumfIB
QZ1IHktoJozNrywGbW7uqc74cFAMl+LPoe7BRAH7j/Lh7A6i5tJB5Vq6abQHSSXj
gvZPlIg08RBUQi1uKDz4Y4Ze1lhJtHOIpO93mD/V6mQjERjDMz3Wp6k34WHrI6zI
kH9OriJGCB3jauLrJiV/bQKBmWqFM2vEOEAcdbk1SdHVIrUMuE/wJNMahkzrNhsj
Z3fS+QwidgV81I3Wgsswcvn6yBN3i61kq6ThJ3ePrI+gImwCUcZmxi6cur1TAmN7
qM6OPnzwj0x2Zb85y+NW6VO9/PgDccbiFZg0WGvBcqi9Vk44QIZZL2eA6HVKc5Ik
qD4Am79IAkjONWC5Bqrh
=5r5T
-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] Branch miss-match between server and client in Kilo

2016-03-10 Thread Matt Riedemann



On 3/10/2016 9:04 AM, Matt Riedemann wrote:



On 3/9/2016 10:16 PM, Janki Chhatbar wrote:

Hi All

Greetings for the day!

I have noticed that while installing*OpenStack Kilo* using DevStack, the
server components cloned are stable/kilo whereas the client components
cloned are master. This leads to errors in installation or commands
miss-match. For eg.

_In tacker,_
tacker git repo is stable/kilo which points to incorrect git repo URL. I
have filled a  bug and proposed a patch for this
(https://bugs.launchpad.net/tacker/+bug/1555130)

_In Magnum_,
*magnum stable/kilo* clones *python-magnumclient master* which leads to
command mismatch (https://bugs.launchpad.net/magnum/+bug/1509273).

 1. Does this affect all other services?
 2. Does this mean that the branch needs to be changed for all the
service's clients? The change will be in /devstack/lib/{service}
file in "GITBRANCH" variable.

  If changes are required, I am willing to work on those.

Thanking you

Janki Chhatbar
OpenStack | SDN | Docker
(+91) 9409239106
simplyexplainedblog.wordpress.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



Assuming the APIs in the server projects have not made backward
incompatible changes since Kilo, the clients from master should continue
to work. That's a big assumption with some projects, however.

If the clients on master implement CLIs for new features that landed
after Kilo, then those won't work.



By the way, normally devstack would limit the versions of the clients 
installed based on what's in global-requirements, but in your case, 
tacker and magnumclient aren't in there (they were newer after kilo):


https://github.com/openstack/requirements/blob/stable/kilo/global-requirements.txt

--

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] [Neutron] Ihar as *-aas core reviewer

2016-03-10 Thread Brandon Logan
I had the same assumption!  Either way, welcome Ihar, your skills and
wisdom will be a great benefit.

Thanks,
Brandon

On Thu, 2016-03-10 at 10:33 +0100, Ihar Hrachyshka wrote:
> Sean M. Collins  wrote:
> 
> > I probably speak for all FwaaS cores when I say - "Welcome!”
> 
> …back! Thanks.
> 
> >
> > Frankly I had just assumed he had core privileges for our repo anyway
> > via an inherited ACL.
> 
> Full disclosure: I had all -*aas core privileges before [not thru inherited  
> ACLs though]. It’s just that lately I lost some of them, probably due to  
> some cleanup.
> 
> To all: it’s not my plan to abuse the powers for anything that is not  
> required for general success of the current stadium. If I ever decide to  
> get more involved into a specific *-aas subproject strategically, I will  
> get back to the corresponding *-aas team for additional approval before I  
> use the powers for anything beyond those immediate goals set by PTL.
> 
> 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


Re: [openstack-dev] The #openstack-packaging channel requires an invite?

2016-03-10 Thread Anita Kuno
On 03/10/2016 10:02 AM, Matt Riedemann wrote:
> 
> 
> On 3/10/2016 7:53 AM, Anita Kuno wrote:
>> On 03/09/2016 12:48 PM, Matt Riedemann wrote:
>>> Someone showed up in the -stable channel this morning asking for help
>>> with packaging. I gather they were there because the IRC wiki [1] says
>>> the #openstack-stable channel is also for packaging discussions, given
>>> -stable originated from distro people.
>>>
>>> I redirected them to https://wiki.openstack.org/wiki/Packaging which
>>> points to https://wiki.openstack.org/wiki/PackagerResources which says:
>>>
>>> "The #openstack-packaging channel on Freenode is available for packaging
>>> collaboration and discussion."
>>>
>>> Great!
>>>
>>> However, you have to apparently be invited to join the elite
>>> #openstack-packaging channel.
>>>
>>> What gives? Is that channel dead? Is there something else? Is there a
>>> secret handshake I can learn to palms to grease to get in?
>>>
>>> [1] https://wiki.openstack.org/wiki/IRC
>>>
>>
>> So could some of the respondents to this thread add their channel name
>> and description to the wikipage? https://wiki.openstack.org/wiki/IRC
>>
>> When this conversation next comes up it is the wikipage I will check and
>> hope it is up to date. I don't see me trying to find this thread in the
>> archives.
>>
>> Thanks,
>> Anita.
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> Done.
> 
Thanks Matt,
Anita.

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


[openstack-dev] [TripleO] Release notes etherpad

2016-03-10 Thread Dan Prince
Hi TripleO,

I've started an etherpad to collect all of the major features that we
completed in Mitaka. If you've worked on any major/minor features that
you'd like to see go into an official release notes doc could you
please add it here along with a detailed description:

https://etherpad.openstack.org/p/tripleo-mitaka

Dan


__
OpenStack Development Mailing 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] enabling third party CI

2016-03-10 Thread Jaume Devesa
This is something I would love to enable as well.

One of the requirements we have with Midonet is to be able to
parametrize the image build, since we need to add extra packages on it.

For the deployment options, I also think that it should not be hard either.

If you want to discuss it in any TripleO meeting, let me know.

Count on us, Emilien.


On Thu, 10 Mar 2016 09:50, Emilien Macchi wrote:
> Something I like in TripleO is third party drivers enablement, thanks to
> the plug-able interface in Puppet modules & Heat Templates.
> Though I don't see any testing regarding these drivers, it sounds like we
> add a lot of parameters and Puppet code that is supposed to deploy the
> drivers, but we never verify it actually works.
> 
> OpenStack Infra provides an easy way to plug CI systems and some CIs (Nova,
> Neutron, Cinder, etc) already gate on some third party systems.
> I was wondering if we would not be interested to investigate this area and
> maybe ask to our third party drivers contributors (Bigswitch, Nuage,
> Midonet, Cisco, Netapp, etc) to run on their own hardware TripleO CI jobs
> running their specific environment to enable the drivers.
> This CI would be plugged to TripleO CI, and would provide awesome feedback.
> 
> We need to know from these vendors if they are interested in such a thing,
> which could improve the quality of TripleO, something we both want.
> If they agree, we could help them to setup this environment (we already
> have the framework, I don't think it would require a lot of work).
> 
> I see an opportunity to involve our vendors in the quality of TripleO, and
> eventually increase the number of contributors by this result.
> 
> Any feedback is welcome here.
> -- 
> 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


-- 
Jaume Devesa
Software Engineer at Midokura

__
OpenStack Development Mailing 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] The #openstack-packaging channel requires an invite?

2016-03-10 Thread Matt Riedemann



On 3/10/2016 7:53 AM, Anita Kuno wrote:

On 03/09/2016 12:48 PM, Matt Riedemann wrote:

Someone showed up in the -stable channel this morning asking for help
with packaging. I gather they were there because the IRC wiki [1] says
the #openstack-stable channel is also for packaging discussions, given
-stable originated from distro people.

I redirected them to https://wiki.openstack.org/wiki/Packaging which
points to https://wiki.openstack.org/wiki/PackagerResources which says:

"The #openstack-packaging channel on Freenode is available for packaging
collaboration and discussion."

Great!

However, you have to apparently be invited to join the elite
#openstack-packaging channel.

What gives? Is that channel dead? Is there something else? Is there a
secret handshake I can learn to palms to grease to get in?

[1] https://wiki.openstack.org/wiki/IRC



So could some of the respondents to this thread add their channel name
and description to the wikipage? https://wiki.openstack.org/wiki/IRC

When this conversation next comes up it is the wikipage I will check and
hope it is up to date. I don't see me trying to find this thread in the
archives.

Thanks,
Anita.

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



Done.

--

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] Branch miss-match between server and client in Kilo

2016-03-10 Thread Matt Riedemann



On 3/9/2016 10:16 PM, Janki Chhatbar wrote:

Hi All

Greetings for the day!

I have noticed that while installing*OpenStack Kilo* using DevStack, the
server components cloned are stable/kilo whereas the client components
cloned are master. This leads to errors in installation or commands
miss-match. For eg.

_In tacker,_
tacker git repo is stable/kilo which points to incorrect git repo URL. I
have filled a  bug and proposed a patch for this
(https://bugs.launchpad.net/tacker/+bug/1555130)

_In Magnum_,
*magnum stable/kilo* clones *python-magnumclient master* which leads to
command mismatch (https://bugs.launchpad.net/magnum/+bug/1509273).

 1. Does this affect all other services?
 2. Does this mean that the branch needs to be changed for all the
service's clients? The change will be in /devstack/lib/{service}
file in "GITBRANCH" variable.

  If changes are required, I am willing to work on those.

Thanking you

Janki Chhatbar
OpenStack | SDN | Docker
(+91) 9409239106
simplyexplainedblog.wordpress.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



Assuming the APIs in the server projects have not made backward 
incompatible changes since Kilo, the clients from master should continue 
to work. That's a big assumption with some projects, however.


If the clients on master implement CLIs for new features that landed 
after Kilo, then those won't work.


--

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-dev] [tripleo] enabling third party CI

2016-03-10 Thread Emilien Macchi
Something I like in TripleO is third party drivers enablement, thanks to
the plug-able interface in Puppet modules & Heat Templates.
Though I don't see any testing regarding these drivers, it sounds like we
add a lot of parameters and Puppet code that is supposed to deploy the
drivers, but we never verify it actually works.

OpenStack Infra provides an easy way to plug CI systems and some CIs (Nova,
Neutron, Cinder, etc) already gate on some third party systems.
I was wondering if we would not be interested to investigate this area and
maybe ask to our third party drivers contributors (Bigswitch, Nuage,
Midonet, Cisco, Netapp, etc) to run on their own hardware TripleO CI jobs
running their specific environment to enable the drivers.
This CI would be plugged to TripleO CI, and would provide awesome feedback.

We need to know from these vendors if they are interested in such a thing,
which could improve the quality of TripleO, something we both want.
If they agree, we could help them to setup this environment (we already
have the framework, I don't think it would require a lot of work).

I see an opportunity to involve our vendors in the quality of TripleO, and
eventually increase the number of contributors by this result.

Any feedback is welcome here.
-- 
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


Re: [openstack-dev] The #openstack-packaging channel requires an invite?

2016-03-10 Thread Kiall Mac Innes
On 09/03/16 17:57, Louis Taylor wrote:
> From ChanServ:
>
> 17:55:03 -ChanServ(ChanServ@services.)- Information on #openstack-packaging:
> 17:55:03 -ChanServ(ChanServ@services.)- Registered : Nov 11 18:59:55
> 2011 (4y 17w 0d ago)
> 17:55:03 -ChanServ(ChanServ@services.)- Last used  : (about 75 weeks ago)
> 17:55:03 -ChanServ(ChanServ@services.)- Mode lock  : +imnstf #openstack-stable
> 17:55:03 -ChanServ(ChanServ@services.)- Flags  : KEEPTOPIC
> TOPICLOCK GUARD PRIVATE
> 17:55:03 -ChanServ(ChanServ@services.)- *** End of Info ***
>
> It doesn't look like it's been used in a long time (75 weeks).

For anyone who may try doing this again in the future, don't set the
invite only flag (+i), and
then the +f #openstack-stable will trigger a redirect to the new channel.

Thanks,
Kiall


__
OpenStack Development Mailing 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] [sahara] Feature Freeze Exception Request for blueprint

2016-03-10 Thread Vitaly Gridnev
+1 from me too

On Thu, Mar 10, 2016 at 5:17 PM, Sergey Reshetnyak  wrote:

> +1 from me.
>
> Patches looks good.
>
> 2016-03-10 17:14 GMT+03:00 Chad Roberts :
>
>> I am +1 for the FFE.  Unlikely to break anything else and it freshens-up
>> a plugin.
>>
>> On Thu, Mar 10, 2016 at 8:56 AM, Grigoriy Roghkov 
>> wrote:
>>
>>> Hi,
>>>
>>> Untill release of MapR 5.1.0 I couldn't have it added to sahara.
>>> The release happened this day and 5.1.0 still can be add in Mitaka
>>> release.
>>>
>>> There are two patches to be merged:
>>> https://review.openstack.org/#/c/286738/
>>> https://review.openstack.org/#/c/286756/
>>>
>>> I want to request an FFE for these patches.
>>>
>>> Regards,
>>> Grigoriy
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>
>


-- 
Best Regards,
Vitaly Gridnev
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] [sahara] Feature Freeze Exception Request for blueprint

2016-03-10 Thread Sergey Reshetnyak
+1 from me.

Patches looks good.

2016-03-10 17:14 GMT+03:00 Chad Roberts :

> I am +1 for the FFE.  Unlikely to break anything else and it freshens-up a
> plugin.
>
> On Thu, Mar 10, 2016 at 8:56 AM, Grigoriy Roghkov 
> wrote:
>
>> Hi,
>>
>> Untill release of MapR 5.1.0 I couldn't have it added to sahara.
>> The release happened this day and 5.1.0 still can be add in Mitaka
>> release.
>>
>> There are two patches to be merged:
>> https://review.openstack.org/#/c/286738/
>> https://review.openstack.org/#/c/286756/
>>
>> I want to request an FFE for these patches.
>>
>> Regards,
>> Grigoriy
>>
>> __
>> OpenStack Development Mailing 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] [sahara] Feature Freeze Exception Request for blueprint

2016-03-10 Thread Chad Roberts
I am +1 for the FFE.  Unlikely to break anything else and it freshens-up a
plugin.

On Thu, Mar 10, 2016 at 8:56 AM, Grigoriy Roghkov 
wrote:

> Hi,
>
> Untill release of MapR 5.1.0 I couldn't have it added to sahara.
> The release happened this day and 5.1.0 still can be add in Mitaka release.
>
> There are two patches to be merged:
> https://review.openstack.org/#/c/286738/
> https://review.openstack.org/#/c/286756/
>
> I want to request an FFE for these patches.
>
> Regards,
> Grigoriy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Thomas Herve
On Thu, Mar 10, 2016 at 2:55 PM, Sean Dague  wrote:
> On 03/10/2016 08:40 AM, Thomas Herve wrote:
>> On Thu, Mar 10, 2016 at 2:28 PM, Chris Dent  wrote:
>>> +many. It would be great if we just got rid of the runnable web
>>> servers in the projects and just expose wsgi apps (the tools like
>>> devstack etc mounted under whatever the available server is).
>>
>> Isn't devstack meant for development? Running the APIs in a WSGI
>> container like Apache or uwsgi makes for a terrible debugging
>> experience. Just this morning I had to prevent aodh from running in
>> Apache to be able to run it standalone.
>>
>> Also, those apps that use WSGI still bind a different port. The fact
>> that it runs in Apache doesn't really solve the URLs problem.
>
> But they shouldn't. I do realize it's taking a while to get there, but
> this is the push to get rid of all these weird ports. The point is to
> get them all on 80 in a subpath or a separate domain.
>
>
> If projects use the pbr wsgi_script directive the wsgi script will run
> on wsgi ref on the commandline if you need that for debug -
> https://github.com/openstack/keystone/blob/4db54810e58ad86edb92869a608fb5630a6b99e5/setup.cfg#L75
> that was built to make this simpler.

Right, but if we move to everything in WSGI besides a subpath, you
won't be able to switch to the script easily. Unless you actually
implement that using a reverse proxy.

I totally understand the will to remove those ports from the final
product. I question whether it's the right choice for devstack. It
would seem that at least keeping those 'weird' ports for internal
consumption would be useful. It's not like we're close to use the 65K
available.

-- 
Thomas

__
OpenStack Development Mailing 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] [docs] [api] Why WADL when you can Swagger

2016-03-10 Thread Sean Dague
Ok, I'm responding very late to this thread because other bits of the
release cycle had attention.

A couple of questions.

1) why are we using the JSON version of the specification instead of the
YAML one -
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#format

One of the reasons this is a bit of a hot button issue for me is beyond
YAML being a bit more readable, it allows *comments* in the file. The
lack of comments support in JSON makes it really problematic to do
anything except completely obvious things that will only ever be
consumed by a computer. Some of these APIs are big, and being able to
provide annotations to API spec developers is really important.

2) What is the tox target I can use to build the HTML out of swagger for
a single project? So that we can iterate here.

3) What is the current best thinking about microversion specification.

This is the #1 current issue with our API reference site, as we've now
got 3 (and soon 4) APIs doing this, but 0 support on the API site to
display this information. If we don't have a near term path forward I
think we're going to just have to dump all the tools and just go to
editing the HTML directly.



On 02/12/2016 04:45 PM, Anne Gentle wrote:
> Hi all,
> I wanted to give an update on the efforts to provide improved
> application developer information on developer.openstack.org
> . Wrangling this much valuable
> information and gathering it in a way that helps people is no simple
> matter. So. We move forward one step at a time.
> 
> What's new?
> 
> This week, with every build of the api-site, we are now running
> fairy-slipper to migrate from WADL to Swagger for API reference
> information. Those migrated Swagger files are then copied to
> developer.openstack.org/draft/swagger
> .
> 
> We know that not all files migrate smoothly. We'd love to get teams
> looking at these migrated files. Thank you to those of you already
> submitting fixes!
> 
> In addition, the infra team is reviewing a spec now so that we can serve
> API reference information from the developer.openstack.org
>  site:
> https://review.openstack.org/#/c/276484/
> 
> Why are we doing all this?
> --
> The overall vision is still intact in the original specifications
> [1][2], however we need to do a lot of web design and front end work to
> get where we want to be.
> 
> What can I do?
> 
> Check out these Swagger files.
> http://developer.openstack.org/draft/swagger/blockstorage-v1-swagger.json
> http://developer.openstack.org/draft/swagger/blockstorage-v2-swagger.json
> http://developer.openstack.org/draft/swagger/clustering-v1-swagger.json
> http://developer.openstack.org/draft/swagger/compute-v2.1-swagger.json
> http://developer.openstack.org/draft/swagger/data-processing-v1.1-swagger.json
> http://developer.openstack.org/draft/swagger/database-v1-swagger.json
> http://developer.openstack.org/draft/swagger/identity-admin-v2-swagger.json
> http://developer.openstack.org/draft/swagger/identity-extensions-v2-swagger.json
> http://developer.openstack.org/draft/swagger/identity-extensions-v3-swagger.json
> http://developer.openstack.org/draft/swagger/identity-v2-swagger.json
> http://developer.openstack.org/draft/swagger/identity-v3-swagger.json
> http://developer.openstack.org/draft/swagger/image-v1-swagger.json
> http://developer.openstack.org/draft/swagger/networking-extensions-v2-swagger.json
> http://developer.openstack.org/draft/swagger/networking-v2-swagger.json
> http://developer.openstack.org/draft/swagger/objectstorage-v1-swagger.json
> http://developer.openstack.org/draft/swagger/orchestration-v1-swagger.json
> http://developer.openstack.org/draft/swagger/share-v1-swagger.json
> http://developer.openstack.org/draft/swagger/telemetry-v2-swagger.json
> 
> If you see a problem in the original WADL, log it here:
> https://bugs.launchpad.net/openstack-api-site. If you see a problem with
> the migration tool, log it here:
> https://bugs.launchpad.net/openstack-doc-tools.
> 
> When will the work be completed?
> 
> 
> I had hoped to have more to show by this point, but I await the infra
> team's review of the server spec above, and we continue to work on the
> bugs in the migration and output. Once the server spec work is complete,
> we can release the draft site.
> 
> What if I have more questions?
> --
> You can always hop onto #openstack-doc or #openstack-sdks to ask me or
> another API working group member for guidance.
> 
> Last but not least, if you want to learn more about Swagger in the
> upstream contributors track at the Summit, vote for this session:
> https://www.openstack.org/summit/austin-2016/vote-for-speakers/presentation/7723
> 
> Thanks,
> Anne
> 
> --
> Anne Gentle
> Rackspace
> 

[openstack-dev] [taas] gate failure fixes

2016-03-10 Thread Takashi Yamamoto
hi,

currently our gate is suffering from multiple issues.
the following steps are necessary to fix them without disabling gate jobs:

1. merge this: https://review.openstack.org/#/c/290946/
2. wait for a fwaas fix being merged: https://review.openstack.org/#/c/290983/
   (or bug 124 fixed in tempest)
3. fold the following two into a single patch and merge it
https://review.openstack.org/#/c/287641/
https://review.openstack.org/#/c/290982/

__
OpenStack Development Mailing 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][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Julien Danjou
On Thu, Mar 10 2016, Thomas Herve wrote:

> Isn't devstack meant for development? Running the APIs in a WSGI
> container like Apache or uwsgi makes for a terrible debugging
> experience. Just this morning I had to prevent aodh from running in
> Apache to be able to run it standalone.

That shouldn't be the case, debugging using Apache shouldn't be much
harder to debug. Could you elaborate on the issues you encountered so we
can possibly improve the situation?

> Also, those apps that use WSGI still bind a different port. The fact
> that it runs in Apache doesn't really solve the URLs problem.

They should not, I know some projects (Keystone at least since I fixed
it, and Gnocchi) are able to run under a prefix on standard ports.

Cheers,
-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


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


Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Sean Dague
On 03/10/2016 08:40 AM, Thomas Herve wrote:
> On Thu, Mar 10, 2016 at 2:28 PM, Chris Dent  wrote:
>> On Thu, 10 Mar 2016, Sean Dague wrote:
>>
>>> These are HTTP services. They really shoudn't be claiming new ports,
>>> they should be running on a real webserver on 80 or 443.
>>>
>>> There is some legacy there with the original services that we are
>>> churning through. It would be nice if new services *started* with
>>> staying on wsgi only, and stopped grabbing random ports.
>>
>>
>> +many. It would be great if we just got rid of the runnable web
>> servers in the projects and just expose wsgi apps (the tools like
>> devstack etc mounted under whatever the available server is).
> 
> Isn't devstack meant for development? Running the APIs in a WSGI
> container like Apache or uwsgi makes for a terrible debugging
> experience. Just this morning I had to prevent aodh from running in
> Apache to be able to run it standalone.
> 
> Also, those apps that use WSGI still bind a different port. The fact
> that it runs in Apache doesn't really solve the URLs problem.

But they shouldn't. I do realize it's taking a while to get there, but
this is the push to get rid of all these weird ports. The point is to
get them all on 80 in a subpath or a separate domain.

If projects use the pbr wsgi_script directive the wsgi script will run
on wsgi ref on the commandline if you need that for debug -
https://github.com/openstack/keystone/blob/4db54810e58ad86edb92869a608fb5630a6b99e5/setup.cfg#L75
that was built to make this simpler.

-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] [sahara] Feature Freeze Exception Request for blueprint

2016-03-10 Thread Grigoriy Roghkov
Hi,

Untill release of MapR 5.1.0 I couldn't have it added to sahara.
The release happened this day and 5.1.0 still can be add in Mitaka release.

There are two patches to be merged:
https://review.openstack.org/#/c/286738/
https://review.openstack.org/#/c/286756/

I want to request an FFE for these patches.

Regards,
Grigoriy
__
OpenStack Development Mailing 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] The #openstack-packaging channel requires an invite?

2016-03-10 Thread Anita Kuno
On 03/09/2016 12:48 PM, Matt Riedemann wrote:
> Someone showed up in the -stable channel this morning asking for help
> with packaging. I gather they were there because the IRC wiki [1] says
> the #openstack-stable channel is also for packaging discussions, given
> -stable originated from distro people.
> 
> I redirected them to https://wiki.openstack.org/wiki/Packaging which
> points to https://wiki.openstack.org/wiki/PackagerResources which says:
> 
> "The #openstack-packaging channel on Freenode is available for packaging
> collaboration and discussion."
> 
> Great!
> 
> However, you have to apparently be invited to join the elite
> #openstack-packaging channel.
> 
> What gives? Is that channel dead? Is there something else? Is there a
> secret handshake I can learn to palms to grease to get in?
> 
> [1] https://wiki.openstack.org/wiki/IRC
> 

So could some of the respondents to this thread add their channel name
and description to the wikipage? https://wiki.openstack.org/wiki/IRC

When this conversation next comes up it is the wikipage I will check and
hope it is up to date. I don't see me trying to find this thread in the
archives.

Thanks,
Anita.

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


Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

2016-03-10 Thread Igor Kalnitsky
Well, what about tomorrow? On SCF we create stable branches and master
is open for next release. You probably will want to run those tests
against Fuel 10, and FPB's master won't have that "10" release in
examples metadata. Because it's something that we usually don't want
to release, and FPB lifecycle is untied from Fuel's.

The only way to avoid that problem is to teach tests to prepare
plugins themselves. They are like test fixtures, it's not very good
that your rely on something that you don't maintain.

On Thu, Mar 10, 2016 at 11:01 AM, Evgeniy L  wrote:
> Mike,
>
> # 2 don't agree, we already generate from templates required information for
> a plugin developer to start development, purpose of plugin examples is
> different, it's used as integration tests for plugins, also QA team uses
> them as Functional tests, they overloaded with tasks and designed to have
> good coverage, so it will only confuse plugin developer.
> # 3 adding real deployment test for fuel-plugins will not help here, since
> change in openstack.yaml caused this problem.
>
> Thanks,
>
> On Thu, Mar 10, 2016 at 10:55 AM, Matthew Mosesohn 
> wrote:
>>
>> Mike,
>>
>> #1 - If you truly agree with that, you should weigh in here:
>> https://review.openstack.org/#/c/287286/
>> #2 - Requires a blueprint and new docs, but okay.
>> #3 - Yes! We have very poor CI for fuel plugin builder. All it does is
>> ensure it makes a plugin, not that it can be installed and deployed.
>>
>> On Thu, Mar 10, 2016 at 10:44 AM, Mike Scherbakov
>>  wrote:
>> > Folks,
>> > here is what I think:
>> > 1) I suggest to fix what is broken now. So that people who come across
>> > examples would not have to deal with issues. We may debate for other few
>> > days (hopefully not more), and all plugin devs will be suffering during
>> > this
>> > time. Also, according to Matt,
>> >
>> >> I should add that this is the only automated daily test that will
>> >> verify
>> > that our plugin framework actually works.
>> > simply means that we must fix it in order to catch any possible
>> > regressions
>> > we may introduce later (if not already).
>> >
>> > 2) I like idea Ilya K. has proposed. To rephrase it (to put extra accent
>> > into it and get feedback), we may not need to have example plugins.
>> > However,
>> > we can have fpb generating template plugin, with commented code in
>> > there. If
>> > you uncomment, you a get a comprehensive example of a working plugin.
>> > To ensure that uncommented code would actually work, we must have a test
>> > for
>> > it (which would uncomment - run - ensure everything deploys).
>> >
>> > 3) Ideally, we need to catch issues at pre-commit stage. So I'd suggest
>> > to
>> > think if there is a way to have tests, which would run such examples
>> > against
>> > pluggable framework for every change to the framework, so that we can
>> > have
>> > -1 right away if something goes wrong.
>> >
>> > I've started separate thread on general thoughts about backward
>> > compatibility and multiple releases support, which actually affects
>> > examples: [1]
>> >
>> > http://lists.openstack.org/pipermail/openstack-dev/2016-March/088921.html
>> >
>> > Thanks,
>> >
>> > On Wed, Mar 9, 2016 at 7:59 AM Evgeniy L  wrote:
>> >>
>> >> Because it doesn't make much sense for a plugin developer to have
>> >> scripts
>> >> to build packages for installation on slave nodes. For default template
>> >> it's
>> >> better to have something minimalistic and the rest of the tasks
>> >> commented,
>> >> otherwise it may create a lot of confusion.
>> >>
>> >> On Wed, Mar 9, 2016 at 6:37 PM, Ilya Kutukov 
>> >> wrote:
>> >>>
>> >>> Talking about templates I mean plugins generated by FBP from the
>> >>> `templates` folder using command you mentioned above.
>> >>>
>> >>> Why not to extend (not replace) template-generated plugins with
>> >>> additional data to provide right coverage?
>> >>>
>> >>> On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L  wrote:
>> 
>>  Ilya,
>> 
>>  What do you mean by "templates" the plugin which is create by just
>>  "fpb
>>  --create plugin-name"?
>>  It doesn't cover enough, package installation and all range of tasks
>>  executions.
>> 
>>  Thanks,
>> 
>>  On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov 
>>  wrote:
>> >
>> > Igor, i completely agree, actually plugin examples is almost a
>> > copy-paste.
>> >
>> > The only thing i see useful in the built plugins example is the
>> > ability
>> > to point some code lines, discussing plugin design and writing
>> > documentation. Why not to generate this examples automatically from
>> > templates?
>> >
>> > Also, as developer and administrator i love to use
>> > examples/templates
>> > where all essential settings and options are persist but commented

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Thomas Herve
On Thu, Mar 10, 2016 at 2:28 PM, Chris Dent  wrote:
> On Thu, 10 Mar 2016, Sean Dague wrote:
>
>> These are HTTP services. They really shoudn't be claiming new ports,
>> they should be running on a real webserver on 80 or 443.
>>
>> There is some legacy there with the original services that we are
>> churning through. It would be nice if new services *started* with
>> staying on wsgi only, and stopped grabbing random ports.
>
>
> +many. It would be great if we just got rid of the runnable web
> servers in the projects and just expose wsgi apps (the tools like
> devstack etc mounted under whatever the available server is).

Isn't devstack meant for development? Running the APIs in a WSGI
container like Apache or uwsgi makes for a terrible debugging
experience. Just this morning I had to prevent aodh from running in
Apache to be able to run it standalone.

Also, those apps that use WSGI still bind a different port. The fact
that it runs in Apache doesn't really solve the URLs problem.

-- 
Thomas

__
OpenStack Development Mailing 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][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Flavio Percoco

On 10/03/16 13:28 +, Chris Dent wrote:

On Thu, 10 Mar 2016, Sean Dague wrote:


These are HTTP services. They really shoudn't be claiming new ports,
they should be running on a real webserver on 80 or 443.

There is some legacy there with the original services that we are
churning through. It would be nice if new services *started* with
staying on wsgi only, and stopped grabbing random ports.


+many. It would be great if we just got rid of the runnable web
servers in the projects and just expose wsgi apps (the tools like
devstack etc mounted under whatever the available server is).


FWIW, Zaqar doesn't ship a wsgi container. It's a pure wsgi app. I think the
issue Fei Long is raising here is w.r.t the gate. From a Zaqar perspective, I
wouldn't be too worried and as far as the gate goes, I think it'd be more than
fine to just switch from using wsgiref in the gate to using httpd.

This is to say, I agree with Chris's and Sean's statements.


Also, as already stated sort of vaguely earlier in the thread, isn't
it the case that if you aren't using the service catalog to find an
endpoint, you're doing it wrong?


++

Flavio

--
@flaper87
Flavio Percoco


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


Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Chris Dent

On Thu, 10 Mar 2016, Sean Dague wrote:


These are HTTP services. They really shoudn't be claiming new ports,
they should be running on a real webserver on 80 or 443.

There is some legacy there with the original services that we are
churning through. It would be nice if new services *started* with
staying on wsgi only, and stopped grabbing random ports.


+many. It would be great if we just got rid of the runnable web
servers in the projects and just expose wsgi apps (the tools like
devstack etc mounted under whatever the available server is).

Also, as already stated sort of vaguely earlier in the thread, isn't
it the case that if you aren't using the service catalog to find an
endpoint, you're doing it wrong?

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing 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] [release][all][ptl] preparing to create stable/mitaka branches for libraries

2016-03-10 Thread gordon chung


On 09/03/2016 12:26 PM, Doug Hellmann wrote:
> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
>
> I will process each repository as I hear from the owning team.
>
> openstack/ceilometermiddleware 0.4.0
> openstack/python-ceilometerclient 2.3.0

- ceilometermiddleware is ready to go
- ceilometerclient requires one last release. 
https://review.openstack.org/#/c/291166/
- aodhclient will probably need it's initial tag for Mitaka as well 
(it's a new client library)

thanks for the support, Doug.

cheers,

-- 
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] [release][all][ptl] preparing to create stable/mitaka branches for libraries

2016-03-10 Thread Doug Hellmann
Excerpts from Qi Ming Teng's message of 2016-03-10 16:09:43 +0800:
> 
> Hi,
> 
> Looks like the python-senlinclient is missing from the list:

The list only included projects with the release:manged tag, but
I'll be happy to take care of other projects if folks want to propose
them here.

Doug

> 
> openstack/python-senlinclient 0.4.0
> 
> 0.4.0 will be its stable branch. Thanks.
> 
> Regards,
>   - Qiming
> 
> 
> 
> From:Doug Hellmann 
> To:openstack-dev 
> Date:2016-03-10 01:32
> Subject:[openstack-dev] [release][all][ptl] preparing to create
> stable/mitaka branches for libraries
> 
> 
> 
> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
> 
> I will process each repository as I hear from the owning team.
> 
> openstack/ceilometermiddleware 0.4.0
> openstack/django_openstack_auth 2.2.0
> openstack/glance_store 0.13.0
> openstack/ironic-lib 1.1.0
> openstack/keystoneauth 2.3.0
> openstack/keystonemiddleware 4.3.0
> openstack/os-brick 1.1.0
> openstack/os-client-config 1.16.0
> openstack/pycadf 2.1.0
> openstack/python-barbicanclient 4.0.0
> openstack/python-brick-cinderclient-ext 0.1.0
> openstack/python-ceilometerclient 2.3.0
> openstack/python-cinderclient 1.6.0
> openstack/cliff 2.0.0
> openstack/python-designateclient 2.0.0
> openstack/python-glanceclient 2.0.0
> openstack/python-heatclient 1.0.0
> openstack/python-ironic-inspector-client 1.5.0
> openstack/python-ironicclient 1.2.0
> openstack/python-keystoneclient 2.3.1
> openstack/python-manilaclient 1.8.0
> openstack/python-neutronclient 4.1.1
> openstack/python-novaclient 3.3.0
> openstack/python-saharaclient 0.13.0
> openstack/python-swiftclient 3.0.0
> openstack/python-troveclient 2.1.0
> openstack/python-zaqarclient 1.0.0
> 

__
OpenStack Development Mailing 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] [release][all][ptl] preparing to create stable/mitaka branches for libraries

2016-03-10 Thread Hayes, Graham
On 09/03/2016 17:29, Doug Hellmann wrote:
> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
>
> I will process each repository as I hear from the owning team.
>
> openstack/python-designateclient 2.0.0

2.0.0 is fine to release for designate.

Thanks,

Graham


__
OpenStack Development Mailing 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] Compatibility of fuel plugins and fuel versions

2016-03-10 Thread Aleksandr Didenko
> Good idea. That should be done despite on any decision we will take.

Currently you have to specify which releases your plugin supports [0]. So I
can take my plugin developed for 8.0 and install it on Fuel-9.0 (I actually
did it and it worked just fine). But I won't be able to enable this plugin
for "mitaka-9.0" release because plugin was not developed and tested for
it, so it does not have "miraka-9.0" in "releases" list [0]. So I don't
quite understand how new "validated_against" parameter will differ from
existing "releases" list.

Regards,
Alex

[0]
https://github.com/openstack/fuel-plugin-external-lb/blob/68fc91a2d3360f19605180d7c3d8683227c8d5b1/metadata.yaml#L11-L21


On Thu, Mar 10, 2016 at 10:22 AM, Bogdan Dobrelya 
wrote:

> On 10.03.2016 08:30, Mike Scherbakov wrote:
> > Hi folks,
> > in order to make a decision whether we need to support example plugins,
> > and if actually need them [1], I'd suggest to discuss more common things
> > about plugins.
> >
> > My thoughts:
> > 1) This is not good, that our plugins created for Fuel 8 won't even
> > install on Fuel 9. By default, we should assume that plugin will work at
> > newer version of Fuel. However, for proper user experience, I suggest to
> > create meta-field "validated_against", where plugin dev would provide
> > versions of Fuel this plugin has been tested with. Let's say, it was
> > tested against 7.0, 8.0. If user installs plugin in Fuel 9, I'd suggest
> > to show a warning saying about risks and the fact that the plugin has
> > not been tested against 9. We should not restrict intsallation against
> > 9, though.
>
> Good idea. That should be done despite on any decision we will take.
>
> >
> > 2) We need to keep backward compatibility of pluggable interface for a
> > few releases. So that plugin developer can use pluggable interface of
> > version x, which was supported in Fuel 6.1. If we still support it, it
> > would mean (see next point) compatibility of this plugin with 6.1, 7.0,
> > 8.0, 9.0. If we want to deprecate pluggable interface version, we should
> > announce it, and basically follow standard process of deprecation.
> >
> > 3) Plugin's ability to work against multiple releases of Fuel
> > (multi-release support). If if..else clauses to support multiple
> > releases are fairly minimal, let's say take less that 10% of LOC, I'd
> > suggest to have this supported. Just because it will be easier for
> > plugin devs to support their plugin code (no code duplication, single
> > repo for multiple releases).
> >
> > Thoughts?
> >
> > [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088211.html
> > --
> > Mike Scherbakov
> > #mihgen
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Sean Dague
On 03/10/2016 07:11 AM, Tim Bell wrote:
> 
> 
> From: Sylvain Bauza >
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>  >
> Date: Thursday 10 March 2016 at 10:04
> To: "OpenStack Development Mailing List (not for usage questions)"
>  >
> Subject: Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list
> 
> 
> 
> Le 09/03/2016 23:41, Matt Fischer a écrit :
>> This is not the first time. Monasca and Murano had a collision
>> too[1]. When this happens the changes trickle down into automation
>> tools also and complicates things.
>>
>> [1] https://bugs.launchpad.net/murano/+bug/1505785
> 
> 
> IMHO, all that info has to be standardized in the Service Catalog.
> That's where endpoint informations can be found for a specific
> service type and that's the basement for cross-project communication.
> 
> FWIW, there is one cross-project spec trying to clean-up the
> per-project bits that are not common
> 
> https://github.com/openstack/openstack-specs/blob/master/specs/service-catalog.rst
> 
> I'm torn between 2 opinions :
>  - either we consider that all those endpoints are (or should be -
> for those which aren't) manageable thru config options, and thus
> that's not a problem we should solve. Any operator can then modify
> the ports to make sure that two conflicting big-tent projects can
> work together.
>  - or, we say that it can be a concern for interoperability, and
> then we should somehow ensure that all projects can work together.
> Then, a documentation link isn't enough IMHO, we should rather test
> that.
> 
> 
> If we can make it so that there are reasonable port commonalities
> between OpenStack clouds, this would be good. Clearly, the service
> catalog is the master so I don’t think there is an interoperability
> concern but having each of the projects using different ports would
> simplify some of the smaller configurations with multiple services on a
> single box. 
> 
> This does assume that there are less big tent projects than available
> TCP/IP ports :-)

These are HTTP services. They really shoudn't be claiming new ports,
they should be running on a real webserver on 80 or 443.

There is some legacy there with the original services that we are
churning through. It would be nice if new services *started* with
staying on wsgi only, and stopped grabbing random ports.

-Sean

-- 
Sean Dague
http://dague.net

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


Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Tim Bell


From: Sylvain Bauza >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday 10 March 2016 at 10:04
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list



Le 09/03/2016 23:41, Matt Fischer a écrit :
This is not the first time. Monasca and Murano had a collision too[1]. When 
this happens the changes trickle down into automation tools also and 
complicates things.

[1] https://bugs.launchpad.net/murano/+bug/1505785


IMHO, all that info has to be standardized in the Service Catalog. That's where 
endpoint informations can be found for a specific service type and that's the 
basement for cross-project communication.

FWIW, there is one cross-project spec trying to clean-up the per-project bits 
that are not common 
https://github.com/openstack/openstack-specs/blob/master/specs/service-catalog.rst

I'm torn between 2 opinions :
 - either we consider that all those endpoints are (or should be - for those 
which aren't) manageable thru config options, and thus that's not a problem we 
should solve. Any operator can then modify the ports to make sure that two 
conflicting big-tent projects can work together.
 - or, we say that it can be a concern for interoperability, and then we should 
somehow ensure that all projects can work together. Then, a documentation link 
isn't enough IMHO, we should rather test that.


If we can make it so that there are reasonable port commonalities between 
OpenStack clouds, this would be good. Clearly, the service catalog is the 
master so I don’t think there is an interoperability concern but having each of 
the projects using different ports would simplify some of the smaller 
configurations with multiple services on a single box.

This does assume that there are less big tent projects than available TCP/IP 
ports :-)

Tim





On Wed, Mar 9, 2016 at 3:30 PM, Xav Paice 
> wrote:
From an ops point of view, this would be extremely helpful information to share 
with various teams around an organization.  Even a simple wiki page would be 
great.

On 10 March 2016 at 10:35, Fei Long Wang 
> wrote:
Hi all,

Yesterday I just found cloudkitty is using the same default port () which 
is used by Zaqar now. So I'm wondering if there is any rule/policy for those 
new services need to be aware. I googled but can't find anything about this. 
The only link I can find is 
http://docs.openstack.org/liberty/config-reference/content/firewalls-default-ports.html.
 So my question is should we document the default ports list on an official 
place given the big tent mode? Thanks.

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


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


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





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

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


Re: [openstack-dev] [neutron][tempest] When to put a test into the smoke suite?

2016-03-10 Thread Sean Dague
On 03/10/2016 04:50 AM, Balázs Gibizer wrote:
> Hi, 
> 
> I tried to find the rules defining which test qualifies to be in the smoke 
> suite of tempest. Is there such a clear definition somewhere?

There isn't a huge formal set of rules. The guidelines though are that
it's short and/or demonstrates a piece of cloud function that if broken
we'd consider the whole cloud to be non functional.

It's used in the gate for grenade testing, so needs to stay at about 5
minutes overall run time when running 4 way.

-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


  1   2   >