Re: [openstack-dev] [neutron][lbaas] Canceling lbaas meeting 12/16

[Evgeny Fedoruk]

Hi Doug,
How are you? 
I have a question regarding https://review.openstack.org/#/c/141247/ change set
Extension changes are not part of this change. I also see the whole extension 
mechanism is out of the new repository.
I may be missed something. Are we replacing  the mechanism with something else? 
Or we will add it separately in other change set?

Thanks,
Evg

-Original Message-
From: Doug Wiegley [mailto:do...@a10networks.com] 
Sent: Sunday, December 14, 2014 7:46 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas] Canceling lbaas meeting 12/16

Unless someone has an urgent agenda item, and due to the mid-cycle for Octavia, 
which has a bunch of overlap with the lbaas team, let’s cancel this week. If 
you have post-split lbaas v2 questions, please find me in #openstack-lbaas.

The only announcement was going to be: If you are waiting to re-submit/submit 
lbaasv2 changes for the new repo, please monitor this review, or make your 
change dependent on it:

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


Thanks,
Doug


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

Re: [openstack-dev] Request for comments for a possible solution

[Narasimhan, Vivekanandan]

Hi Mike,

Just one comment [Vivek]

-Original Message-
From: Mike Kolesnik [mailto:mkole...@redhat.com]
Sent: Sunday, December 21, 2014 11:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Robert Kukura
Subject: Re: [openstack-dev] [Neutron][L2Pop][HA Routers] Request for comments 
for a possible solution

Hi Mathieu,

Comments inline

Regards,
Mike

- Original Message -
> Mike,
>
> I'm not even sure that your solution works without being able to bind
> a router HA port to several hosts.
> What's happening currently is that you :
>
> 1.create the router on two l3agent.
> 2. those l3agent trigger the sync_router() on the l3plugin.
> 3. l3plugin.sync_routers() will trigger l2plugin.update_port(host=l3agent).
> 4. ML2 will bind the port to the host mentioned in the last update_port().
>
> From a l2pop perspective, this will result in creating only one tunnel
> to the host lastly specified.
> I can't find any code that forces that only the master router binds
> its router port. So we don't even know if the host which binds the
> router port is hosting the master router or the slave one, and so if
> l2pop is creating the tunnel to the master or to the slave.
>
> Can you confirm that the above sequence is correct? or am I missing
> something?

Are you referring to the alternative solution?

In that case it seems that you're correct so that there would need to be 
awareness of the master router at some level there as well.
I can't say for sure as I've been thinking on the proposed solution with no 
FDBs so there would be some issues with the alternative that need to be ironed 
out.

>
> Without the capacity to bind a port to several hosts, l2pop won't be
> able to create tunnel correctly, that's the reason why I was saying
> that a prerequisite for a smart solution would be to first fix the bug
> :
> https://bugs.launchpad.net/neutron/+bug/1367391
>
> DVR Had the same issue. Their workaround was to create a new
> port_binding tables, that manages the capacity for one DVR port to be
> bound to several host.
> As mentioned in the bug 1367391, this adding a technical debt in ML2,
> which has to be tackle down in priority from my POV.

I agree that this would simplify work but even without this bug fixed we can 
achieve either solution.

We have already knowledge of the agents hosting a router so this is completely 
doable without waiting for fix for bug 1367391.

Also from my understanding the bug 1367391 is targeted at DVR only, not at HA 
router ports.

[Vivek]  Currently yes, but Bob's concept embraces all replicated ports and so 
HA router ports will play into it :)

--
Thanks,

Vivek


>
>
> On Thu, Dec 18, 2014 at 6:28 PM, Mike Kolesnik  wrote:
> > Hi Mathieu,
> >
> > Thanks for the quick reply, some comments inline..
> >
> > Regards,
> > Mike
> >
> > - Original Message -
> >> Hi mike,
> >>
> >> thanks for working on this bug :
> >>
> >> On Thu, Dec 18, 2014 at 1:47 PM, Gary Kotton  wrote:
> >> >
> >> >
> >> > On 12/18/14, 2:06 PM, "Mike Kolesnik"  wrote:
> >> >
> >> >>Hi Neutron community members.
> >> >>
> >> >>I wanted to query the community about a proposal of how to fix HA
> >> >>routers not working with L2Population (bug 1365476[1]).
> >> >>This bug is important to fix especially if we want to have HA
> >> >>routers and DVR routers working together.
> >> >>
> >> >>[1] https://bugs.launchpad.net/neutron/+bug/1365476
> >> >>
> >> >>What's happening now?
> >> >>* HA routers use distributed ports, i.e. the port with the same
> >> >>IP & MAC
> >> >>  details is applied on all nodes where an L3 agent is hosting
> >> >>this router.
> >> >>* Currently, the port details have a binding pointing to an
> >> >>arbitrary node
> >> >>  and this is not updated.
> >> >>* L2pop takes this "potentially stale" information and uses it to
> >> >>create:
> >> >>  1. A tunnel to the node.
> >> >>  2. An FDB entry that directs traffic for that port to that node.
> >> >>  3. If ARP responder is on, ARP requests will not traverse the network.
> >> >>* Problem is, the master router wouldn't necessarily be running
> >> >>on the
> >> >>  reported agent.
> >> >>  This means that traffic would not reach the master node but
> >> >>some arbitrary
> >> >>  node where the router master might be running, but might be in
> >> >>another
> >> >>  state (standby, fail).
> >> >>
> >> >>What is proposed?
> >> >>Basically the idea is not to do L2Pop for HA router ports that
> >> >>reside on the tenant network.
> >> >>Instead, we would create a tunnel to each node hosting the HA
> >> >>router so that the normal learning switch functionality would
> >> >>take care of switching the traffic to the master router.
> >> >
> >> > In Neutron we just ensure that the MAC address is unique per network.
> >> > Could a duplicate MAC address cause problems here?
> >>
> >> gary, AFAIU, from a Neutron POV, there is only one port, which is
> >> the router Port, which is plugged twice. One time per port.
> >> I think 

Re: [openstack-dev] [qa] Fail to launch VM due to maximum number of ports exceeded

[ZZelle]

Hi Danny,


Port quota includes compute ports (for vms) + network ports (for
dhcps/routers).
You seems to have 40 compute ports + 5 networks x 2 (1 port for the dhcp
and 1 port for the router) ==> 50 ports.


Cedric
ZZelle@IRC








On Sun, Dec 21, 2014 at 5:02 AM, Timur Nurlygayanov <
tnurlygaya...@mirantis.com> wrote:

