Re: [openstack-dev] [neutron] dvr l3_snat
Not sure if you've seen this one too: https://wiki.openstack.org/wiki/Neutron/DVR Hope this helps! Armando On 7 November 2014 01:50, Li Tianqing jaze...@163.com wrote: Oh, thanks, i finally find it. it's all here. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr Thanks a lot. -- Best Li Tianqing At 2014-11-06 20:47:39, Henry henry4...@gmail.com wrote: Have you read previous posts? This topic had been discussed for a while. Sent from my iPad On 2014-11-6, at 下午6:18, Li Tianqing jaze...@163.com wrote: Hello, why we put l3_snat on network node to handle North/South snat, and why don't we put it on compute node? Does it possible to put l3_agent on all compute_node for North/South snat, dnat, and east/west l3 routing? -- Best Li Tianqing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] LeastNetwork scheduling for DHCP
Hi Vivek, We are definitely interested in working on these blueprints collaboratively. We have a working implementation for our blueprint and received few important comments from Armando and addressing them currently. Regards Praveen. From: Narasimhan, Vivekanandan Sent: Thursday, November 06, 2014 9:09 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Beltur, Jayashree; S M, Praveen Kumar; benjamin.grass...@thalesgroup.com; Sourabh Patwardhan (sopatwar) Subject: [Neutron] LeastNetwork scheduling for DHCP Hi Neutron Stackers, There is an interest among vendors to bring Least Networks scheduling for DHCP into Openstack Neutron. Currently there are the following blueprints lying there, all of them trying to address this issue: https://review.openstack.org/111210 https://review.openstack.org/#/c/130912/ https://review.openstack.org/104587 We are trying to pull together all these BPs as one Umbrella BP, on which we can pour volunteers from every side, to clear out this BP itself as initial step. So we would like to collaborate, to plan BP approval for these. Please respond if you are interested. -- Thanks, Vivek ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] dvr l3_snat
Thanks a lot, i really helps after i read times :) 在 2014-11-07 16:08:50，Armando M. arma...@gmail.com 写道： Not sure if you've seen this one too: https://wiki.openstack.org/wiki/Neutron/DVR Hope this helps! Armando On 7 November 2014 01:50, Li Tianqing jaze...@163.com wrote: Oh, thanks, i finally find it. it's all here. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr Thanks a lot. -- Best Li Tianqing At 2014-11-06 20:47:39, Henry henry4...@gmail.com wrote: Have you read previous posts? This topic had been discussed for a while. Sent from my iPad On 2014-11-6, at 下午6:18, Li Tianqing jaze...@163.com wrote: Hello, why we put l3_snat on network node to handle North/South snat, and why don't we put it on compute node? Does it possible to put l3_agent on all compute_node for North/South snat, dnat, and east/west l3 routing? -- Best Li Tianqing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ceilometer] how to specific a language to ceilometer? Dose it supports that?
-- Best Li Tianqing___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Let's fix all neutron bugs! (NOT)
Hi folks, I have been supervising bug list for neutron during the last release cycle, trying to do some housekeeping, prioritizing issues and fixing some of them. As you might see, amount of bugs (even staying in New state) doesn't go down. Bugs appear at quite fast pace, and some of them hang for quite a long time, especially if someone has assigned the bug on himself and then abandoned working on it. One of the other reasons for that is that we lack volunteers willing to fix those bugs. So, If you're willing to help, have some knowledge of neutron and its codebase or you have a lab where you can reproduce (and hence, confirm) the bug and provide more additional debugging info, that would be great! My plan is to get your contact, knowing what part of neutron project you familiar with, and then assign bugs directly to you if I feel that the issue matches your experience. I just want to make bug triaging/fixing process a bit more iterative and efficient, with a help of community. So please reach directly to me and let me know what you are interested/experienced with. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] IPv6 team summit meetup
Hi, guys: Very nice to talk to all of you yesterday. Unfortunately I need to head out to the airport at 1pm, so I won't be able to make it for the lunch. :( Will see you on IRC and keep in touch! Shixiong On Thu, Nov 6, 2014 at 4:18 PM, Xuhan Peng pengxu...@gmail.com wrote: Hey, Since we don't have any slot for ipv6 in summit to meet up, can we have a lunch meetup together tomorrow (11/7 Friday)? We can meet at 12:30 at the meet up place Neuilly lobby of Le Meridien and go to lunch together after that. Xu Han — Sent from Mailbox https://www.dropbox.com/mailbox for iPhone ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] IPv6 team summit meetup
On 11/06/2014 04:18 PM, Xuhan Peng wrote: Hey, Since we don't have any slot for ipv6 in summit to meet up, can we have a lunch meetup together tomorrow (11/7 Friday)? We can meet at 12:30 at the meet up place Neuilly lobby of Le Meridien and go to lunch together after that. I'll be there. -Brian ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] IPv6 team summit meetup
will be there too On 11/7/14, 4:53 AM, Brian Haley brian.ha...@hp.com wrote: On 11/06/2014 04:18 PM, Xuhan Peng wrote: Hey, Since we don't have any slot for ipv6 in summit to meet up, can we have a lunch meetup together tomorrow (11/7 Friday)? We can meet at 12:30 at the meet up place Neuilly lobby of Le Meridien and go to lunch together after that. I'll be there. -Brian ___ 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] [ceilometer] how to specific a language to ceilometer? Dose it supports that?
I find at last you should add use like this ceilometer-api export CEILOMETER_LOCALEDIR=YOUR LOCALE DIR export LANGUAGE=YOUR LANGUAGE -- Best Li Tianqing 在 2014-11-07 17:11:59，Li Tianqing jaze...@163.com 写道： -- Best Li Tianqing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon ode support
Hi Yorik, I was talking with Mark Mcclain a minute ago here at the summit about this. And he told me that now at the start of the cycle looks like a good moment to merge the spec the root wrap daemon bits, so we have a lot of headroom for testing during the next months. We need to upgrade the spec [1] to the new Kilo format. Do you have some time to do it?, I can allocate some time and do it right away. [1] https://review.openstack.org/#/c/93889/ -- Miguel Ángel Ajo Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Thursday, 24 de July de 2014 at 01:42, Miguel Angel Ajo Pelayo wrote: +1 Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Yuriy Taraday [yorik@gmail.com (mailto:yorik@gmail.com)] Received: Thursday, 24 Jul 2014, 0:42 To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org (mailto:openstack-dev@lists.openstack.org)] Subject: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon mode support Hello. I'd like to propose making a spec freeze exception for rootwrap-daemon-mode spec [1]. Its goal is to save agents' execution time by using daemon mode for rootwrap and thus avoiding python interpreter startup time as well as sudo overhead for each call. Preliminary benchmark shows 10x+ speedup of the rootwrap interaction itself. This spec have a number of supporters from Neutron team (Carl and Miguel gave it their +2 and +1) and have all code waiting for review [2], [3], [4]. The only thing that has been blocking its progress is Mark's -2 left when oslo.rootwrap spec hasn't been merged yet. Now that's not the case and code in oslo.rootwrap is steadily getting approved [5]. [1] https://review.openstack.org/93889 [2] https://review.openstack.org/82787 [3] https://review.openstack.org/84667 [4] https://review.openstack.org/107386 [5] https://review.openstack.org/#/q/project:openstack/oslo.rootwrap+topic:bp/rootwrap-daemon-mode,n,z -- Kind regards, Yuriy. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][TripleO] Clear all flows when ovs agent start? why and how avoid?
Hi all, Let me introduce our experiment's result: First we write an patch: https://review.openstack.org/#/c/131791/, and tried to use it in an experiment environment. Bad things happened: 1. Note that this is the old flows (Network node's br-tun, the previous version is about icehouse): cookie=0x0, duration=238379.566s, table=1, n_packets=373521, n_bytes=26981817, idle_age=0, hard_age=65534, priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,21) cookie=0x0, duration=238379.575s, table=1, n_packets=30101, n_bytes=3603857, idle_age=198, hard_age=65534, priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20) cookie=0x0, duration=238379.530s, table=20, n_packets=4957, n_bytes=631543, idle_age=198, hard_age=65534, priority=0 actions=resubmit(,21) If the packet is a broadcast packet, we will resubmit it to table 20, and table 20 will do nothing but resubmit to table 21. the full sequence is: from vxlan ports?: table 0 - table 3 - table 10 (learn flows and insert to table 20) from br-int?: table 0 - table 1 - (table 20) - table 21 In the new version (about to juno), we discard table 1, use table 2 instead: cookie=0x0, duration=142084.354s, table=2, n_packets=175823, n_bytes=12323286, idle_age=0, hard_age=65534, priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,22) cookie=0x0, duration=142084.364s, table=2, n_packets=861601, n_bytes=107499857, idle_age=0, hard_age=65534, priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20) But if haven't remove all old flows, the table 1 will still exists, and it will intercept packets, and try to submit packets to table 21 and 20, which the correct tables are 22 and 20. the full sequence is: from vxlan ports?: table 0 - table 4 - table 10 from br-int?: table 0 - table 2 - (table 20, maybe output then!) - table 22 Let's image we mix these up, because priority is 1 to table 0's flows, so we can't make sure packets will trans to right flow, so some packets may submit to table 21, this is quite beyond the pale! 2. What's more, let's imagine if we both use vxlan and vlan as provider: +-+ | | | namespace | ++ | +---++ || | | | qg-| || namespace | | || || | | ++ || ++ | | || | tap | | | ++ || ++ | | | qr x | || | | ++ | +--+-+ | | | +---+++ | || | +-+++---+ | | +---+ | | +---+ | | | br-int | | | | ovs-br vlan +---+ +--+ br-tun(vxlan)| | | | | | | +---+---+ | | +-+-+ | +---+| | | | | | +-+ | | | | | | | +---+ +--+ | | eth0(ethernet card) | | | | | +-+ since ovs-br's vlan is assigned as x, this will mod to y to br-int, but y is assigned by ovs, not our config, so there may exist more than one mod flow for vlan packet in ovs-br, this will cause vlan_id falsify! And may cause network loop! The above accidents are what happened our experiment, not only my imagine. Please take more caution in design! Please feel free to contact me with this email address and welcome to comments. Damon Wang 2014-11-06 2:59 GMT+08:00 Armando M. arma...@gmail.com: I would be open to making this toggle switch available, however I feel that doing it via static configuration can introduce unnecessary burden to the operator. Perhaps we could explore a way where the agent can figure which state it's supposed to be in based on its reported status? Armando On 5 November 2014 12:09, Salvatore Orlando sorla...@nicira.com wrote: I have no opposition to that, and I will be happy to assist reviewing the code that will enable flow synchronisation (or to say it in an easier way, punctual removal of flows unknown to the l2 agent). In the meanwhile, I hope you won't mind if we go ahead and start making flow reset optional - so that we stop causing downtime upon agent restart. Salvatore On 5 November 2014
Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon ode support
Hello, Miguel. I switched departments recently and unfortunately don't have much free time for community work. Feel free to pick up my change requests and push them if you have time. I'll try to keep track of these changes and give some feedback on them on occasion, but don't wait on me. Thank you for keeping this feature in mind. I'd be glad to see it finally used in Neutron (and any other project). -- Kind regards, Yuriy. On Fri, Nov 7, 2014 at 1:05 PM, Miguel Ángel Ajo majop...@redhat.com wrote: Hi Yorik, I was talking with Mark Mcclain a minute ago here at the summit about this. And he told me that now at the start of the cycle looks like a good moment to merge the spec the root wrap daemon bits, so we have a lot of headroom for testing during the next months. We need to upgrade the spec [1] to the new Kilo format. Do you have some time to do it?, I can allocate some time and do it right away. [1] https://review.openstack.org/#/c/93889/ -- Miguel Ángel Ajo Sent with Sparrow http://www.sparrowmailapp.com/?sig On Thursday, 24 de July de 2014 at 01:42, Miguel Angel Ajo Pelayo wrote: +1 Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Yuriy Taraday [yorik@gmail.com] Received: Thursday, 24 Jul 2014, 0:42 To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org] Subject: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon mode support Hello. I'd like to propose making a spec freeze exception for rootwrap-daemon-mode spec [1]. Its goal is to save agents' execution time by using daemon mode for rootwrap and thus avoiding python interpreter startup time as well as sudo overhead for each call. Preliminary benchmark shows 10x+ speedup of the rootwrap interaction itself. This spec have a number of supporters from Neutron team (Carl and Miguel gave it their +2 and +1) and have all code waiting for review [2], [3], [4]. The only thing that has been blocking its progress is Mark's -2 left when oslo.rootwrap spec hasn't been merged yet. Now that's not the case and code in oslo.rootwrap is steadily getting approved [5]. [1] https://review.openstack.org/93889 [2] https://review.openstack.org/82787 [3] https://review.openstack.org/84667 [4] https://review.openstack.org/107386 [5] https://review.openstack.org/#/q/project:openstack/oslo.rootwrap+topic:bp/rootwrap-daemon-mode,n,z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Let's fix all neutron bugs! (NOT)
Hi Eugene, This is really a good thing and I think I have some time and resource to do it :-) My launchpad profile: https://launchpad.net/~damon-devops Github: https://github.com/MatheMatrix Damon 2014-11-07 17:17 GMT+08:00 Eugene Nikanorov enikano...@mirantis.com: Hi folks, I have been supervising bug list for neutron during the last release cycle, trying to do some housekeeping, prioritizing issues and fixing some of them. As you might see, amount of bugs (even staying in New state) doesn't go down. Bugs appear at quite fast pace, and some of them hang for quite a long time, especially if someone has assigned the bug on himself and then abandoned working on it. One of the other reasons for that is that we lack volunteers willing to fix those bugs. So, If you're willing to help, have some knowledge of neutron and its codebase or you have a lab where you can reproduce (and hence, confirm) the bug and provide more additional debugging info, that would be great! My plan is to get your contact, knowing what part of neutron project you familiar with, and then assign bugs directly to you if I feel that the issue matches your experience. I just want to make bug triaging/fixing process a bit more iterative and efficient, with a help of community. So please reach directly to me and let me know what you are interested/experienced with. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon ode support
Ohh, sad to hear that Yuriy, you were doing an awesome work. I will take some time to re-review the final state of the code and specs, and move it forward. Thank you very much for your contribution. -- Miguel Ángel Ajo Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Friday, 7 de November de 2014 at 11:44, Yuriy Taraday wrote: Hello, Miguel. I switched departments recently and unfortunately don't have much free time for community work. Feel free to pick up my change requests and push them if you have time. I'll try to keep track of these changes and give some feedback on them on occasion, but don't wait on me. Thank you for keeping this feature in mind. I'd be glad to see it finally used in Neutron (and any other project). -- Kind regards, Yuriy. On Fri, Nov 7, 2014 at 1:05 PM, Miguel Ángel Ajo majop...@redhat.com (mailto:majop...@redhat.com) wrote: Hi Yorik, I was talking with Mark Mcclain a minute ago here at the summit about this. And he told me that now at the start of the cycle looks like a good moment to merge the spec the root wrap daemon bits, so we have a lot of headroom for testing during the next months. We need to upgrade the spec [1] to the new Kilo format. Do you have some time to do it?, I can allocate some time and do it right away. [1] https://review.openstack.org/#/c/93889/ -- Miguel Ángel Ajo Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Thursday, 24 de July de 2014 at 01:42, Miguel Angel Ajo Pelayo wrote: +1 Sent from my Android phone using TouchDown (www.nitrodesk.com (http://www.nitrodesk.com)) -Original Message- From: Yuriy Taraday [yorik@gmail.com (mailto:yorik@gmail.com)] Received: Thursday, 24 Jul 2014, 0:42 To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org (mailto:openstack-dev@lists.openstack.org)] Subject: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon mode support Hello. I'd like to propose making a spec freeze exception for rootwrap-daemon-mode spec [1]. Its goal is to save agents' execution time by using daemon mode for rootwrap and thus avoiding python interpreter startup time as well as sudo overhead for each call. Preliminary benchmark shows 10x+ speedup of the rootwrap interaction itself. This spec have a number of supporters from Neutron team (Carl and Miguel gave it their +2 and +1) and have all code waiting for review [2], [3], [4]. The only thing that has been blocking its progress is Mark's -2 left when oslo.rootwrap spec hasn't been merged yet. Now that's not the case and code in oslo.rootwrap is steadily getting approved [5]. [1] https://review.openstack.org/93889 [2] https://review.openstack.org/82787 [3] https://review.openstack.org/84667 [4] https://review.openstack.org/107386 [5] https://review.openstack.org/#/q/project:openstack/oslo.rootwrap+topic:bp/rootwrap-daemon-mode,n,z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Barbican] Nominating Juan Antonio Osorio Robles for barbican-core
+1 for me. On Wed, 2014-11-05 at 15:53 +, Douglas Mendizabal wrote: Hi All, I would like to nominate Juan Antonio Osorio Robles to the barbican-core team. Juan has been consistently giving us very well thought out and constructive reviews for Barbican, python-barbicanclient and barbican-specs. It’s obvious from his reviews that he cares deeply for the quality of the Barbican project, and I think he will be a great addition to the core team. As a reminder to barbican-core members, we use the voting process outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our team. References: http://stackalytics.com/report/contribution/barbican-group/90 Thanks, Douglas Douglas Mendizábal IRC: redrobot PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C ___ 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] [Barbican] Nominating Steve Heyman for barbican-core
+1 for me. On Thu, 2014-11-06 at 11:21 +, John Wood wrote: +1 Thanks, John From: Nathan Reller [rellerrel...@yahoo.com] Sent: Thursday, November 06, 2014 3:35 AM To: Openstack-Dev Subject: Re: [openstack-dev] [Barbican] Nominating Steve Heyman for barbican-core +1 for me -Nate ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [NFV][Telco] Minutes from Telco Working Group Session are now available.
Hi all, This week there was Telco Working Group session on the operators track at OpenStack Summit in Paris. We had some issues with etherpad connectivity during the session but Carol has since uploaded minutes of the session and they are available here: https://etherpad.openstack.org/p/kilo-summit-ops-telco Thanks, Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Neutron] Rootwrap daemon ode support
Yuriy, what’s the status of the rootwrap-daemon implementation on the nova side?, was it merged?, otherwise do you think there could be anyone interested in picking it up? Best regards, -- Miguel Ángel Ajo Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Friday, 7 de November de 2014 at 11:52, Miguel Ángel Ajo wrote: Ohh, sad to hear that Yuriy, you were doing an awesome work. I will take some time to re-review the final state of the code and specs, and move it forward. Thank you very much for your contribution. -- Miguel Ángel Ajo Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Friday, 7 de November de 2014 at 11:44, Yuriy Taraday wrote: Hello, Miguel. I switched departments recently and unfortunately don't have much free time for community work. Feel free to pick up my change requests and push them if you have time. I'll try to keep track of these changes and give some feedback on them on occasion, but don't wait on me. Thank you for keeping this feature in mind. I'd be glad to see it finally used in Neutron (and any other project). -- Kind regards, Yuriy. On Fri, Nov 7, 2014 at 1:05 PM, Miguel Ángel Ajo majop...@redhat.com (mailto:majop...@redhat.com) wrote: Hi Yorik, I was talking with Mark Mcclain a minute ago here at the summit about this. And he told me that now at the start of the cycle looks like a good moment to merge the spec the root wrap daemon bits, so we have a lot of headroom for testing during the next months. We need to upgrade the spec [1] to the new Kilo format. Do you have some time to do it?, I can allocate some time and do it right away. [1] https://review.openstack.org/#/c/93889/ -- Miguel Ángel Ajo Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Thursday, 24 de July de 2014 at 01:42, Miguel Angel Ajo Pelayo wrote: +1 Sent from my Android phone using TouchDown (www.nitrodesk.com (http://www.nitrodesk.com)) -Original Message- From: Yuriy Taraday [yorik@gmail.com (mailto:yorik@gmail.com)] Received: Thursday, 24 Jul 2014, 0:42 To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org (mailto:openstack-dev@lists.openstack.org)] Subject: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon mode support Hello. I'd like to propose making a spec freeze exception for rootwrap-daemon-mode spec [1]. Its goal is to save agents' execution time by using daemon mode for rootwrap and thus avoiding python interpreter startup time as well as sudo overhead for each call. Preliminary benchmark shows 10x+ speedup of the rootwrap interaction itself. This spec have a number of supporters from Neutron team (Carl and Miguel gave it their +2 and +1) and have all code waiting for review [2], [3], [4]. The only thing that has been blocking its progress is Mark's -2 left when oslo.rootwrap spec hasn't been merged yet. Now that's not the case and code in oslo.rootwrap is steadily getting approved [5]. [1] https://review.openstack.org/93889 [2] https://review.openstack.org/82787 [3] https://review.openstack.org/84667 [4] https://review.openstack.org/107386 [5] https://review.openstack.org/#/q/project:openstack/oslo.rootwrap+topic:bp/rootwrap-daemon-mode,n,z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org (mailto: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] [qa] [neutron] local.conf for devstack using neutron on home network
On Thu, 6 Nov 2014, Kyle Mestery wrote: On Thu, Nov 6, 2014 at 1:24 PM, Chris Dent chd...@redhat.com wrote: Using nova-networking I can make this work without issue: ``` [[local|localrc]] HOST_IP=192.168.2.3 FLOATING_RANGE=192.168.2.128/26 ``` What transformation is needed to get similar functionality with neutron? Keep the above in your local.conf, and add the following: Q_PLUGIN=ml2 Q_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch,logger Q_AGENT=openvswitch enable_service q-agt ENABLE_TENANT_TUNNELS=True That will enable GRE tunnels between your hosts using your HOST_IP as the tunnel endpoint. And it should setup floating IPs per the range you have specified as well. Thanks but that doesn't quite get me all the way there. I probably should have been more clear that I'm making a combined controller/compute all-in-one. To that end I needed to add a few more enabled services (q-svc, q-meta, q-dhcp). That got me to a completed run but I had no public network and as far as I could tell the private network was not associated with any interface. I dug around doing a few net-, subnet- and router- creates but seemed to be missing a piece. I raise the pay to virtual scotch. What I hope to have at the end of this process is a nicely commented local.conf that I can post somewhere for people who want a similar thing. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] unable to collect compute.node.cpu.* data
You didn't provide the full name of the meter. Here are results in my system. localadmin@ostest2:~/devstack$ ceilometer sample-list -m compute.node.cpu +-+--+--++--+---+ | Resource ID | Name | Type | Volume | Unit | Timestamp | +-+--+--++--+---+ +-+--+--++--+---+ localadmin@ostest2:~/devstack$ ceilometer sample-list -m compute.node.cpu.idle.time | head +-+++-+--++ | Resource ID | Name | Type | Volume | Unit | Timestamp | +-+++-+--++ | ostest2_ostest2 | compute.node.cpu.idle.time | cumulative | 3.876353234e +16 | ns | 2014-11-07T13:15:06.580099 | | ostest2_ostest2 | compute.node.cpu.idle.time | cumulative | 3.876282715e +16 | ns | 2014-11-07T13:14:06.587392 | | ostest2_ostest2 | compute.node.cpu.idle.time | cumulative | 3.87621264e +16 | ns | 2014-11-07T13:13:06.556272 | | ostest2_ostest2 | compute.node.cpu.idle.time | cumulative | 3.876141325e +16 | ns | 2014-11-07T13:12:05.596962 | | ostest2_ostest2 | compute.node.cpu.idle.time | cumulative | 3.876070965e +16 | ns | 2014-11-07T13:11:05.576771 | | ostest2_ostest2 | compute.node.cpu.idle.time | cumulative | 3.875998092e +16 | ns | 2014-11-07T13:10:03.597978 | | ostest2_ostest2 | compute.node.cpu.idle.time | cumulative | 3.87592522e +16 | ns | 2014-11-07T13:09:01.583991 | Best Regards, Liu, Hang(Henry) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Du Jun dj199...@gmail.com 写于 2014/11/07 15:46:21: From: Du Jun dj199...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2014/11/07 15:50 Subject: Re: [openstack-dev] [ceilometer] unable to collect compute.node.cpu.* data Nothing shows when I type command: vcap@ubuntu:~$ ceilometer sample-list --meter compute.node.cpu +-+--+--++--+---+ | Resource ID | Name | Type | Volume | Unit | Timestamp | +-+--+--++--+---+ +-+--+--++--+---+ So, I guess there is no sample data concerning on compute.node.cpu in the database. I assume the problem is about the pipeline.yaml, the pipeline in my devstack system is: --- sources: - name: meter_source interval: 600 meters: - * sinks: - meter_sink - name: cpu_source interval: 600 meters: - cpu sinks: - cpu_sink - name: disk_source interval: 600 meters: - disk.read.bytes - disk.read.requests - disk.write.bytes - disk.write.requests sinks: - disk_sink - name: network_source interval: 600 meters: - network.incoming.bytes - network.incoming.packets - network.outgoing.bytes - network.outgoing.packets sinks: - network_sink sinks: - name: meter_sink transformers: publishers: - notifier:// - name: cpu_sink transformers: - name: rate_of_change parameters: target: name: cpu_util unit: % type: gauge scale: 100.0 / (10**9 * (resource_metadata.cpu_number or 1)) publishers: - notifier:// - name: disk_sink transformers: - name: rate_of_change parameters: source: map_from: name: disk\\.(read|write)\\.(bytes|requests) unit: (B|request) target: map_to: name: disk.\\1.\\2.rate unit: \\1/s type: gauge publishers: - notifier:// - name: network_sink transformers: - name: rate_of_change parameters: source: map_from: name: network\\.(incoming|outgoing)\\.(bytes| packets) unit: (B|packet) target: map_to: name: network.\\1.\\2.rate unit: \\1/s type: gauge publishers: - notifier:// Can anyone tell me whether it's true? @hangliu, would you please show me your pipeline.yaml, if possible. Thanks! -- Regards, Frank 2014-11-06 22:37 GMT+08:00 Neal, Phil
Re: [openstack-dev] [Neutron] Let's fix all neutron bugs! (NOT)
We've been tagging things that are IPv6 related with ipv6 - and we monitor the following URL. https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6 It has been very useful. Feel free to tag anything that looks IPv6 related as such and I'll triage. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Infra] Infra-manual documentation Sprint, December 1-2
Hi everyone, The OpenStack Infrastructure team will be hosting a virtual sprint in the Freenode IRC channel #openstack-sprint for the Infrastructure User Manual on December 1st starting at 15:00 UTC and going for 48 hours. The goal of this sprint is to work on sections of the infra-manual which are still incomplete, review patches and note any style guidelines that still need to be addressed with the Documentation team (style guideines here: https://wiki.openstack.org/wiki/Documentation/Conventions ) Live version of the current documentation is available here: http://docs.openstack.org/infra/manual/ The documentation itself lives in the openstack-infra/infra-manual respository. http://git.openstack.org/cgit/openstack-infra/infra-manual/tree/ -- Elizabeth Krumbach Joseph || Lyz || pleia2 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Neutron] Rootwrap daemon ode support
It hasn't been started it yet. AFAIR Nova people wanted to see it working in Neutron first (and I asked them too late in Juno cycle), so I tried to push it to Neutron only first. I don't know if anyone is interested in implementing this for Nova but I'll ask around. On Fri, Nov 7, 2014 at 3:35 PM, Miguel Ángel Ajo majop...@redhat.com wrote: Yuriy, what’s the status of the rootwrap-daemon implementation on the nova side?, was it merged?, otherwise do you think there could be anyone interested in picking it up? Best regards, -- Miguel Ángel Ajo Sent with Sparrow http://www.sparrowmailapp.com/?sig On Friday, 7 de November de 2014 at 11:52, Miguel Ángel Ajo wrote: Ohh, sad to hear that Yuriy, you were doing an awesome work. I will take some time to re-review the final state of the code and specs, and move it forward. Thank you very much for your contribution. -- Miguel Ángel Ajo Sent with Sparrow http://www.sparrowmailapp.com/?sig On Friday, 7 de November de 2014 at 11:44, Yuriy Taraday wrote: Hello, Miguel. I switched departments recently and unfortunately don't have much free time for community work. Feel free to pick up my change requests and push them if you have time. I'll try to keep track of these changes and give some feedback on them on occasion, but don't wait on me. Thank you for keeping this feature in mind. I'd be glad to see it finally used in Neutron (and any other project). -- Kind regards, Yuriy. On Fri, Nov 7, 2014 at 1:05 PM, Miguel Ángel Ajo majop...@redhat.com wrote: Hi Yorik, I was talking with Mark Mcclain a minute ago here at the summit about this. And he told me that now at the start of the cycle looks like a good moment to merge the spec the root wrap daemon bits, so we have a lot of headroom for testing during the next months. We need to upgrade the spec [1] to the new Kilo format. Do you have some time to do it?, I can allocate some time and do it right away. [1] https://review.openstack.org/#/c/93889/ -- Miguel Ángel Ajo Sent with Sparrow http://www.sparrowmailapp.com/?sig On Thursday, 24 de July de 2014 at 01:42, Miguel Angel Ajo Pelayo wrote: +1 Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Yuriy Taraday [yorik@gmail.com] Received: Thursday, 24 Jul 2014, 0:42 To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org] Subject: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon mode support Hello. I'd like to propose making a spec freeze exception for rootwrap-daemon-mode spec [1]. Its goal is to save agents' execution time by using daemon mode for rootwrap and thus avoiding python interpreter startup time as well as sudo overhead for each call. Preliminary benchmark shows 10x+ speedup of the rootwrap interaction itself. This spec have a number of supporters from Neutron team (Carl and Miguel gave it their +2 and +1) and have all code waiting for review [2], [3], [4]. The only thing that has been blocking its progress is Mark's -2 left when oslo.rootwrap spec hasn't been merged yet. Now that's not the case and code in oslo.rootwrap is steadily getting approved [5]. [1] https://review.openstack.org/93889 [2] https://review.openstack.org/82787 [3] https://review.openstack.org/84667 [4] https://review.openstack.org/107386 [5] https://review.openstack.org/#/q/project:openstack/oslo.rootwrap+topic:bp/rootwrap-daemon-mode,n,z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kind regards, Yuriy. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OVF/OVA support
Gosha – this is wonderful news. Complements Intel interest. I am in the Glance area .. stopped by a couple of times, the room was available 2 pm onwards. Contact made and can continue via email and IRC. Malini From: Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com] Sent: Friday, November 07, 2014 8:20 AM To: Bhandaru, Malini K Cc: OpenStack Development Mailing List Subject: Re: OVF/OVA support Hi Malini, I am interested in OVa support for applications. Specifically Ova to Heat as this is whay we usually do in Murano project. When is free format session for Glance? Should we add this to session etherpad? Thanks, Gosha On Nov 5, 2014 6:06 PM, Bhandaru, Malini K malini.k.bhand...@intel.commailto:malini.k.bhand...@intel.com wrote: Please join us on Friday in the Glance track – free format session, to discuss supporting OVF/OVA in OpenStack. Poll: 1) How interested are you in this feature? 0 – 10 2) Interested enough to help develop the feature? Artifacts are ready for use. We are considering defining an artifact for OVF/OVA. What should the scope of this work be? Who are our fellow travelers? Intel is interested in parsing OVF meta data associated with images – to ensure that a VM image lands on the most appropriate hardware in the cloud instance, to ensure optimal performance. The goal is to remove the need to manually specify image meta data, allow the appliance provider to specify HW requirements, and in so doing reduce human error. Are any partners interested in writing an OVF/OVA artifact = stack deployment? Along the lines of heat? As a first pass, Intel we could at least 1) Defining artifact for OVA, parsing the OVF in it, pulling out the images therein and storing them in the glance image database and attaching meta data to the same. 2) Do not want to imply that OpenStack supports OVA/OVF -- need to be clear on this. 3) An OpenStack user could create a heat template using the images registered in step -1 4) OVA to Heat – there may be a loss in translation! Should we attempt this? 5) What should we do with multiple volume artifacts? 6) Are volumes read-only? Or on cloning, make copies of them? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] Test runner for python tests and parallel execution
Hi guys, Long time ago i've made patch [1] which added tests distribution between processes and databases. It was simple py.test configuration which allows us to reduce time of test execution almost linearly, on my local machine one test run (distributed over 4 cores) takes 250 seconds. At that time idea of using py.test was discarded, because: 1. it is neither nosetests 2. nor openstack community way (testrepository) There is plugin for nosetests which adds multiprocessing support (maybe it is even included in default distribution) but i wasnt able to find a normal way of distribution over databases, just because runner doesnot include necessery config options like RUNNER_ID. I cant stop you from trying - so please share your results, if you will find a nice and easy way to make it work. As for testrepository - if you have positive experience using this tool, share them, from my point of view it has very bad UX. Please consider trying py.test [2], i bet you will notice difference in reporting, and maybe will use it yourself for day-to-day test executions. Additionally there is very good system for parametrizing tests and writing extensions. The goal of this letter is to solve problem of CI queues for fuel-web project, so please share your opinions, It will be nice to solve this at the start of next week. [1] https://review.openstack.org/#/c/82284/3/nailgun/conftest.py [2] http://pytest.readthedocs.org/en/2.1.0/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] [Infra] Infra-manual documentation Sprint, December 1-2
On 11/07/2014 02:57 PM, Elizabeth K. Joseph wrote: Hi everyone, The OpenStack Infrastructure team will be hosting a virtual sprint in the Freenode IRC channel #openstack-sprint for the Infrastructure User Manual on December 1st starting at 15:00 UTC and going for 48 hours. The goal of this sprint is to work on sections of the infra-manual which are still incomplete, review patches and note any style guidelines that still need to be addressed with the Documentation team (style guideines here: https://wiki.openstack.org/wiki/Documentation/Conventions ) Live version of the current documentation is available here: http://docs.openstack.org/infra/manual/ The documentation itself lives in the openstack-infra/infra-manual respository. http://git.openstack.org/cgit/openstack-infra/infra-manual/tree/ Rainya has created a wikipage for booking the new #openstack-sprint channel: https://wiki.openstack.org/wiki/VirtualSprints I am working on patches to have logging in the channel. Thanks, Anita. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Test runner for python tests and parallel execution
Hi Dmitry, Thank you for bringing it up, it's not only about CI, it really takes a lot of developers time to run Nailgun unit/integration tests on local machine, and it's must have priority task in technical debt scope. Personally I'm ok with py.test, but we should improve db creation mechanism in your patch to use psycopg2 instead of running psql in subprocess. Thanks, On Fri, Nov 7, 2014 at 5:35 PM, Dmitriy Shulyak dshul...@mirantis.com wrote: Hi guys, Long time ago i've made patch [1] which added tests distribution between processes and databases. It was simple py.test configuration which allows us to reduce time of test execution almost linearly, on my local machine one test run (distributed over 4 cores) takes 250 seconds. At that time idea of using py.test was discarded, because: 1. it is neither nosetests 2. nor openstack community way (testrepository) There is plugin for nosetests which adds multiprocessing support (maybe it is even included in default distribution) but i wasnt able to find a normal way of distribution over databases, just because runner doesnot include necessery config options like RUNNER_ID. I cant stop you from trying - so please share your results, if you will find a nice and easy way to make it work. As for testrepository - if you have positive experience using this tool, share them, from my point of view it has very bad UX. Please consider trying py.test [2], i bet you will notice difference in reporting, and maybe will use it yourself for day-to-day test executions. Additionally there is very good system for parametrizing tests and writing extensions. The goal of this letter is to solve problem of CI queues for fuel-web project, so please share your opinions, It will be nice to solve this at the start of next week. [1] https://review.openstack.org/#/c/82284/3/nailgun/conftest.py [2] http://pytest.readthedocs.org/en/2.1.0/ ___ 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] [qa] [neutron] local.conf for devstack using neutron on home network
On Fri, Nov 07, 2014 at 02:16:52PM CET, Chris Dent wrote: What I hope to have at the end of this process is a nicely commented local.conf that I can post somewhere for people who want a similar thing. Yes, and I hope my patchset will accomplish this, I just need to make changes to it based on both your feedback on the review, as well as in-person discussions with Dean Troyer. It is currently adapted from notes for my multi-node lab that contains dual interfaces and provider networking. I am working to address your comments about using a single interface, although some additions may need to be done to DevStack to add the public interface to the bridge and re-assign the IP address, similar to what Nova-Network does. https://review.openstack.org/#/c/131201/ -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] [UX] Curvature interactive virtual network design
As discussed in the Horizon contributor meet up, here at Cisco we’re interested in upstreaming our work on the Curvature dashboard into Horizon. We think that it can solve a lot of issues around guidance for new users and generally improving the experience of interacting with Neutron. Possibly an alternative persona for novice users? For reference, see: 1. http://youtu.be/oFTmHHCn2-g – Video Demo 2. https://www.openstack.org/summit/portland-2013/session-videos/presentation/interactive-visual-orchestration-with-curvature-and-donabe – Portland presentation 3. https://github.com/CiscoSystems/curvature – original (Rails based) code We’d like to gauge interest from the community on whether this is something people want. Thanks, John, Brad Sam ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Test runner for python tests and parallel execution
On Fri, 7 Nov 2014, Dmitriy Shulyak wrote: As for testrepository - if you have positive experience using this tool, share them, from my point of view it has very bad UX. +1, but with the caveat that testr and its compatriots (e.g. subunit) appear to have been optimized for automation of huge test suites and CI contexts. That's a reasonable thing to be but I think focusing on that side of things has been to detriment of the human/developer benefits that happen as a result of writing and running tests. This is something I'd love for us (people who make OpenStack), as a shared culture, to address. Please consider trying py.test [2], i bet you will notice difference in reporting, and maybe will use it yourself for day-to-day test executions. Additionally there is very good system for parametrizing tests and writing extensions. I'm with you on this. I love py.test. The user experience for a human, doing active development, is rather nice indeed. The difficulty, of course, is that there's been a very large investment in tools that rely on a particular form of test discovery that as far as I can tell py.test doesn't want to play with. If we can overcome that problem...disco. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] [neutron] local.conf for devstack using neutron on home network
On Fri, 7 Nov 2014, Collins, Sean wrote: On Fri, Nov 07, 2014 at 02:16:52PM CET, Chris Dent wrote: What I hope to have at the end of this process is a nicely commented local.conf that I can post somewhere for people who want a similar thing. Yes, and I hope my patchset will accomplish this, I just need to make changes to it based on both your feedback on the review, as well as in-person discussions with Dean Troyer. Awesome. Sorry about my tone in those comments. I was in the midst of one the longer efforts to get things working (many edits to lib/neutron, many dives in to `ip netns wtf`) and stumbled upon that review and was initially \o/ and then :(. It is currently adapted from notes for my multi-node lab that contains dual interfaces and provider networking. I am working to address your comments about using a single interface, although some additions may need to be done to DevStack to add the public interface to the bridge and re-assign the IP address, similar to what Nova-Network does. I'll keep track of that review and if there are others that I can test please give me a shout. Thanks. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Test runner for python tests and parallel execution
What changes do you want to see in the ui? On 7 Nov 2014 17:17, Chris Dent chd...@redhat.com wrote: On Fri, 7 Nov 2014, Dmitriy Shulyak wrote: As for testrepository - if you have positive experience using this tool, share them, from my point of view it has very bad UX. +1, but with the caveat that testr and its compatriots (e.g. subunit) appear to have been optimized for automation of huge test suites and CI contexts. That's a reasonable thing to be but I think focusing on that side of things has been to detriment of the human/developer benefits that happen as a result of writing and running tests. This is something I'd love for us (people who make OpenStack), as a shared culture, to address. Please consider trying py.test [2], i bet you will notice difference in reporting, and maybe will use it yourself for day-to-day test executions. Additionally there is very good system for parametrizing tests and writing extensions. I'm with you on this. I love py.test. The user experience for a human, doing active development, is rather nice indeed. The difficulty, of course, is that there's been a very large investment in tools that rely on a particular form of test discovery that as far as I can tell py.test doesn't want to play with. If we can overcome that problem...disco. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent ___ 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] [Barbican][OSSG] Mid Cycle Attendance / Crossover.
Hi All, How many people would want to attend both the OSSG mid-cycle and the Barbican one? Both expected to be on the west coast of the US. We are trying to work out how/if we should organise these events to take place at adjacent times and if they should be in the same location, back to back to reduce travel costs. Cheers -Rob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][lbaas] meeting day/time change
Hi all, Neutron LBaaS meetings are now going to be Tuesdays at 16:00 UTC. Safe travels. Thanks, Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] L2 Gateway discussion
Hi, Why not use already defined multi-segements (or multi-provider-network) API interface, and hide the L2GW explicit manipulation? Best Regards Chaoyi Huang ( joehuang ) From: Sukhdev Kapur [sukhdevka...@gmail.com] Sent: 06 November 2014 19:27 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] L2 Gateway discussion resending with with the correct subject On Thu, Nov 6, 2014 at 12:22 PM, Sukhdev Kapur sukhdevka...@gmail.commailto:sukhdevka...@gmail.com wrote: Folks, After Maruti's lighting talk on L2 Gateway, bunch of people/vendors expressed interest in coming up with an API for this service. The goal is to come up with a basic set of API which can be implemented in Kilo time frame and build upon it over time in the future. Armando, Akihiro, and others present in this small discussion decided to get together tomorrow morning (Friday) in the Pods area (outside Degas Room) at 9:30am. If anybody has any interest in this discussion or can add value to this discussion, this will be a great opportunity to stop by. Thanks Sukhdev ___ 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] [Openstack-security] [Barbican][OSSG] Mid Cycle Attendance / Crossover.
I would like to try to attend both, assuming the Barbican guys will have me ;-) -bryan On Fri, Nov 7, 2014 at 12:02 PM, Clark, Robert Graham robert.cl...@hp.com wrote: Hi All, How many people would want to attend both the OSSG mid-cycle and the Barbican one? Both expected to be on the west coast of the US. We are trying to work out how/if we should organise these events to take place at adjacent times and if they should be in the same location, back to back to reduce travel costs. Cheers -Rob ___ Openstack-security mailing list openstack-secur...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-security] [Barbican][OSSG] Mid Cycle Attendance / Crossover.
+1 attend both -- Malini -Original Message- From: Clark, Robert Graham [mailto:robert.cl...@hp.com] Sent: Friday, November 07, 2014 11:02 AM To: OpenStack List Cc: openstack-secur...@lists.openstack.org Subject: [Openstack-security] [Barbican][OSSG] Mid Cycle Attendance / Crossover. Hi All, How many people would want to attend both the OSSG mid-cycle and the Barbican one? Both expected to be on the west coast of the US. We are trying to work out how/if we should organise these events to take place at adjacent times and if they should be in the same location, back to back to reduce travel costs. Cheers -Rob ___ Openstack-security mailing list openstack-secur...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
