Re: [openstack-dev] [neutron][lbaas] Canceling lbaas meeting 12/16
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
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 mkole...@redhat.com 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 gkot...@vmware.com wrote: On 12/18/14, 2:06 PM, Mike Kolesnik mkole...@redhat.com 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 that the capacity to bind a port to several host is also a prerequisite for a clean solution here. This will be provided by patches to this bug : https://bugs.launchpad.net/neutron/+bug/1367391 This way no matter where the
Re: [openstack-dev] [qa] Fail to launch VM due to maximum number of ports exceeded
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) 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 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-46b3-897d-b301cfa74a1a | vm--cedd9984-79f0-46b3-897d-b301cfa74a1a | ACTIVE | - | Running | private_net30=30.0.0.40; private_net50=50.0.0.31; private_net40=40.0.0.30 | | ec83e53f-556f-4e66-ab85-15a9e1ba9d28 |
Re: [openstack-dev] [qa] Fail to launch VM due to maximum number of ports exceeded
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 tnurlygaya...@mirantis.commailto:tnurlygaya...@mirantis.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [qa] Fail to launch VM due to maximum number of ports exceeded Message-ID: cahcyybnapbhywfvkjxghn7fckg1wp4sdzf8tujqbjj1lgk2...@mail.gmail.commailto: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) dannc...@cisco.commailto: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
[openstack-dev] [qa] host aggregate's availability zone
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
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) dannc...@cisco.com
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
|
| tenant_id
Re: [openstack-dev] [neutron][lbaas] Canceling lbaas meeting 12/16
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
2014-12-19 17:44 GMT+08:00 Alex Xu sou...@gmail.com: 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?
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 y-g...@jp.fujitsu.com ___ 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
2014-12-22 9:21 GMT+08:00 Alex Xu sou...@gmail.com: 2014-12-22 9:01 GMT+08:00 Lingxian Kong anlin.k...@gmail.com: 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
在 2014年12月22日 10:36, Lingxian Kong 写道: 2014-12-22 9:21 GMT+08:00 Alex Xu sou...@gmail.com: 2014-12-22 9:01 GMT+08:00 Lingxian Kong anlin.k...@gmail.com: 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
在 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.reservEli
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) ta...@linux.vnet.ibm.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
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/)_
https://review.openstack.org/#/c/132827/
--
Thanks Eli Qiao(_qia...@cn.ibm.com_
mailto: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 recent call
Re: [openstack-dev] [Mistral] For-each
On 20 Dec 2014, at 03:01, Dmitri Zimine dzim...@stackstorm.com 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
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
On 20 Dec 2014, at 06:54, Dmitri Zimine dzim...@stackstorm.com 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 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)
- Original Message - From: Doug Hellmann d...@doughellmann.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org 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 fla...@redhat.com 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 OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [Heat] How can I write at milestone section of blueprint?
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 sha...@redhat.com 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 y-g...@jp.fujitsu.com ___ 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
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.commailto: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 mbi...@gmail.commailto: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.orgmailto: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
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 vikram.choudh...@huawei.commailto: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.demailto:yuriy.babe...@telekom.de [mailto:yuriy.babe...@telekom.demailto:yuriy.babe...@telekom.de] Sent: 18 December 2014 19:35 To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org; stephen.kf.w...@gmail.commailto: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.commailto: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 mbi...@gmail.commailto: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.orgmailto: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
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 ta...@linux.vnet.ibm.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
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.reservEli 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) ta...@linux.vnet.ibm.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
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
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 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 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 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] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI
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 ramy.asse...@hp.com 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
Change 0x7fe5ec029b50 139585,9 depends on changes []
2014-12-19 12:07:14,683 INFO zuul.Gearman: Launch job
noop-check-communication for change Change 0x7fe5ec029b50 139585,9 with
dependent changes []
2014-12-19 12:07:14,693 INFO zuul.Gearman: Launch job dsvm-tempest-full
for change Change 0x7fe5ec029b50 139585,9 with dependent changes []
2014-12-19 12:07:14,694 ERROR zuul.Gearman: Job gear.Job 0x7fe5ec2e2f10
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 gear.Job 0x7fe5ec2e2f10
handle: None name: build:dsvm-tempest-full unique:
a9199d304d1140a8bf4448dfb1ae42c1 complete, result NOT_REGISTERED
2014-12-19 12:07:14,765 INFO zuul.Gearman: Build gear.Job 0x7fe5ec2e2d10
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 gear.Job 0x7fe5ec2e2d10
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 Change 0x7fe5ec029b50 139585,9, actions: [ActionReporter
zuul.reporter.gerrit.Reporter object at 0x2694a10, {'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 ramy.asse...@hp.com
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