> Hi Danny,
>
> what about the global ports count and quotas?
>
> On Sun, Dec 21, 2014 at 1:32 AM, Danny Choi (dannchoi)  > wrote:
>
>>  Hi,
>>
>>  The default quota for port is 50.
>>
>>  +--++-+
>>
>> localadmin@qa4:~/devstack$ neutron quota-show --tenant-id
>> 1b2e5efaeeeb46f2922849b483f09ec1
>>
>> +-+---+
>>
>> | Field   | Value |
>>
>> +-+---+
>>
>> | floatingip  | 50|
>>
>> | network | 10|
>>
>> | port| 50|< 50
>>
>> | router  | 10|
>>
>> | security_group  | 10|
>>
>> | security_group_rule | 100   |
>>
>> | subnet  | 10|
>>
>> +-+---+
>>
>>   Total number of ports used so far is 40.
>>
>>  localadmin@qa4:~/devstack$ nova list
>>
>>
>> +--+--+++-+---+
>>
>> | ID   | Name
>> | Status | Task State | Power State | Networks
>> |
>>
>>
>> +--+--+++-+---+
>>
>> | 595940bd-3fb1-4ad3-8cc0-29329b464471 | VM-1
>> | ACTIVE | -  | Running | private_net30=30.0.0.44
>> |
>>
>> | 192ce36d-bc76-427a-a374-1f8e8933938f | VM-2
>> | ACTIVE | -  | Running | private_net30=30.0.0.45
>> |
>>
>> | 10ad850e-ed9d-42d9-8743-b8eda4107edc |
>> cirros--10ad850e-ed9d-42d9-8743-b8eda4107edc | ACTIVE | -  |
>> Running | private_net20=20.0.0.38; private=10.0.0.52
>> |
>>
>> | 18209b40-09e7-4718-b04f-40a01a8e5993 |
>> cirros--18209b40-09e7-4718-b04f-40a01a8e5993 | ACTIVE | -  |
>> Running | private_net20=20.0.0.40; private=10.0.0.54
>> |
>>
>> | 1ededa1e-c820-4915-adf2-4be8eedaf012 |
>> cirros--1ededa1e-c820-4915-adf2-4be8eedaf012 | ACTIVE | -  |
>> Running | private_net20=20.0.0.41; private=10.0.0.55
>> |
>>
>> | 3688262e-d00f-4263-91a7-785c40f4ae0f |
>> cirros--3688262e-d00f-4263-91a7-785c40f4ae0f | ACTIVE | -  |
>> Running | private_net20=20.0.0.34; private=10.0.0.49
>> |
>>
>> | 4620663f-e6e0-4af2-84c0-6108279cbbed |
>> cirros--4620663f-e6e0-4af2-84c0-6108279cbbed | ACTIVE | -  |
>> Running | private_net20=20.0.0.37; private=10.0.0.51
>> |
>>
>> | 8f8252a3-fa23-47fc-8b32-7f7328ecfba2 |
>> cirros--8f8252a3-fa23-47fc-8b32-7f7328ecfba2 | ACTIVE | -  |
>> Running | private_net20=20.0.0.39; private=10.0.0.53
>> |
>>
>> | a228f33b-0388-464e-af49-b55af9601f56 |
>> cirros--a228f33b-0388-464e-af49-b55af9601f56 | ACTIVE | -  |
>> Running | private_net20=20.0.0.42; private=10.0.0.56
>> |
>>
>> | def5a255-0c9d-4df0-af02-3944bf5af2db |
>> cirros--def5a255-0c9d-4df0-af02-3944bf5af2db | ACTIVE | -  |
>> Running | private_net20=20.0.0.36; private=10.0.0.50
>> |
>>
>> | e1470813-bf4c-4989-9a11-62da47a5c4b4 |
>> cirros--e1470813-bf4c-4989-9a11-62da47a5c4b4 | ACTIVE | -  |
>> Running | private_net20=20.0.0.33; private=10.0.0.48
>> |
>>
>> | f63390fa-2169-45c0-bb02-e42633a08b8f |
>> cirros--f63390fa-2169-45c0-bb02-e42633a08b8f | ACTIVE | -  |
>> Running | private_net20=20.0.0.35; private=10.0.0.47
>> |
>>
>> | 2c34956d-4bf9-45e5-a9de-84d3095ee719 |
>> vm--2c34956d-4bf9-45e5-a9de-84d3095ee719 | ACTIVE | -  |
>> Running | private_net30=30.0.0.39; private_net50=50.0.0.29;
>> private_net40=40.0.0.29 |
>>
>> | 680c55f5-527b-49e3-847c-7794e1f8e7a8 |
>> vm--680c55f5-527b-49e3-847c-7794e1f8e7a8 | ACTIVE | -  |
>> Running | private_net30=30.0.0.41; private_net50=50.0.0.30;
>> private_net40=40.0.0.31 |
>>
>> | ade4c14b-baf7-4e57-948e-095689f73ce3 |
>> vm--ade4c14b-baf7-4e57-948e-095689f73ce3 | ACTIVE | -  |
>> Running | private_net30=30.0.0.43; private_net50=50.0.0.32;
>> private_net40=40.0.0.33 |
>>
>> | c91e426a-ed68-4659-89f6-df6d1154bb16 |
>> vm--c91e426a-ed68-4659-89f6-df6d1154bb16 | ACTIVE | -  |
>> Running | private_net30=30.0.0.42; private_net50=50.0.0.33;
>> private_net40=40.0.0.32 |
>>
>> | cedd9984-79f0-46b

Re: [openstack-dev] [qa] Fail to launch VM due to maximum number of ports exceeded

[Danny Choi (dannchoi)]

Hi Timur,

When you said the “global” counts, I assumed you refer to the admin tenant.

BTW, I’m launching VMs in the demo tenant.


localadmin@qa4:~/devstack$ keystone --os-tenant-name admin --os-username admin 
tenant-list

+--++-+

|id|name| enabled |

+--++-+

| 84827057a7444354b0bff11566ccb80b |   admin|   True  |

| 5977ba64a5734395a7dc1f8f1dbbac7c |  alt_demo  |   True  |

| 1b2e5efaeeeb46f2922849b483f09ec1 |demo|   True  |

| 7dbe65974f144993ad3fb165ced85a0e | invisible_to_admin |   True  |

| eef9dee7066f4a30be32eaa67f2e40c9 |  service   |   True  |

+--+++

localadmin@qa4:~/devstack$ keystone --os-tenant-name admin --os-username admin 
user-list

+--+--+-+--+

|id|   name   | enabled |email |

+--+--+-+--+

| 9d5fd9947d154a2db396fce177f1f83c |  admin   |   True  |  |

| bf51d29350b04a00aef1e701f1f6bb81 | alt_demo |   True  | alt_d...@example.com |

| 668cf3505aba4e45b965cf2963942df9 |  cinder  |   True  |  |

| 4ddc6d36192c4c34bea3865b4286c90d |   demo   |   True  |   d...@example.com   |

| f37bf45d6d0e4168bb3c18d07dbb39fc |  glance  |   True  |  |

| 20376173b10147b6a2111f976bf4e397 |   heat   |   True  |  |

| cf8bf98325964d04a4a3708e36d5f09d | neutron  |   True  |  |

| fec102e33eb64c9e8866a5bd0f718d37 |   nova   |   True  |  |

+--+--+-+--+

localadmin@qa4:~/devstack$ neutron --os-tenant-name admin --os-username admin 
quota-show --tenant-id 84827057a7444354b0bff11566ccb80b

+-+---+

| Field   | Value |

+-+---+

| floatingip  | 50|

| network | 10|

| port| 50|

| router  | 10|

| security_group  | 10|

| security_group_rule | 100   |

| subnet  | 10|

+-+---+

localadmin@qa4:~/devstack$ nova --os-tenant-name admin --os-username admin 
quota-show --tenant 84827057a7444354b0bff11566ccb80b --user 
9d5fd9947d154a2db396fce177f1f83c

+-+---+

| Quota   | Limit |

+-+---+

| instances   | 10|

| cores   | 20|

| ram | 51200 |

| floating_ips| 10|

| fixed_ips   | -1|

| metadata_items  | 128   |

| injected_files  | 5 |

| injected_file_content_bytes | 10240 |

| injected_file_path_bytes| 255   |

| key_pairs   | 100   |

| security_groups | 10|

| security_group_rules| 20|

| server_groups   | 10|

| server_group_members| 10|

+-+---+

Danny
——

Date: Sun, 21 Dec 2014 07:02:05 +0300
From: Timur Nurlygayanov 
mailto:tnurlygaya...@mirantis.com>>
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [qa] Fail to launch VM due to maximum
number of ports exceeded
Message-ID:
mailto:cahcyybnapbhywfvkjxghn7fckg1wp4sdzf8tujqbjj1lgk2...@mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

Hi Danny,

what about the global ports count and quotas?

On Sun, Dec 21, 2014 at 1:32 AM, Danny Choi (dannchoi) 
mailto:dannc...@cisco.com>>
wrote:

  Hi,

  The default quota for port is 50.

  +--++-+

localadmin@qa4:~/devstack$ neutron quota-show --tenant-id
1b2e5efaeeeb46f2922849b483f09ec1

+-+---+

| Field   | Value |

+-+---+

| floatingip  | 50|

| network | 10|

| port| 50|< 50

| router  | 10|

| security_group  | 10|

| security_group_rule | 100   |

| subnet  | 10|

+-+---+

   Total number of ports used so far is 40.

  localadmin@qa4:~/devstack$ nova list


+--+--+++-+---+

| ID   | Name
 | Status | Task State | Power

[openstack-dev] [qa] host aggregate's availability zone

[Danny Choi (dannchoi)]

Hi,

I have a multi-node setup with 2 compute hosts, qa5 and qa6.

I created 2 host-aggregate, each with its own availability zone, and assigned 
one compute host:


localadmin@qa4:~/devstack$ nova aggregate-details host-aggregate-zone-1

++---+---+---+--+

| Id | Name  | Availability Zone | Hosts | Metadata 
|

