Re: [openstack-dev] [Heat] New function: first_nonnull
On 06/11/2014 8:32 AM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Lee, Alexis's message of 2014-11-05 15:46:43 +0100:
I'm considering adding a function which takes a list and returns the
first
non-null, non-empty value in that list.
So you could do EG:
some_thing:
config:
ControlVIP:
first_nonnull:
- {get_param: ControlVIP}
- {get_attr: [ControlVirtualIP, fixed_ips, 0,
ip_address]}]}
I'm open to other names, EG some, or, fallback_list etc.
Steve Hardy suggested building this into get_attr or Fn::Select. My
feeling
is that those each do one job well right now, I'm happy to take a steer
though.
What do you think please?
Yes this is super useful for writing responsive, reusable templates.
I'd like to suggest that this be called 'coalesce' as that is what SQL
calls it.
Although I have no clue why they called it that (colalesce mean join/merge
not get first non-null). I'd rather it be called what it does
first_nonnull() seems more obvious to me. We could also try the
conditional as Zane suggested.
-Angus
___
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] [Fuel] Test runner for python tests and parallel execution
On Sat, 8 Nov 2014, Robert Collins wrote: What changes do you want to see in the ui? I don't want to hijack the thread too much so I hope Dmitriy will join back in but for me there are two aspects of the existing experience that don't work out well. I suspect many of these situations can be resolved with more info (that is, the bug is in my ignorance, not in the software). * Lack of transparency on how to manage verbosity and output handling during a test run. Obviously the output during an unobserved run is going to need to be different from what I as a devloper want while doing an observed run. In the latter case I want to know, while it is happening, which tests have been discovered, which one is happening right now, and a sense of the status of the current assert. I want, at my option, to spew stderr and stdout directly without interference so I can do unhygenic debugging. Essentially, I want to be able to discover the flags, arguments and toosl that allow me to use tests as an ad hoc development aid, not post hoc. I know this is possible with the existing tools, it's just not easy nor easy (for me) to discover. * The current testing code and tools are, to use that lovely saw, hard to reason about. Which for me equates to hard to read. This is perhaps because I'm not particular wed to _unit_ tests, _unittest_ formed tests, or concepts such as test isolation and hates mocks. I see the value of these things but I think it is easy for them to be overused and make other purposes more difficult. I threw this[1] up on the list a little while, which is related: Same complaints and a hope that we won't have the same over-emphasis when we move to in tree testing. Summary: I think we need to spend some time and thought on improving the usefulness of tests, testing and testing tools for someone working on a feature or a bug _right now_. That is: tests run by humans should be as frictionless as possible so that bugs are caught[2] and fixed before test suites are ever run by robots. [1] https://tank.peermore.com/tanks/cdent-rhat/SummitFunctionalTesting [2] And with luck will help create more effective and usable code[3]. [3] Yes, I believe in TDD. -- 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] [Horizon] [UX] Curvature interactive virtual network design
On Fri, 7 Nov 2014, John Davidge (jodavidg) wrote: We’d like to gauge interest from the community on whether this is something people want. When I go to the existing network topology maps in horizon I frequently find myself wanting to drag stuff around. So +1 from me. -- 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 Sat, 8 Nov 2014, Kashyap Chamarthy wrote: [I realize you intend to use physical machine for DevStack, still I thought I'd post this here.] Thanks for posting it. Each added datapoint will get us closer. FWIW, this[1] is the minimal localrc contents (be sure to edit That's minimal? :) Once the stack.sh is complete, I do some tasks Neutron expects: - Create a new private network - Create a new private subnet (on the above private network) - Create a router - Associate the router to an existing external network by setting it as its gateway - Associate the private network interface to the router - Add Neutron security group rules for ICMP and SSH For devstack to live up to the dev in its name the above steps are something I would expect devstack to do for me, assuming I set the right varables and enabled the right services in local.conf. -- 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 Sun, Nov 09, 2014 at 02:48:49PM +, Chris Dent wrote: On Sat, 8 Nov 2014, Kashyap Chamarthy wrote: [I realize you intend to use physical machine for DevStack, still I thought I'd post this here.] Thanks for posting it. Each added datapoint will get us closer. FWIW, this[1] is the minimal localrc contents (be sure to edit That's minimal? :) Hmm, apart from Cinder service in the said config, rest of them all noted there are essential to get a minimal, functional DevStack -- at-least in my testing. Cinder isn't normally part of my test environment (maybe I should add it), but I was investigating a bug in that case, so if you don't prefer it, you can elide these: c-api,c-bak,c-sch,c-vol. That said, I should have defined what I consider minimal, broadly: Nova (libvirt/KVM driver with nested virt), Neutron (OVS+GRE or VXLAN), Keystone (with PKI), Glance. Once the stack.sh is complete, I do some tasks Neutron expects: - Create a new private network - Create a new private subnet (on the above private network) - Create a router - Associate the router to an existing external network by setting it as its gateway - Associate the private network interface to the router - Add Neutron security group rules for ICMP and SSH For devstack to live up to the dev in its name the above steps are something I would expect devstack to do for me, assuming I set the right varables and enabled the right services in local.conf. -- /kashyap ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] [UX] Curvature interactive virtual network design
+1 from me Also, can you get Cisco to opensource Avos? It was demo'd at Atlanta On Sun, Nov 9, 2014 at 6:45 AM, Chris Dent chd...@redhat.com wrote: On Fri, 7 Nov 2014, John Davidge (jodavidg) wrote: We’d like to gauge interest from the community on whether this is something people want. When I go to the existing network topology maps in horizon I frequently find myself wanting to drag stuff around. So +1 from me. -- 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 -- BR, Stuart ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] New function: first_nonnull
Excerpts from Angus Salkeld's message of 2014-11-09 00:15:42 -0800:
On 06/11/2014 8:32 AM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Lee, Alexis's message of 2014-11-05 15:46:43 +0100:
I'm considering adding a function which takes a list and returns the
first
non-null, non-empty value in that list.
So you could do EG:
some_thing:
config:
ControlVIP:
first_nonnull:
- {get_param: ControlVIP}
- {get_attr: [ControlVirtualIP, fixed_ips, 0,
ip_address]}]}
I'm open to other names, EG some, or, fallback_list etc.
Steve Hardy suggested building this into get_attr or Fn::Select. My
feeling
is that those each do one job well right now, I'm happy to take a steer
though.
What do you think please?
Yes this is super useful for writing responsive, reusable templates.
I'd like to suggest that this be called 'coalesce' as that is what SQL
calls it.
Although I have no clue why they called it that (colalesce mean join/merge
not get first non-null). I'd rather it be called what it does
first_nonnull() seems more obvious to me. We could also try the
conditional as Zane suggested.
I believe it is called that because it is meant to coalesce a list of
variables in descending priority into one, which is precisely the use
case presented.
That said, first_nonnull is fine too if that nuance is not as obvious to
others as it is to me. :-P
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] New function: first_nonnull
Excerpts from Zane Bitter's message of 2014-11-06 15:35:09 -0800:
On 06/11/14 20:44, Steven Hardy wrote:
On Wed, Nov 05, 2014 at 02:46:43PM +, Lee, Alexis wrote:
I'm considering adding a function which takes a list and returns the
first
non-null, non-empty value in that list.
So you could do EG:
some_thing:
config:
ControlVIP:
first_nonnull:
- {get_param: ControlVIP}
- {get_attr: [ControlVirtualIP, fixed_ips, 0,
ip_address]}]}
I'm open to other names, EG some, or, fallback_list etc.
Steve Hardy suggested building this into get_attr or Fn::Select. My
feeling is that those each do one job well right now, I'm happy to
take a steer though.
Ah, from our IRC discussion I was thinking you wanted primarily list
filtering of get_attr output, thus thinking an optional argument would make
more sense than a new function.
I see now that you're actually looking for something of a poor-mans
conditional, so you choose either the ControlVIP parameter, or the
ControlVirtualIP attribute, for which your proposal is probably cleaner -
my concern is just that we avoid a proliferation of different list
select/filter functions, when we could just have one.
Crazy thought: why not just implement conditionals? We had a proto-spec
for them started at one point...
The coalesce/first_nonnull is just a shortcut for a common conditional
problem. I'd agree that conditionals are useful as well, but they might
be better served by more time to bake than this more narrow case.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On 7 Nov 2014 16:57, Ian Wienand iwien...@redhat.com wrote: On 10/29/2014 12:42 AM, Doug Hellmann wrote: Another way to do this, which has been used in some other projects, is to define one option for a list of “names” of things, and use those names to make groups with each field I've proposed that in [1]. I look forward to some -1's :) OTOH, oslo.config is not the only way we have to support configuration. This looks like a good example of settings that are more complex than what oslo.config is meant to handle, and that might be better served in a separate file with the location of that file specified in an oslo.config option. My personal opinion is that yet-another-config-file in possibly yet-another-format is just a few lines of code, but has a pretty high cost for packagers, testers, admins, etc. So I feel like that's probably a last-resort. Mangling hardware data into an obtuse format is harder than it needs to be. Dropping a new file in /etc is very ready for a deployer. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] [UX] Curvature interactive virtual network design
Another +1 for me and 2 preliminary questions Router visualisation will work also with Neutron DVR ? Any change to handle also network services ? (i.e. LBaaS) Thanks regards Stefano On Sun, Nov 9, 2014 at 5:39 PM, Stuart Fox stu...@demonware.net wrote: +1 from me Also, can you get Cisco to opensource Avos? It was demo'd at Atlanta On Sun, Nov 9, 2014 at 6:45 AM, Chris Dent chd...@redhat.com wrote: On Fri, 7 Nov 2014, John Davidge (jodavidg) wrote: We’d like to gauge interest from the community on whether this is something people want. When I go to the existing network topology maps in horizon I frequently find myself wanting to drag stuff around. So +1 from me. -- 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 -- BR, Stuart ___ 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] Let's fix all neutron bugs! (NOT)
- Original Message - 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. There is one potential downside with this workflow. When a bug is assigned to someone, it will discourage anyone else from looking at it. You may end up with a lot of bugs assigned that are not actively being worked on. An alternative approach would be to just subscribe developers you think may be willing and interested to take a look. That way they'll get a notification email about it, but it won't discourage anyone else from working on it that may want to in the meantime. -- Russell Bryant ___ 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 Bryant, There is one potential downside with this workflow. When a bug is assigned to someone, it will discourage anyone else from looking at it. You may end up with a lot of bugs assigned that are not actively being worked on. Can't agree more An alternative approach would be to just subscribe developers you think may be willing and interested to take a look. That way they'll get a notification email about it, but it won't discourage anyone else from working on it that may want to in the meantime. Good Way! Damon 2014-11-10 9:47 GMT+08:00 Russell Bryant rbry...@redhat.com: - Original Message - 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. There is one potential downside with this workflow. When a bug is assigned to someone, it will discourage anyone else from looking at it. You may end up with a lot of bugs assigned that are not actively being worked on. An alternative approach would be to just subscribe developers you think may be willing and interested to take a look. That way they'll get a notification email about it, but it won't discourage anyone else from working on it that may want to in the meantime. -- Russell Bryant ___ 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] [neutron][advanced services] Weekly IRC meeting day/time change
Hi All, Following up from the discussions during the Kilo Summit, we will be resuming the Advanced Services' meetings [1]. The new day/time will be Tuesday 17.00 UTC on #openstack-meeting-4 to follow the LBaaS meeting [2]. Hope you can join. Thanks, ~Sumit. [1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices [2] http://lists.openstack.org/pipermail/openstack-dev/2014-November/050005.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][advanced services] Weekly IRC meeting day/time change
I use Event time announcer to create a event to convenient people in different time zone: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Neutron+Advanced+Servicesiso=2014T17p1=1440 Hope helps Damon 2014-11-10 12:14 GMT+08:00 Sumit Naiksatam sumitnaiksa...@gmail.com: Hi All, Following up from the discussions during the Kilo Summit, we will be resuming the Advanced Services' meetings [1]. The new day/time will be Tuesday 17.00 UTC on #openstack-meeting-4 to follow the LBaaS meeting [2]. Hope you can join. Thanks, ~Sumit. [1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices [2] http://lists.openstack.org/pipermail/openstack-dev/2014-November/050005.html ___ 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] [Manila] File-storage for Manila service image
Is this image made available from some other location? I'm not able to download it from the dropbox? Date: Tue, 5 Aug 2014 21:11:36 + From: Swartzlander, Ben ben.swartzlan...@netapp.com To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Manila] File-storage for Manila service image Message-ID: 1407273103.3455.4.camel@bswartz-u904 Content-Type: text/plain; charset=utf-8 On Tue, 2014-08-05 at 23:50 +0300, Valeriy Ponomaryov wrote: Github has file size limit in 100 Mb, see https://help.github.com/articles/what-is-my-disk-quota Our current image is about 300 Mb. Do you think we could upload the file to launchpad somehow? I've seen LP hosting various downloadable files. If that fails maybe the openstack-infra team has a place for blobs. Worst case we will just host in on S3 and pay for it out of our pockets. On Tue, Aug 5, 2014 at 11:43 PM, Swartzlander, Ben ben.swartzlan...@netapp.com wrote: On Tue, 2014-08-05 at 23:13 +0300, Valeriy Ponomaryov wrote: Hello everyone, Currently used image for Manila is located in dropbox: ubuntu_1204_nfs_cifs.qcow2 and dropbox has limit for traffic, see https://www.dropbox.com/help/4204 Due to generation of excessive traffic, public links were banned and image could not be downloaded with error code 509, now it is unbanned, until another excess reached. Traffic limit should not threat possibility to use project, so we need find stable file storage with permanent public links and without traffic limit. Does anyone have any suggestions for more suitable file storage to use? Let's try creating a github repo and sharing it there. For hopefully obvious reasons, let's NOT put this into the manila repos directly -- let's keep it separate. -- Kind Regards Valeriy Ponomaryov ___ 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 -- Kind Regards Valeriy Ponomaryov ___ 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 End of OpenStack-dev Digest, Vol 28, Issue 11 * ___ 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
+1. I think this is an important feature and I'd be happy to do reviews when needed - hopefully this can get in by Kilo! :) On 11/08/2014 12:24 PM, Armando M. wrote: Hi Miguel, Thanks for picking this up. Pull me in and I'd be happy to help! Cheers, Armando On 7 November 2014 10:05, 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 -- 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 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 ___ 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)
On 07/11/14 11:17, Eugene Nikanorov wrote: 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, Hi Eugene, I started looking into various bugs a couple weeks before summit as a way to learn more about the codebase - I can continue to do this into this cycle and am happy to try anything, thanks! marios 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
[OpenStack-Infra] Proposal: bold/italics in style guides
On Friday, a few folks from infra team sat together and discussed the
style guide for the infra-manual (see
https://etherpad.openstack.org/p/kilo-infra-manual ) as a followup to
reviewing : https://review.openstack.org/#/c/107303/ and
https://review.openstack.org/#/c/107360/ . I took the action item to
cover the problems as an enhancement to our style guide.
Looking up the IBM style guide, I didn't found any explicit mentioning
of this - so wrote up the following myself:
==
For documentation, we use semantic markup and let the toolchain format
the text in a consistent and appropriate way. Thus, every occurence of
a term, like a variable, should use the same markup. The writing
should be clear and markup consistent and thus a reader should easily
know why a certain term is using a specific markup like boldface or
italics. Explicit use of bold or italics is in general wrong.
==
Please tell me whether it's accurate and specific enough for this case,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [OpenStack-docs] Proposal: bold/italics in style guides
On Sun, Nov 9, 2014 at 9:16 AM, Andreas Jaeger a...@suse.com wrote:
On Friday, a few folks from infra team sat together and discussed the
style guide for the infra-manual (see
https://etherpad.openstack.org/p/kilo-infra-manual ) as a followup to
reviewing : https://review.openstack.org/#/c/107303/ and
https://review.openstack.org/#/c/107360/ . I took the action item to
cover the problems as an enhancement to our style guide.
Looking up the IBM style guide, I didn't found any explicit mentioning
of this - so wrote up the following myself:
==
For documentation, we use semantic markup and let the toolchain format
the text in a consistent and appropriate way. Thus, every occurence of
a term, like a variable, should use the same markup. The writing
should be clear and markup consistent and thus a reader should easily
know why a certain term is using a specific markup like boldface or
italics. Explicit use of bold or italics is in general wrong.
While it's currently considered wrong for our current toolchain, how do
people using RST do mark up semantically?
==
Please tell me whether it's accurate and specific enough for this case,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
___
OpenStack-docs mailing list
openstack-d...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [OpenStack-docs] Proposal: bold/italics in style guides
On Sun, Nov 9, 2014 at 1:56 PM, Anne Gentle a...@openstack.org wrote:
On Sun, Nov 9, 2014 at 9:16 AM, Andreas Jaeger a...@suse.com wrote:
On Friday, a few folks from infra team sat together and discussed the
style guide for the infra-manual (see
https://etherpad.openstack.org/p/kilo-infra-manual ) as a followup to
reviewing : https://review.openstack.org/#/c/107303/ and
https://review.openstack.org/#/c/107360/ . I took the action item to
cover the problems as an enhancement to our style guide.
Looking up the IBM style guide, I didn't found any explicit mentioning
of this - so wrote up the following myself:
==
For documentation, we use semantic markup and let the toolchain format
the text in a consistent and appropriate way. Thus, every occurence of
a term, like a variable, should use the same markup. The writing
should be clear and markup consistent and thus a reader should easily
know why a certain term is using a specific markup like boldface or
italics. Explicit use of bold or italics is in general wrong.
While it's currently considered wrong for our current toolchain, how do
people using RST do mark up semantically?
Sorry, found it:
http://sphinx-doc.org/markup/inline.html#other-semantic-markup
==
Please tell me whether it's accurate and specific enough for this case,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
___
OpenStack-docs mailing list
openstack-d...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [OpenStack-docs] Proposal: bold/italics in style guides
On 11/09/2014 08:57 PM, Anne Gentle wrote:
On Sun, Nov 9, 2014 at 1:56 PM, Anne Gentle a...@openstack.org
mailto:a...@openstack.org wrote:
On Sun, Nov 9, 2014 at 9:16 AM, Andreas Jaeger a...@suse.com
mailto:a...@suse.com wrote:
On Friday, a few folks from infra team sat together and
discussed the
style guide for the infra-manual (see
https://etherpad.openstack.org/p/kilo-infra-manual ) as a
followup to
reviewing : https://review.openstack.org/#/c/107303/ and
https://review.openstack.org/#/c/107360/ . I took the action item to
cover the problems as an enhancement to our style guide.
Looking up the IBM style guide, I didn't found any explicit
mentioning
of this - so wrote up the following myself:
==
For documentation, we use semantic markup and let the toolchain
format
the text in a consistent and appropriate way. Thus, every
occurence of
a term, like a variable, should use the same markup. The writing
should be clear and markup consistent and thus a reader should
easily
know why a certain term is using a specific markup like boldface or
italics. Explicit use of bold or italics is in general wrong.
While it's currently considered wrong for our current toolchain, how
do people using RST do mark up semantically?
Sorry, found it:
http://sphinx-doc.org/markup/inline.html#other-semantic-markup
Exactly - and I want to add this kind of information to our markup
conventions page, see my other email,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] What is the final manila merge point in Kilo?
Hi, We want to add a manila driver in Kilo. I want to know what is the latest(final) time point we should submit our driver or get our dirver merged in kilo, while guaranteeing our driver can be merged in kilo successfully? Should we must submit our driver or get our dirver merged in kilo before Kilo-1 at 18/12/2014 or we can do this later just before Kilo-2 at 05/02/2014? Thanks. ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[Openstack] Very low bandwidth between instances and routers with OVS, GRE on Debian Jessie (Icehouse)
Hi, Debian testing (jessie) is now frozen, so it seems a good time to use it as a base for an OpenStack deployment. Debian jessie provides OpenStack Icehouse packages from official repos, backported repos are no longer needed. Installation procedure works fine in a setup with OVS and GRE tunnels, but a very low bandwidth is found between instances and routers. I know this is a frequently asked topic, but after reading some related threads and bugs, different causes and solutions where shown. In order to find the problem, several test with iperf has been made and proposed solutions applied: 1. Bandwidth between two instances running on the same compute node: 2.77 Gbits/sec 2. Bandwidht between compute node and network node (Gigabith Ethernet used): 941 Mbits/sec 3. Bandwidth between an instance and a router running on network node: 200 Kbits/sec !!! 4. After applying proposed solution setting instance MTU to 1454, identical result was obtained. 5. After applying proposed solution setting GRO off to physical interfaces (network and compute nodes), identical result was obtained. A solution was found here: https://bugs.launchpad.net/fuel/+bug/1256289 6. After setting tcp segmentation offload off in internal router interface: ip netns exec qrouter-XX ethtool -K qr-14460da5-08 tso off Bandwidth increased to 27 Mbits/sec 7. After setting tcp segmentation offload off in the instance interface, a very good performance is achieved: 776 Mbits/sec. Solution found :), but the question is: What's the best way to implement it? It isn't a practical solution to modify instance Ethernet configuration after an instance is launched. Any tip on this? Thanks! Alberto ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] external dns server for instances-nova-network
Oh - Nice, I've not seen these repositories before. I'll add them to our related links docs section for easier discovery. Also - Slightly Off Topic - At the Summit in Paris, I was speaking with one of the Neutron developers who has some pretty solid Neutron + Designate integration, I'm hoping to catch him on IRC during the week to see how we can move it forward :) Thanks, Kiall On 2014-11-08 19:22, Yuriy Brodskiy wrote: For our use-case we only add fip records into external DNS. Whenever a floating ip(fip) is created via neutron, a DNS domain for the tenant will be created if doesnt exist and a DNS A record will be created in the tenant dns domain. https://github.com/Symantec/neutron-designate-fip-plugin [4] To make sure that VMs have correct domain information, we populate metadata with designate information of the tenant and that is used via cloud-init. https://github.com/Symantec/nova-designate-dns-plugin [5] On Sat, Nov 8, 2014 at 10:25 AM, mad Engineer themadengin...@gmail.com [6] wrote: Hi, Is there any way to use external dns server for instances? All instances are currently getting instance name as hostname and with in openstack network its working and i manually add entries in corporate BIND to make it work for outside openstack. Is it possible to use an an external DNS server as nameserver for all instance and automatically add hostnames to that server. Thanks ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1] Post to : openstack@lists.openstack.org [2] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [3] ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Very low bandwidth between instances and routers with OVS, GRE on Debian Jessie (Icehouse)
Try to disable GRO on interfaces. It's well known bug, causing significant net performance drop in case of the GRE tunnels. (Use ethtool) On Nov 9, 2014 11:17 AM, Alberto Molina Coballes alb.mol...@gmail.com wrote: Hi, Debian testing (jessie) is now frozen, so it seems a good time to use it as a base for an OpenStack deployment. Debian jessie provides OpenStack Icehouse packages from official repos, backported repos are no longer needed. Installation procedure works fine in a setup with OVS and GRE tunnels, but a very low bandwidth is found between instances and routers. I know this is a frequently asked topic, but after reading some related threads and bugs, different causes and solutions where shown. In order to find the problem, several test with iperf has been made and proposed solutions applied: 1. Bandwidth between two instances running on the same compute node: 2.77 Gbits/sec 2. Bandwidht between compute node and network node (Gigabith Ethernet used): 941 Mbits/sec 3. Bandwidth between an instance and a router running on network node: 200 Kbits/sec !!! 4. After applying proposed solution setting instance MTU to 1454, identical result was obtained. 5. After applying proposed solution setting GRO off to physical interfaces (network and compute nodes), identical result was obtained. A solution was found here: https://bugs.launchpad.net/fuel/+bug/1256289 6. After setting tcp segmentation offload off in internal router interface: ip netns exec qrouter-XX ethtool -K qr-14460da5-08 tso off Bandwidth increased to 27 Mbits/sec 7. After setting tcp segmentation offload off in the instance interface, a very good performance is achieved: 776 Mbits/sec. Solution found :), but the question is: What's the best way to implement it? It isn't a practical solution to modify instance Ethernet configuration after an instance is launched. Any tip on this? Thanks! Alberto ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] UCC 2014 London UK-- Conference Programme is now available
Dear All, The conference programme for UCC 2014, being held in London from December 8-11 2014, is available at: http://computing.derby.ac.uk/ucc2014/conference-programme/ We have some very interesting keynote speakers this year. The notable names and their talks include the following: 1. Enabling Cloud Computing at Hyper-Scale: Kenji Takeda, Microsoft 2. Cloud Native Cost Optimization: Adrian Cockcroft, Battery Ventures (prev. Netflix, eBay, Sun) 3. A Few Control Issues in Warehouse-scale Computing: John Wilkes, Google 4. Rack-Scale Computers and the Cloud: Ant Rowstron, Microsoft 5. Joe Baguley, Chief Technology Officer, EMEA, VMware 6. Professor Yike Guo, Imperial College London 7. Actors in the Cloud: Supporting Security, Scalability and Availability , Gul Agha, University of Illinois at Urbana-Champaign, USA 8. Clinical Intelligence Integration: Tackling Large Data Analytics in Real-Time, Oliver Vettel and Andreas Koop, Roche Panel Discussion: How adaptive should our infrastructure (networks, data centres etc.) be to support next generation Clouds? Alan Sill; Open Grid Forum (OGF) Joe Baguley; VMWare John Wilken; Google Erik Elmroth; Umeå University (UMU) Gul Agha; University of Illinois at Urbana-Champaign UCC 2014 Tutorials 1. Azure Machine Learning for Research, Kenji Takeda 2. Model-Driven Management of Multi-Cloud Applications, Danilo Ardagna 3. The Intercloud Architecture and Project, David R. Bernstein 4. Distributed Data Storage: From Dispersed Files to Stealth Databases, Josef Spillner, Johannes Müller, 5. Software Development in Cloud: An Experiential Study with CMS, Chandra Sekaran K, 6. Data Analysis with R, Shruti Kohli, Shruti Kohli 6. Microsoft Azure for Research, Kenji Takeda 7. Autonomic Clouds, Omer Rana and Manish Parashar, Omer F. Rana 8. Help Clinical Intelligence take the next step using state-of-the art in-memory analytics, Oliver Vettel and Andreas Koop 9. CRISTAL : Designing Traceable Cloud-based Systems, Richard McClatchey, Andrew Branson UCC 2014 Workshops 1. International Symposium on Big Data Computing 2014 – BDC 2014 2. 6th Cloud Control Workshop – CloudControl6 3. Cloud Federation Management: Identity, Resources and Applications Workshop – CFM 2014 4. Workshops on Standards and Pre-Standards Topics in Clouds, Big Data and Data Analytics – SCBDA 2014 5. ITaaU Network+ Symposium – ITaaU 2014 6. Clouds and eScience Applications Management Workshop – CloudAM 2014 7. Crowdsourcing and Gamification in the Cloud Workshop – CGCloud 2014 8. Re-computability in the Cloud Workshop – Re-computability 2014 9. Advances in CC Legislation, Accountability, Security and Privacy Workshop – CLASP 2014 10. Trust in Cloud Computing Workshop – IWTCC 2014 11. Green Cloud Computing Workshop – GCC 2014 12. Smart City Clouds: Technologies, Systems and Applications Workshop – SCCTSA 2014 13. Cloud Automation, Intelligent Management and Scalability Workshop – CAIMS 2014 14. Cyber-physical Cloud Computing Workshop – CPCC 2014 15. Network Virtualization and SDN for Cloud Data Centres Workshop 16. Big Data, Intelligence Management and Analytics Workshop – BDIMA 17. Big Data and Social Networking Management and Security Workshop 18. Education in the Cloud Workshop – EC 2014 19. EGI Federated Cloud Workshop 20. Plugfest: Cloud Interoperability Event UCC 2014 Registration To register please visit: http://www.derby.ac.uk/enterprisecentre/events/ucc/book/ Best regards Ashiq Anjum Organising Chair UCC 2014 -- http://computing.derby.ac.uk/ucc2014/ Dr. Ashiq Anjum Reader in Distributed Computing Distributed and Intelligent Systems (DISYS) research centre School of Computing and Mathematics University of Derby Room E510 Kedleston Road Derby, UK DE22 1GB ashiq.an...@cern.ch a.an...@derby.ac.uk +44 (0) 1332 591881 44 (0) 772 4017071 http://www.derby.ac.uk/staff/ashiq-anjum/ ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack-operators] Proposal for an 'Operations' project
Excerpts from Jeremy Stanley's message of 2014-11-08 16:23:02 -0800: On 2014-11-08 04:08:08 -0500 (-0500), Fischer, Matt wrote: [...] Perhaps some of the code fits in some places as previously mentioned on the list, but the issue is that none of those projects really focus on operations. The projects are inevitably developer focused, despite the best attempts to get operator feedback. [...] I would counter that we have lots of operator-focused projects already underway... the Infra and QA teams, for example, have plenty of projects which are entirely shell scripts and configuration management. If you were in any of the Deployment Program's design sessions, there was a fairly consistent message that Triple-O is encouraging direct involvement from the various config management teams to bring more officialness to the diverse tools with which OpenStack is deployed and managed at production sites. If the projects you want to start aren't focused on deployment and lifecycle management, nor on community infrastructure tools, nor on documentation, then I would buy that there's some potential project use cases for which we haven't made suitable homes yet. But I'd hate to see that used to further what I see as an unnecessary separation between developers and operators. There's this crazy movement underway called DevOps where we stop treating these two groups as independent victims of each-other's conflicting responsibilities. Instead we need to see each as simply _more_ focused on one responsibility or another, but all on the same team with the same end goal of a stable, agile deployment. Given that most of us seem to believe that, I am really confused why anybody sees the Deployment Program as anything other than an operations focused project. It is entirely focused on deploying and operating OpenStack. The fact that we've stated we will use components of OpenStack whenever that is possible is secondary to the first charge of actually deploying a managable OpenStack cloud. Now I understand, in the past we have been entirely prescriptive and opinionated on levels that have made large portions of the operators feel excluded. That may have been necessary to make some early progress, but I don't believe it will continue. I sat with several people who attended the gathering of operators that this thread references, and at least the few of us there agreed that most of what they discussed wasn't specifically about deploying OpenStack, but about deploying it with all of the supporting tools that surround OpenStack. This sounds like the beginnings of a complimentary program. I am quite excited to see some discussion around coalescing these efforts. Having diverse deployments is useful for finding efficient ways to solve real problems. How you get logs into LogStash and what Kibana queries you use to find issues is interesting. Whether you express that you want your logs in LogStash as Chef, Puppet, or diskimage-builder elements with os-apply-config templates and os-refresh-config scripts is pretty uninteresting in comparison. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Proposal for an 'Operations' project
Could you please explain exactly what the Deployment Program is? Is that just the same as the Infra or TripleO project? I confess that I do not know what it is and until now haven¹t heard of it. Is the main concern here around duplication of effort between the Deployment Program and this proposed operators project? I don¹t understand if/why there is a problem with starting up an operators project, other than semantics. Mike On 11/9/14, 9:45 AM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Jeremy Stanley's message of 2014-11-08 16:23:02 -0800: On 2014-11-08 04:08:08 -0500 (-0500), Fischer, Matt wrote: [...] Perhaps some of the code fits in some places as previously mentioned on the list, but the issue is that none of those projects really focus on operations. The projects are inevitably developer focused, despite the best attempts to get operator feedback. [...] I would counter that we have lots of operator-focused projects already underway... the Infra and QA teams, for example, have plenty of projects which are entirely shell scripts and configuration management. If you were in any of the Deployment Program's design sessions, there was a fairly consistent message that Triple-O is encouraging direct involvement from the various config management teams to bring more officialness to the diverse tools with which OpenStack is deployed and managed at production sites. If the projects you want to start aren't focused on deployment and lifecycle management, nor on community infrastructure tools, nor on documentation, then I would buy that there's some potential project use cases for which we haven't made suitable homes yet. But I'd hate to see that used to further what I see as an unnecessary separation between developers and operators. There's this crazy movement underway called DevOps where we stop treating these two groups as independent victims of each-other's conflicting responsibilities. Instead we need to see each as simply _more_ focused on one responsibility or another, but all on the same team with the same end goal of a stable, agile deployment. Given that most of us seem to believe that, I am really confused why anybody sees the Deployment Program as anything other than an operations focused project. It is entirely focused on deploying and operating OpenStack. The fact that we've stated we will use components of OpenStack whenever that is possible is secondary to the first charge of actually deploying a managable OpenStack cloud. Now I understand, in the past we have been entirely prescriptive and opinionated on levels that have made large portions of the operators feel excluded. That may have been necessary to make some early progress, but I don't believe it will continue. I sat with several people who attended the gathering of operators that this thread references, and at least the few of us there agreed that most of what they discussed wasn't specifically about deploying OpenStack, but about deploying it with all of the supporting tools that surround OpenStack. This sounds like the beginnings of a complimentary program. I am quite excited to see some discussion around coalescing these efforts. Having diverse deployments is useful for finding efficient ways to solve real problems. How you get logs into LogStash and what Kibana queries you use to find issues is interesting. Whether you express that you want your logs in LogStash as Chef, Puppet, or diskimage-builder elements with os-apply-config templates and os-refresh-config scripts is pretty uninteresting in comparison. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