++---+---+---+--+

| 9  | host-aggregate-zone-1 | az-1  | 'qa5' | 
'availability_zone=az-1' |

++---+---+---+--+

localadmin@qa4:~/devstack$ nova aggregate-details host-aggregate-zone-2

++---+---+---+--+

| Id | Name  | Availability Zone | Hosts | Metadata 
|

++---+---+---+--+

| 10 | host-aggregate-zone-2 | az-2  | 'qa6' | 
'availability_zone=az-2' |

++---+---+---+—+


My intent is to control at which compute host to launch a VM via the 
host-aggregate’s availability-zone parameter.


To test, for vm-1, I specify --availiability-zone=az-1, and 
--availiability-zone=az-2 for vm-2:


localadmin@qa4:~/devstack$ nova boot --image cirros-0.3.2-x86_64-uec --flavor 1 
--nic net-id=5da9d715-19fd-47c7-9710-e395b5b90442 --availability-zone az-1 vm-1

+--++

| Property | Value  
|

+--++

| OS-DCF:diskConfig| MANUAL 
|

| OS-EXT-AZ:availability_zone  | nova   
|

| OS-EXT-SRV-ATTR:host | -  
|

| OS-EXT-SRV-ATTR:hypervisor_hostname  | -  
|

| OS-EXT-SRV-ATTR:instance_name| instance-0066  
|

| OS-EXT-STS:power_state   | 0  
|

| OS-EXT-STS:task_state| -  
|

| OS-EXT-STS:vm_state  | building   
|

| OS-SRV-USG:launched_at   | -  
|

| OS-SRV-USG:terminated_at | -  
|

| accessIPv4   |
|

| accessIPv6   |
|

| adminPass| kxot3ZBZcBH6   
|

| config_drive |
|

| created  | 2014-12-21T15:59:03Z   
|

| flavor   | m1.tiny (1)
|

| hostId   |
|

| id   | 854acae9-b718-4ea5-bc28-e0bc46378b60   
|

| image| cirros-0.3.2-x86_64-uec 
(61409a53-305c-4022-978b-06e55052875b) |

| key_name | -  
|

| metadata | {} 
|

| name | vm-1   
|

| os-extended-volumes:volumes_attached | [] 
|

| progress | 0  
|

| security_groups  | default
|

| status   | BUILD  
|

| tenant_id| 84827057a7444354b0bff11566ccb80b   
|

| updated  | 2014-12-21T15:59:03Z   
|

| user_id  | 9d5fd9947d154a2db396fce177f1f83c   
   

Re: [openstack-dev] [qa] host aggregate's availability zone

[Joe Cropper]

Did you enable the AvailabilityZoneFilter in nova.conf that the scheduler uses? 
 And enable the FilterScheduler?  These are two common issues related to this.

- Joe

> On Dec 21, 2014, at 10:28 AM, Danny Choi (dannchoi)  
> wrote:
> 
> Hi,
> 
> I have a multi-node setup with 2 compute hosts, qa5 and qa6.
> 
> I created 2 host-aggregate, each with its own availability zone, and assigned 
> one compute host:
> 
> localadmin@qa4:~/devstack$ nova aggregate-details host-aggregate-zone-1
> ++---+---+---+--+
> | Id | Name  | Availability Zone | Hosts | Metadata   
>   |
> ++---+---+---+--+
> | 9  | host-aggregate-zone-1 | az-1  | 'qa5' | 
> 'availability_zone=az-1' |
> ++---+---+---+--+
> localadmin@qa4:~/devstack$ nova aggregate-details host-aggregate-zone-2
> ++---+---+---+--+
> | Id | Name  | Availability Zone | Hosts | Metadata   
>   |
> ++---+---+---+--+
> | 10 | host-aggregate-zone-2 | az-2  | 'qa6' | 
> 'availability_zone=az-2' |
> ++---+---+---+—+
> 
> My intent is to control at which compute host to launch a VM via the 
> host-aggregate’s availability-zone parameter.
> 
> To test, for vm-1, I specify --availiability-zone=az-1, and 
> --availiability-zone=az-2 for vm-2:
> 
> localadmin@qa4:~/devstack$ nova boot --image cirros-0.3.2-x86_64-uec --flavor 
> 1 --nic net-id=5da9d715-19fd-47c7-9710-e395b5b90442 --availability-zone az-1 
> vm-1
> +--++
> | Property | Value
>   |
> +--++
> | OS-DCF:diskConfig| MANUAL   
>   |
> | OS-EXT-AZ:availability_zone  | nova 
>   |
> | OS-EXT-SRV-ATTR:host | -
>   |
> | OS-EXT-SRV-ATTR:hypervisor_hostname  | -
>   |
> | OS-EXT-SRV-ATTR:instance_name| instance-0066
>   |
> | OS-EXT-STS:power_state   | 0
>   |
> | OS-EXT-STS:task_state| -
>   |
> | OS-EXT-STS:vm_state  | building 
>   |
> | OS-SRV-USG:launched_at   | -
>   |
> | OS-SRV-USG:terminated_at | -
>   |
> | accessIPv4   |  
>   |
> | accessIPv6   |  
>   |
> | adminPass| kxot3ZBZcBH6 
>   |
> | config_drive |  
>   |
> | created  | 2014-12-21T15:59:03Z 
>   |
> | flavor   | m1.tiny (1)  
>   |
> | hostId   |  
>   |
> | id   | 854acae9-b718-4ea5-bc28-e0bc46378b60 
>   |
> | image| cirros-0.3.2-x86_64-uec 
> (61409a53-305c-4022-978b-06e55052875b) |
> | key_name | -
>   |
> | metadata | {}   
>   |
> | name | vm-1 
>   |
> | os-extended-volumes:volumes_attached | []   
>   |
> | progress | 0
>   |
> | security_groups  | default  
>   |
> | status   | BUILD 

Re: [openstack-dev] [neutron][lbaas] Canceling lbaas meeting 12/16

[Brandon Logan]

The extensions are remaining in neutron until the Neutron WSGI Refactor
is completed so it's easier for them to test all extensions and that
nothing breaks.  I do believe the plan is to move the extensions into
the service repos once this is completed.

Thanks,
Brandon
On Sun, 2014-12-21 at 10:14 +, Evgeny Fedoruk wrote:
> Hi Doug,
> How are you? 
> I have a question regarding https://review.openstack.org/#/c/141247/ change 
> set
> Extension changes are not part of this change. I also see the whole extension 
> mechanism is out of the new repository.
> I may be missed something. Are we replacing  the mechanism with something 
> else? Or we will add it separately in other change set?
> 
> Thanks,
> Evg
> 
> -Original Message-
> From: Doug Wiegley [mailto:do...@a10networks.com] 
> Sent: Sunday, December 14, 2014 7:46 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [neutron][lbaas] Canceling lbaas meeting 12/16
> 
> Unless someone has an urgent agenda item, and due to the mid-cycle for 
> Octavia, which has a bunch of overlap with the lbaas team, let’s cancel this 
> week. If you have post-split lbaas v2 questions, please find me in 
> #openstack-lbaas.
> 
> The only announcement was going to be: If you are waiting to re-submit/submit 
> lbaasv2 changes for the new repo, please monitor this review, or make your 
> change dependent on it:
> 
> https://review.openstack.org/#/c/141247/
> 
> 
> Thanks,
> Doug
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [nova] Evacuate instance which in server group with affinity policy

[Lingxian Kong]

2014-12-19 17:44 GMT+08:00 Alex Xu :
> Hi,
>
> There is problem when evacuate instance. If the instance is in the server
> group with affinity policy, the instance can't evacuate out the failed
> compute node.
>
> I know there is soft affinity policy under development, but think of if the
> instance in server group with hard affinity means no way to get it back when
> compute node failed, it's really confuse.
>
> I guess there should be some people concern that will violate the affinity
> policy. But I think the compute node already down, all the instance in that
> server group are down also, so I think we needn't care about the policy
> anymore.

but what if the compute node is back to normal? There will be
instances in the same server group with affinity policy, but located
in different hosts.

>
> I wrote up a patch can fix this problem:
> https://review.openstack.org/#/c/135607/
>
>
> We have some discussion on the gerrit (Thanks Sylvain for discuss with me),
> but we still not sure we are on the right direction. So I bring this up at
> here.
>
> Thanks
> Alex
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [Heat] How can I write at milestone section of blueprint?

[Yasunori Goto]

> On Fri, Dec 19, 2014 at 05:02:04PM +0900, Yasunori Goto wrote:
> > 
> > Hello,
> > 
> > This is the first mail at Openstack community,
> 
> Welcome! :)
> 
> > and I have a small question about how to write blueprint for Heat.
> > 
> > Currently our team would like to propose 2 interfaces
> > for users operation in HOT. 
> > (One is "Event handler" which is to notify user's defined event to heat.
> >  Another is definitions of action when heat catches the above notification.)
> > So, I'm preparing the blueprint for it.
> 
> Please include details of the exact use-case, e.g the problem you're trying
> to solve (not just the proposed solution), as it's possible we can suggest
> solutions based on exiting interfaces.


Ok, I'll try.

> > However, I can not find how I can write at the milestone section of 
> > blueprint.
> > 
> > Heat blueprint template has a section for Milestones.
> > "Milestones -- Target Milestone for completeion:"
> > 
> > But I don't think I can decide it by myself.
> > In my understanding, it should be decided by PTL.
> 
> Normally, it's decided by when the person submitting the spec expects to
> finish writing the code by.  The PTL doesn't really have much control over
> that ;)

I see.

> 
> > In addition, probably the above our request will not finish
> > by Kilo. I suppose it will be "L" version or later.
> 
> So to clarify, you want to propose the feature, but you're not planning on
> working on it (e.g implementing it) yourself?

I want to develop it.


> 
> > So, what should I write at this section?
> > "Kilo-x", "L version", or empty?
> 
> As has already been mentioned, it doesn't matter that much - I see it as a
> statement of intent from developers.  If you're just requesting a feature,
> you can even leave it blank if you want and we'll update it when an
> assignee is found (e.g during the spec review).

Thanks for your comment.

I'm very newbie of Openstack world.
To be honest, I don't have confidence when I can finish it.

(Though I have experience Linux kernel development, 
 currently, I feel python/Openstack is more difficult than it for me yet.)

But, anyway, I'll do my best, and I'll write something at Milestone section.

Bye.


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

-- 
Yasunori Goto 



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

Re: [openstack-dev] [nova] Evacuate instance which in server group with affinity policy

[Alex Xu]

2014-12-22 9:01 GMT+08:00 Lingxian Kong :

> 2014-12-19 17:44 GMT+08:00 Alex Xu :
> > Hi,
> >
> > There is problem when evacuate instance. If the instance is in the server
> > group with affinity policy, the instance can't evacuate out the failed
> > compute node.
> >
> > I know there is soft affinity policy under development, but think of if
> the
> > instance in server group with hard affinity means no way to get it back
> when
> > compute node failed, it's really confuse.
> >
> > I guess there should be some people concern that will violate the
> affinity
> > policy. But I think the compute node already down, all the instance in
> that
> > server group are down also, so I think we needn't care about the policy
> > anymore.
>
> but what if the compute node is back to normal? There will be
> instances in the same server group with affinity policy, but located
> in different hosts.
>
>
If operator decide to evacuate the instance from the failed host, we should
fence the failed host first.
So the failed host shoudn't have chance to get back.



> >
> > I wrote up a patch can fix this problem:
> > https://review.openstack.org/#/c/135607/
> >
> >
> > We have some discussion on the gerrit (Thanks Sylvain for discuss with
> me),
> > but we still not sure we are on the right direction. So I bring this up
> at
> > here.
> >
> > Thanks
> > Alex
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Regards!
> ---
> Lingxian Kong
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Evacuate instance which in server group with affinity policy

[Lingxian Kong]

2014-12-22 9:21 GMT+08:00 Alex Xu :
>
>
> 2014-12-22 9:01 GMT+08:00 Lingxian Kong :
>>

>>
>> but what if the compute node is back to normal? There will be
>> instances in the same server group with affinity policy, but located
>> in different hosts.
>>
>
> If operator decide to evacuate the instance from the failed host, we should
> fence the failed host first.

Yes, actually. I mean the recommandation or prerequisite should be
emphasized somewhere, e.g. the Operation Guide, otherwise it'll make
things more confused. But the issue you are working around is indeed a
problem we should solve.

-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [nova] Evacuate instance which in server group with affinity policy

[Joe Cropper]

This is another great example of a use case in which these blueprints [1, 2] 
would be handy.  They didn’t make the clip line for Kilo, but we’ll try again 
for L.  I personally don’t think the scheduler should have “special case” rules 
about when/when not to apply affinity policies, as that could be confusing for 
administrators.  It would be simple to just remove it from the group, thereby 
allowing the administrator to rebuild the VM anywhere s/he wants… and then 
re-add the VM to the group once the environment is operational once again.

[1] https://review.openstack.org/#/c/136487/
[2] https://review.openstack.org/#/c/139272/

- Joe

On Dec 21, 2014, at 8:36 PM, Lingxian Kong  wrote:

> 2014-12-22 9:21 GMT+08:00 Alex Xu :
>> 
>> 
>> 2014-12-22 9:01 GMT+08:00 Lingxian Kong :
>>> 
> 
>>> 
>>> but what if the compute node is back to normal? There will be
>>> instances in the same server group with affinity policy, but located
>>> in different hosts.
>>> 
>> 
>> If operator decide to evacuate the instance from the failed host, we should
>> fence the failed host first.
> 
> Yes, actually. I mean the recommandation or prerequisite should be
> emphasized somewhere, e.g. the Operation Guide, otherwise it'll make
> things more confused. But the issue you are working around is indeed a
> problem we should solve.
> 
> -- 
> Regards!
> ---
> Lingxian Kong
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [nova] Evacuate instance which in server group with affinity policy

[Eli Qiao]

在 2014年12月22日 10:36, Lingxian Kong 写道:

2014-12-22 9:21 GMT+08:00 Alex Xu :


2014-12-22 9:01 GMT+08:00 Lingxian Kong :

but what if the compute node is back to normal? There will be
instances in the same server group with affinity policy, but located
in different hosts.


If operator decide to evacuate the instance from the failed host, we should
fence the failed host first.

Yes, actually. I mean the recommandation or prerequisite should be
emphasized somewhere, e.g. the Operation Guide, otherwise it'll make
things more confused. But the issue you are working around is indeed a
problem we should solve.


hi Alex,
how about ask this in openstack-op mailing list, that will be much help.


--
Thanks,
Eli (Li Yong) Qiao


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

Re: [openstack-dev] [nova][resend with correct subject prefix] ask for usage of quota reserve

[Eli Qiao]

在 2014年12月18日 17:33, Chen CH Ji 写道:


AFAIK, quota will expire in 24 hours

cfg.IntOpt('reservation_expire',
   default=86400,
   help='Number of seconds until a reservation expires'),

Best Regards!


hi Kevin,
but that is not reliable,  user/op can change the default value.
shall we just leave as the quota reservation there can do not 
commit/rollback ?

I don't think there will be much more we can do.



Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian 
District, Beijing 100193, PRC


Inactive hide details for "Eli Qiao(Li Yong Qiao)" ---12/18/2014 
04:34:32 PM---hi all, can anyone tell if we call quotas.reserv"Eli 
Qiao(Li Yong Qiao)" ---12/18/2014 04:34:32 PM---hi all, can anyone 
tell if we call quotas.reserve() but never call


From: "Eli Qiao(Li Yong Qiao)" 
To: "OpenStack Development Mailing List (not for usage questions)" 


Date: 12/18/2014 04:34 PM
Subject: [openstack-dev] [nova][resend with correct subject prefix] 
ask for usage of quota reserve






hi all,
can anyone tell if we call quotas.reserve() but never call 
quotas.commit() or quotas.rollback().

what will happen?

for example:

1. when doing resize, we call quotas.reserve() to reservea a delta
quota.(new_flavor - old_flavor)
2. for some reasons, nova-compute crashed, and not chance to call
quotas.commit() or quotas.rollback() /(called by finish_resize in
nova/compute/manager.py)/
3. next time restart nova-compute server, is the delta quota still
reserved , or do we need any other operation on quotas? 



Thanks in advance
-Eli.

ps: this is related to patch : Handle RESIZE_PREP status when nova 
compute do init_instance(_https://review.openstack.org/#/c/132827/)_ 



--
Thanks Eli Qiao(_qia...@cn.ibm.com_ 
)___

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



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


--
Thanks,
Eli (Li Yong) Qiao

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

[openstack-dev] Reply: [Nova] RemoteError: Remote error: OperationalError (OperationalError) (1048, "Column 'instance_uuid' cannot be null")

[贺鹏]

Hi,
   I met the same problem three days ago. I found that my
controller node has a lower version Nova (Nova 2) while the compute
node has a relative new Nova version (2.1). I updated my controller
node Nova, and the problem got solved.

   I also did some code investigation. It seems that the newer
version code of Nova changes the process of building a new instance in
compute node. Specifically, when the compute node invokes the
instacne.save via rpc, it asks for more update operations in
databases.

  I notice that the varables `updates` in instance.save
(nova/objects/instance.py) has a key named 'numa_topology = None', and
this key leads to this database update error in the old version of
Nova. When I remove this key-value pair in 'updates', I did not see
this error again.

 I did search the bug list but I don't find the corresponding bug,
so I post it there, hope it can help.






---

Hi folks,
when i launch instance use cirros image in the new openstack
environment(juno version & centos7 OS base), the following piece is
error logs from compute node.
anybody meet the same error?









2014-12-12 17:16:52.481 12966 ERROR nova.compute.manager [-]
[instance: 67e215e0-2193-439d-89c4-be8c378df78d] Failed to allocate
network(s)
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] Traceback (most recent call
last):
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] File
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2190,
in _build_resources
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] requested_networks,
security_groups)
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] File
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1683,
in _build_networks_for_instance
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] requested_networks, macs,
security_groups, dhcp_options)
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] File
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1717,
in _allocate_network
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d]
instance.save(expected_task_state=[None])
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] File
"/usr/lib/python2.7/site-packages/nova/objects/base.py", line 189, in
wrapper
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] ctxt, self, fn.__name__, args,
kwargs)
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] File
"/usr/lib/python2.7/site-packages/nova/conductor/rpcapi.py", line 351,
in object_action
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] objmethod=objmethod, args=args,
kwargs=kwargs)
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] File
"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/client.py", line
152, in call
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] retry=self.retry)
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] File
"/usr/lib/python2.7/site-packages/oslo/messaging/transport.py", line
90, in _send
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] timeout=timeout, retry=retry)
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] File
"/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py",
line 408, in send
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] retry=retry)
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] File
"/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py",
line 399, in _send
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] raise result
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] RemoteError: Remote error:
OperationalError (OperationalError) (1048, "Column 'instance_uuid'
cannot be null") 'UPDATE instance_extra SET updated_at=%s,
instance_uuid=%s WHERE instance_extra.id = %s'
(datetime.datetime(2014, 12, 12, 9, 16, 52, 434376), None, 5L)
2014-12-12 17:16:52.481 12966 TRACE nova.compute.manager [instance:
67e215e0-2193-439d-89c4-be8c378df78d] [.u'Traceback (most r

Re: [openstack-dev] [Mistral] For-each

[Renat Akhmerov]

> On 20 Dec 2014, at 03:01, Dmitri Zimine  wrote:
> 
> Another observation on naming consistency - mistral uses dash, like 
> `for-each`. 
> Heat uses _underscores when naming YAML keys. 
> So does TOSCA standard. We should have thought about this earlier but it may 
> be not late to fix it while v2 spec is still forming. 

Dmitri,

We thought about it long ago. 

So my related comments/thoughts:
We didn’t find any strict requirements about using snake case in YAML
as well as in OpenStack
We also didn’t find any technical problems with using “dash case"
One of the reasons to use “dash case” was a suggested style of naming workflow 
variables using snake case. So not to confuse workflow language keywords with 
workflow variables we consciously made this decision.
v2 is still forming but I’ve been totally against of introducing backwards 
incompatible changes into it since the beginning of October since we promised 
not to when we released 0.1 version. All the changes we’re now considering 
should be 100% backwards compatible with all existing syntax. Otherwise, it 
will be not easy to gain trusts from people who use it. Again, all changes must 
be additive within at least one major version of DSL. If we gather enough 
feedback that some of the things need to be changed in a non-backwards 
compatible way then we will probably create v3. Otherwise, why do we need 
versioning at all?

Renat Akhmerov
@ Mirantis Inc.

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

[openstack-dev] #PERSONAL# : Horizon -- CSS and JS Query for Blueprint submission

[Swati Shukla1]

 Hi All,

I have 2 queries -

1) CSS : I have added a new template file. Where should I write its 
corresponding external css? should it be written in a .css file/.scss file? I 
am unaware of the .scss syntax so pls let me know how to proceed.

2) JS : I have included a new html2canvas.js file in my code. While committing 
the code, additional line feeds (carriage returns,etc) also get committed. 
Should I replace it with the .min.js file or is there any other way of 
commiting?

Also, kindly let me know which all files have to go through xstatic?

I am in the middle of a blueprint submission so an early help is appreciated.

Thanks and Regards,
Swati Shukla
Tata Consultancy Services
Mailto: swati.shuk...@tcs.com
Website: http://www.tcs.com

Experience certainty.   IT Services
Business Solutions
Consulting


-
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


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

Re: [openstack-dev] [Mistral] For-each

[Renat Akhmerov]

> On 20 Dec 2014, at 06:54, Dmitri Zimine  wrote:
> 
> I appended some more ideas on making for-each loop more readable / less 
> confusing in the document. 
> 
> It’s not rocking the boat (yet) - all the key agreements done that far, stay 
> so far. It’s refinements. 
> 
> Please take a look, leave comments, +1 / -1 for various ideas, and leave your 
> ideas there, too. 
> 
> https://docs.google.com/document/d/1iw0OgQcU0LV_i3Lnbax9NqAJ397zSYA3PMvl6F_uqm0/edit#heading=h.5hjdjqxsgfle
>  
> 

Dmitri, thanks. Looks like you guys have been really creative around this 
blueprint :)

I left my comments in the document. In essence, I would suggest we stop at the 
following syntax:


1. Short one-line syntax in case we need to iterate through one array.

task1:
for: my_item in $.my_array
action: my_action ….

2. Full syntax in case there are more than one array that we need to iterate 
through.

task1:
for:
my_item1: $.my_array1
my_item2: $.my_array2
...
action: my_action ….


Option 3

task1:
for:
- my_item1 in $.my_array1
- my_item2 in $.my_array2

also looks ok to me but it doesn’t seem a YAML way a little bit because in YAML 
we can express key-value pairs naturally like in #2. 


Actually, I don’t see any problems with supporting all three options.

As far as naming, let’s comment on each of the options we have now:
‘‘for-each’ - I’d be ok with it but seems like lots of people have been 
confused with it so far because their expectation were really different than 
the description we told them, so I’m ok to pick a different name.
“map” - I’m totally against it, first glance at “map” would make very little 
sense to me even though I understand where this option comes from. I’m pretty 
sure it will be even more confusing than “for-each”.
“with_items” -  Ansible style, it’s ok to me.
“for” - I think this is my favourite option so far. Semantically it may not be 
too different than “for-each” but it’s very concise and most general purpose 
languages have the same construct with similar semantics.

After all, my suggestion would be not to spend huge amount of time arguing on 
naming. Although it’s pretty important, it’s always subjective to a great 
extent.


Thanks

Renat Akhmerov
@ Mirantis Inc.

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

Re: [openstack-dev] [all] Lets not assume everyone is using the global `CONF` object (zaqar broken by latest keystoneclient release 1.0)

[Jamie Lennox]

- Original Message -
> From: "Doug Hellmann" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Saturday, 20 December, 2014 12:07:59 AM
> Subject: Re: [openstack-dev] [all] Lets not assume everyone is using the  
> global `CONF` object (zaqar broken by latest
> keystoneclientrelease 1.0)
> 
> 
> On Dec 19, 2014, at 7:17 AM, Flavio Percoco  wrote:
> 
> > Greetings,
> > 
> > DISCLAIMER: The following comments are neither finger pointing the
> > author of this work nor the keystone team.

That was me. 

> > RANT: We should really stop assuming everyone is using a global `CONF`
> > object. Moreover, we should really stop using it, especially in
> > libraries.
> > 
> > That said, here's a gentle note for all of us:
> > 
> > If I understood the flow of changes correctly, keystoneclient recently
> > introduced a auth_section[0] option, which needs to be registered in
> > order for it to work properly. In keystoneclient, it's been correctly
> > added a function[1] to register this option in a conf object.
> > 
> > keystonemiddleware was then updated to support the above and a call to
> > the register function[1] was then added to the `auth_token` module[2].
> > 
> > The above, unfortunately, broke Zaqar's auth because Zaqar is not
> > using the global `CONF` object which means it has to register
> > keystonemiddleware's options itself. Since the option was registered
> > in the global conf instead of the conf object passed to
> > `AuthProtocol`, the new `auth_section` option is not bein registered
> > as keystoneclient excepts.
> > 
> > So, as a gentle reminder to everyone, please, lets not assume all
> > projects are using the global `CONF` object and make sure all libraries
> > provide a good way to register the required options. I think either
> > secretly registering options or exposing a function to let consumers
> > do so is fine.
> > 
> > I hate complaining without helping to solve the problem so, here's[3] a
> > workaround to provide a, hopefully, better way to do this. Note that
> > this shouldn't be the definitive fix and that we also implemented a
> > workaround in zaqar as well.

That will fix the immediate problem - and i assume is fixing the issue that 
oslo.config sample config generator must not be picking up those options if 
it's not there. 
 
> That change will fix the issue, but a better solution is to have the code in
> keystoneclient that wants the options handle the registration at runtime. It
> looks like keystoneclient/auth/conf.py:load_from_conf_options() is at least
> one place that’s needed, there may be others.

So auth_token middleware was never designed to work this way - but we can fix 
it to. The reason AuthProtocol.__init__ takes a conf dict (it's not an 
oslo.config.Cfg object) is to work with options being included via paste file, 
these are expected to be overrides of the global CONF object. Putting these 
options in paste.ini is something the keystone team has been advising against 
for a while now and my understanding from that was that we were close to 
everyone using the global CONF object. 

Do you know if there are any other projects managing CONF this way? I too 
dislike the global CONF, however this is the only time i've seen a project work 
to not use it.

The problem with the proposed solution is that we are moving towards pluggable 
authentication in keystonemiddleware (and the clients). The auth_section option 
is the first called but the important option there is the auth_plugin option 
which specifies what sort of authentication to perform. The options that will 
be read/registered on CONF are then dependent on the plugin specified by 
auth_plugin. Handling this manually from Zaqar and having the correct options 
registered is going to be a pain.

Given that there are users, I'll have a look into making auth_token middleware 
actually accept a CONF object rather than require people to hack things through 
in the override dictionary. 

Jamie



> Doug
> 
> > 
> > Cheers,
> > Flavio
> > 
> > [0]
> > https://github.com/openstack/python-keystoneclient/blob/41afe3c963fa01f61b67c44e572eee34b0972382/keystoneclient/auth/conf.py#L20
> > [1]
> > https://github.com/openstack/python-keystoneclient/blob/41afe3c963fa01f61b67c44e572eee34b0972382/keystoneclient/auth/conf.py#L49
> > [2]
> > https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token.py#L356
> > [3] https://review.openstack.org/143063
> > 
> > --
> > @flaper87
> > Flavio Percoco
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
Open

Re: [openstack-dev] [Heat] How can I write at milestone section of blueprint?

[Yasunori Goto]

Rundal-san,

> There should already be blueprints in launchpad for very similar 
> functionality.
> For example: https://blueprints.launchpad.net/heat/+spec/lifecycle-callbacks.
> While that specifies Heat sending notifications to the outside world,
> there has been discussion around debugging that would allow the receiver to
> send notifications back. I only point this out so you can see there should be
> similar blueprints and specs that you can reference and use as examples.

Thank you for pointing it out.
But do you know current status about it?
Though the above blueprint is not approved, and it seems to be discarded.

Bye,

> 
> On Dec 19, 2014, at 4:17 AM, Steven Hardy 
>  wrote:
> 
> > On Fri, Dec 19, 2014 at 05:02:04PM +0900, Yasunori Goto wrote:
> >> 
> >> Hello,
> >> 
> >> This is the first mail at Openstack community,
> > 
> > Welcome! :)
> > 
> >> and I have a small question about how to write blueprint for Heat.
> >> 
> >> Currently our team would like to propose 2 interfaces
> >> for users operation in HOT. 
> >> (One is "Event handler" which is to notify user's defined event to heat.
> >> Another is definitions of action when heat catches the above notification.)
> >> So, I'm preparing the blueprint for it.
> > 
> > Please include details of the exact use-case, e.g the problem you're trying
> > to solve (not just the proposed solution), as it's possible we can suggest
> > solutions based on exiting interfaces.
> > 
> >> However, I can not find how I can write at the milestone section of 
> >> blueprint.
> >> 
> >> Heat blueprint template has a section for Milestones.
> >> "Milestones -- Target Milestone for completeion:"
> >> 
> >> But I don't think I can decide it by myself.
> >> In my understanding, it should be decided by PTL.
> > 
> > Normally, it's decided by when the person submitting the spec expects to
> > finish writing the code by.  The PTL doesn't really have much control over
> > that ;)
> > 
> >> In addition, probably the above our request will not finish
> >> by Kilo. I suppose it will be "L" version or later.
> > 
> > So to clarify, you want to propose the feature, but you're not planning on
> > working on it (e.g implementing it) yourself?
> > 
> >> So, what should I write at this section?
> >> "Kilo-x", "L version", or empty?
> > 
> > As has already been mentioned, it doesn't matter that much - I see it as a
> > statement of intent from developers.  If you're just requesting a feature,
> > you can even leave it blank if you want and we'll update it when an
> > assignee is found (e.g during the spec review).
> > 
> > Thanks,
> > 
> > Steve
> > 
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Yasunori Goto 



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

[openstack-dev] Our idea for SFC using OpenFlow. RE: [NFV][Telco] Service VM v/s its basic framework

[Vikram Choudhary]

Hi Murali,

We have proposed service function chaining idea using open flow.
https://blueprints.launchpad.net/neutron/+spec/service-function-chaining-using-openflow

Will submit the same for review soon.

Thanks
Vikram

From: yuriy.babe...@telekom.de [mailto:yuriy.babe...@telekom.de]
Sent: 18 December 2014 19:35
To: openstack-dev@lists.openstack.org; stephen.kf.w...@gmail.com
Subject: Re: [openstack-dev] [NFV][Telco] Service VM v/s its basic framework

Hi,
in the IRC meeting yesterday we agreed to work on the use-case for service 
function chaining as it seems to be important for a lot of participants [1].
We will prepare the first draft and share it in the TelcoWG Wiki for discussion.

There is one blueprint in openstack on that in [2]


[1] 
http://eavesdrop.openstack.org/meetings/telcowg/2014/telcowg.2014-12-17-14.01.txt
[2] 
https://blueprints.launchpad.net/group-based-policy/+spec/group-based-policy-service-chaining

Kind regards/Mit freundlichen Grüßen
Yuriy Babenko

Von: A, Keshava [mailto:keshav...@hp.com]
Gesendet: Mittwoch, 10. Dezember 2014 19:06
An: stephen.kf.w...@gmail.com; OpenStack 
Development Mailing List (not for usage questions)
Betreff: Re: [openstack-dev] [NFV][Telco] Service VM v/s its basic framework

Hi Murali,

There are many unknows w.r.t ‘Service-VM’ and how it should from NFV 
perspective.
In my opinion it was not decided how the Service-VM framework should be.
Depending on this we at OpenStack also will have impact for ‘Service Chaining’.
Please find the mail attached w.r.t that discussion with NFV for ‘Service-VM + 
Openstack OVS related discussion”.


Regards,
keshava

From: Stephen Wong [mailto:stephen.kf.w...@gmail.com]
Sent: Wednesday, December 10, 2014 10:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [NFV][Telco] Service VM v/s its basic framework

Hi Murali,

There is already a ServiceVM project (Tacker), currently under development 
on stackforge:

https://wiki.openstack.org/wiki/ServiceVM

If you are interested in this topic, please take a look at the wiki page 
above and see if the project's goals align with yours. If so, you are certainly 
welcome to join the IRC meeting and start to contribute to the project's 
direction and design.

Thanks,
- Stephen


On Wed, Dec 10, 2014 at 7:01 AM, Murali B 
mailto:mbi...@gmail.com>> wrote:
Hi keshava,

We would like contribute towards service chain and NFV

Could you please share the document if you have any related to service VM

The service chain can be achieved if we able to redirect the traffic to service 
VM using ovs-flows

in this case we no need to have routing enable on the service VM(traffic is 
redirected at L2).

All the tenant VM's in cloud could use this service VM services  by adding the 
ovs-rules in OVS


Thanks
-Murali




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

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

Re: [openstack-dev] Our idea for SFC using OpenFlow. RE: [NFV][Telco] Service VM v/s its basic framework

[Vikram Choudhary]

Sorry for the incontinence. We will sort the issue at the earliest.
Please find the BP attached with the mail!!!

From: Murali B [mailto:mbi...@gmail.com]
Sent: 22 December 2014 12:20
To: Vikram Choudhary
Cc: openstack-dev@lists.openstack.org; yuriy.babe...@telekom.de; 
keshav...@hp.com; stephen.kf.w...@gmail.com; Dhruv Dhody; Dongfeng (C); 
Kalyankumar Asangi
Subject: Re: Our idea for SFC using OpenFlow. RE: [openstack-dev] [NFV][Telco] 
Service VM v/s its basic framework

Thank you Vikram,

Could you or somebody please provide the access the full specification document

Thanks
-Murali

On Mon, Dec 22, 2014 at 11:48 AM, Vikram Choudhary 
mailto:vikram.choudh...@huawei.com>> wrote:
Hi Murali,

We have proposed service function chaining idea using open flow.
https://blueprints.launchpad.net/neutron/+spec/service-function-chaining-using-openflow

Will submit the same for review soon.

Thanks
Vikram

From: yuriy.babe...@telekom.de 
[mailto:yuriy.babe...@telekom.de]
Sent: 18 December 2014 19:35
To: 
openstack-dev@lists.openstack.org; 
stephen.kf.w...@gmail.com
Subject: Re: [openstack-dev] [NFV][Telco] Service VM v/s its basic framework

Hi,
in the IRC meeting yesterday we agreed to work on the use-case for service 
function chaining as it seems to be important for a lot of participants [1].
We will prepare the first draft and share it in the TelcoWG Wiki for discussion.

There is one blueprint in openstack on that in [2]


[1] 
http://eavesdrop.openstack.org/meetings/telcowg/2014/telcowg.2014-12-17-14.01.txt
[2] 
https://blueprints.launchpad.net/group-based-policy/+spec/group-based-policy-service-chaining

Kind regards/Mit freundlichen Grüßen
Yuriy Babenko

Von: A, Keshava [mailto:keshav...@hp.com]
Gesendet: Mittwoch, 10. Dezember 2014 19:06
An: stephen.kf.w...@gmail.com; OpenStack 
Development Mailing List (not for usage questions)
Betreff: Re: [openstack-dev] [NFV][Telco] Service VM v/s its basic framework

Hi Murali,

There are many unknows w.r.t ‘Service-VM’ and how it should from NFV 
perspective.
In my opinion it was not decided how the Service-VM framework should be.
Depending on this we at OpenStack also will have impact for ‘Service Chaining’.
Please find the mail attached w.r.t that discussion with NFV for ‘Service-VM + 
Openstack OVS related discussion”.


Regards,
keshava

From: Stephen Wong [mailto:stephen.kf.w...@gmail.com]
Sent: Wednesday, December 10, 2014 10:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [NFV][Telco] Service VM v/s its basic framework

Hi Murali,

There is already a ServiceVM project (Tacker), currently under development 
on stackforge:

https://wiki.openstack.org/wiki/ServiceVM

If you are interested in this topic, please take a look at the wiki page 
above and see if the project's goals align with yours. If so, you are certainly 
welcome to join the IRC meeting and start to contribute to the project's 
direction and design.

Thanks,
- Stephen


On Wed, Dec 10, 2014 at 7:01 AM, Murali B 
mailto:mbi...@gmail.com>> wrote:
Hi keshava,

We would like contribute towards service chain and NFV

Could you please share the document if you have any related to service VM

The service chain can be achieved if we able to redirect the traffic to service 
VM using ovs-flows

in this case we no need to have routing enable on the service VM(traffic is 
redirected at L2).

All the tenant VM's in cloud could use this service VM services  by adding the 
ovs-rules in OVS


Thanks
-Murali




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



service-function-chaining-using-openflow.rst
Description: service-function-chaining-using-openflow.rst
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][resend with correct subject prefix] ask for usage of quota reserve

[Chen CH Ji]

I used to submit a patch and retrieve the reservation of quota, got a -2
because it can expire :)

so, I guess expire do no harm unless the uncommitted / unrollbacked
reservation may occupy the quota
and lead to side effect on upcoming actions...

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Eli Qiao 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   12/22/2014 11:37 AM
Subject:Re: [openstack-dev] [nova][resend with correct subject prefix]
ask for usage of quota reserve




在 2014年12月18日 17:33, Chen CH Ji 写道:


  AFAIK, quota will expire in 24 hours

  cfg.IntOpt('reservation_expire',
                 default=86400,
                 help='Number of seconds until a reservation expires'),

  Best Regards!


hi Kevin,
but that is not reliable,  user/op can change the default value.
shall we just leave as the quota reservation there can do not
commit/rollback ?
I don't think there will be much more we can do.



  Kevin (Chen) Ji 纪 晨

  Engineer, zVM Development, CSTL
  Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
  Phone: +86-10-82454158
  Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
  District, Beijing 100193, PRC

  Inactive hide details for "Eli Qiao(Li Yong
  Qiao)"
  ---12/18/2014 04:34:32 PM---hi all, can anyone
  tell if we
  call quotas.reserv"Eli Qiao(Li Yong Qiao)" ---12/18/2014 04:34:32
  PM---hi all, can anyone tell if we call quotas.reserve() but never
  call

  From: "Eli Qiao(Li Yong Qiao)" 
  To: "OpenStack Development Mailing List (not for usage questions)"
  
  Date: 12/18/2014 04:34 PM
  Subject: [openstack-dev] [nova][resend with correct subject prefix]
  ask for usage of quota reserve





  hi all,
  can anyone tell if we call quotas.reserve() but never call
  quotas.commit() or quotas.rollback().
  what will happen?

  for example:
1. when doing resize, we call quotas.reserve() to reservea a
delta quota.(new_flavor - old_flavor)
2. for some reasons, nova-compute crashed, and not chance to
call quotas.commit() or quotas.rollback() (called by
finish_resize in nova/compute/manager.py)
3. next time restart nova-compute server, is the delta quota
still reserved , or do we need any other operation on quotas?

  Thanks in advance
  -Eli.


  ps: this is related to patch : Handle RESIZE_PREP status when nova
  compute do init_instance(https://review.openstack.org/#/c/132827/)


  --
  Thanks Eli Qiao(qia...@cn.ibm.com)
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev






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


--
Thanks,
Eli (Li Yong) Qiao___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Our idea for SFC using OpenFlow. RE: [NFV][Telco] Service VM v/s its basic framework

[Murali B]

Thank you Vikram,

Could you or somebody please provide the access the full specification
document

Thanks
-Murali

On Mon, Dec 22, 2014 at 11:48 AM, Vikram Choudhary <
vikram.choudh...@huawei.com> wrote:
>
>  Hi Murali,
>
>
>
> We have proposed service function chaining idea using open flow.
>
>
> https://blueprints.launchpad.net/neutron/+spec/service-function-chaining-using-openflow
>
>
>
> Will submit the same for review soon.
>
>
>
> Thanks
>
> Vikram
>
>
>
> *From:* yuriy.babe...@telekom.de [mailto:yuriy.babe...@telekom.de]
> *Sent:* 18 December 2014 19:35
> *To:* openstack-dev@lists.openstack.org; stephen.kf.w...@gmail.com
> *Subject:* Re: [openstack-dev] [NFV][Telco] Service VM v/s its basic
> framework
>
>
>
> Hi,
>
> in the IRC meeting yesterday we agreed to work on the use-case for service
> function chaining as it seems to be important for a lot of participants
> [1].
>
> We will prepare the first draft and share it in the TelcoWG Wiki for
> discussion.
>
> There is one blueprint in openstack on that in [2]
>
>
>
> [1]
> http://eavesdrop.openstack.org/meetings/telcowg/2014/telcowg.2014-12-17-14.01.txt
>
> [2]
> https://blueprints.launchpad.net/group-based-policy/+spec/group-based-policy-service-chaining
>
>
>
> Kind regards/Mit freundlichen Grüßen
>
> Yuriy Babenko
>
>
>
> *Von:* A, Keshava [mailto:keshav...@hp.com ]
> *Gesendet:* Mittwoch, 10. Dezember 2014 19:06
> *An:* stephen.kf.w...@gmail.com; OpenStack Development Mailing List (not
> for usage questions)
> *Betreff:* Re: [openstack-dev] [NFV][Telco] Service VM v/s its basic
> framework
>
>
>
> Hi Murali,
>
>
>
> There are many unknows w.r.t ‘Service-VM’ and how it should from NFV
> perspective.
> In my opinion it was not decided how the Service-VM framework should be.
>
> Depending on this we at OpenStack also will have impact for ‘Service
> Chaining’.
>
> *Please find the mail attached w.r.t that discussion with NFV for
> ‘Service-VM + Openstack OVS related discussion”.*
>
>
>
>
>
> Regards,
>
> keshava
>
>
>
> *From:* Stephen Wong [mailto:stephen.kf.w...@gmail.com
> ]
> *Sent:* Wednesday, December 10, 2014 10:03 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [NFV][Telco] Service VM v/s its basic
> framework
>
>
>
> Hi Murali,
>
>
>
> There is already a ServiceVM project (Tacker), currently under
> development on stackforge:
>
>
>
> https://wiki.openstack.org/wiki/ServiceVM
>
>
>
> If you are interested in this topic, please take a look at the wiki
> page above and see if the project's goals align with yours. If so, you are
> certainly welcome to join the IRC meeting and start to contribute to the
> project's direction and design.
>
>
>
> Thanks,
>
> - Stephen
>
>
>
>
>
> On Wed, Dec 10, 2014 at 7:01 AM, Murali B  wrote:
>
>  Hi keshava,
>
>
>
> We would like contribute towards service chain and NFV
>
>
>
> Could you please share the document if you have any related to service VM
>
>
>
> The service chain can be achieved if we able to redirect the traffic to
> service VM using ovs-flows
>
>
>
> in this case we no need to have routing enable on the service VM(traffic
> is redirected at L2).
>
>
>
> All the tenant VM's in cloud could use this service VM services  by adding
> the ovs-rules in OVS
>
>
>
>
>
> Thanks
>
> -Murali
>
>
>
>
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

[Eduard Matei]

Thanks Ramy,

Unfortunately i don't see dsvm-tempest-full in the "status" output.
Any idea how i can get it "registered"?

Thanks,
Eduard

On Fri, Dec 19, 2014 at 9:43 PM, Asselin, Ramy  wrote:
>
>  Eduard,
>
>
>
> If you run this command, you can see which jobs are registered:
>
> >telnet localhost 4730
>
>
>
> >status
>
>
>
> There are 3 numbers per job: queued, running and workers that can run job.
> Make sure the job is listed & last ‘workers’ is non-zero.
>
>
>
> To run the job again without submitting a patch set, leave a “recheck”
> comment on the patch & make sure your zuul layout.yaml is configured to
> trigger off that comment. For example [1].
>
> Be sure to use the sandbox repository. [2]
>
> I’m not aware of other ways.
>
>
>
> Ramy
>
>
>
> [1]
> https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L20
>
> [2] https://github.com/openstack-dev/sandbox
>
>
>
>
>
>
>
>
>
> *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
> *Sent:* Friday, December 19, 2014 3:36 AM
> *To:* Asselin, Ramy
> *Cc:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help
> setting up CI
>
>
>
> Hi all,
>
> After a little struggle with the config scripts i managed to get a working
> setup that is able to process openstack-dev/sandbox and run
> noop-check-comunication.
>
>
>
> Then, i tried enabling dsvm-tempest-full job but it keeps returning
> "NOT_REGISTERED"
>
>
>
> 2014-12-19 12:07:14,683 INFO zuul.IndependentPipelineManager: Change
>  depends on changes []
>
> 2014-12-19 12:07:14,683 INFO zuul.Gearman: Launch job
> noop-check-communication for change  with
> dependent changes []
>
> 2014-12-19 12:07:14,693 INFO zuul.Gearman: Launch job dsvm-tempest-full
> for change  with dependent changes []
>
> 2014-12-19 12:07:14,694 ERROR zuul.Gearman: Job  handle: None name: build:dsvm-tempest-full unique:
> a9199d304d1140a8bf4448dfb1ae42c1> is not registered with Gearman
>
> 2014-12-19 12:07:14,694 INFO zuul.Gearman: Build  handle: None name: build:dsvm-tempest-full unique:
> a9199d304d1140a8bf4448dfb1ae42c1> complete, result NOT_REGISTERED
>
> 2014-12-19 12:07:14,765 INFO zuul.Gearman: Build  handle: H:127.0.0.1:2 name: build:noop-check-communication unique:
> 333c6ea077324a788e3c37a313d872c5> started
>
> 2014-12-19 12:07:14,910 INFO zuul.Gearman: Build  handle: H:127.0.0.1:2 name: build:noop-check-communication unique:
> 333c6ea077324a788e3c37a313d872c5> complete, result SUCCESS
>
> 2014-12-19 12:07:14,916 INFO zuul.IndependentPipelineManager: Reporting
> change , actions: [ , {'verified': -1}>]
>
>
>
> Nodepoold's log show no reference to dsvm-tempest-full and neither
> jenkins' logs.
>
>
>
> Any idea how to enable this job?
>
>
>
> Also, i got the "Cloud provider" setup and i can access it from the
> jenkins master.
>
> Any idea how i can manually trigger dsvm-tempest-full job to run and test
> the cloud provider without having to push a review to Gerrit?
>
>
>
> Thanks,
>
> Eduard
>
>
>
> On Thu, Dec 18, 2014 at 7:52 PM, Eduard Matei <
> eduard.ma...@cloudfounders.com> wrote:
>
>  Thanks for the input.
>
>
>
> I managed to get another master working (on Ubuntu 13.10), again with some
> issues since it was already setup.
>
> I'm now working towards setting up the slave.
>
>
>
> Will add comments to those reviews.
>
>
>
> Thanks,
>
> Eduard
>
>
>
> On Thu, Dec 18, 2014 at 7:42 PM, Asselin, Ramy 
> wrote:
>
>  Yes, Ubuntu 12.04 is tested as mentioned in the readme [1]. Note that
> the referenced script is just a wrapper that pulls all the latest from
> various locations in openstack-infra, e.g. [2].
>
> Ubuntu 14.04 support is WIP [3]
>
> FYI, there’s a spec to get an in-tree 3rd party ci solution [4]. Please
> add your comments if this interests you.
>
>
>
> [1] https://github.com/rasselin/os-ext-testing/blob/master/README.md
>
> [2]
> https://github.com/rasselin/os-ext-testing/blob/master/puppet/install_master.sh#L29
>
> [3] https://review.openstack.org/#/c/141518/
>
> [4] https://review.openstack.org/#/c/139745/
>
>
>
>
>
> *From:* Punith S [mailto:punit...@cloudbyte.com]
> *Sent:* Thursday, December 18, 2014 3:12 AM
> *To:* OpenStack Development Mailing List (not for usage questions);
> Eduard Matei
>
>
> *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help
> setting up CI
>
>
>
> Hi Eduard
>
>
>
> we tried running
> https://raw.githubusercontent.com/rasselin/os-ext-testing/master/puppet/install_master.sh
>
> on ubuntu master 12.04, and it appears to be working fine on 12.04.
>
>
>
> thanks
>
>
>
> On Thu, Dec 18, 2014 at 1:57 PM, Eduard Matei <
> eduard.ma...@cloudfounders.com> wrote:
>
>  Hi,
>
> Seems i can't install using puppet on the jenkins master using
> install_master.sh from
> https://raw.githubusercontent.com/rasselin/os-ext-testing/master/puppet/install_master.sh
> because it's running Ubuntu 11.10 and it appears unsupported.
>
> I managed to install puppet manually on m