<DIV>@Jay Lau I agree with you that image pull be time-consuming. </DIV>
<DIV>Did is much better to supply a magnum api let end-user can clean image that not used?</DIV>
<DIV>Clean or not clean is decide by the end-user. Or we can supply a method let </DIV>
<DIV>end-user can decide whether or not clean image.</DIV>
<DIV>
<DIV style="PADDING-BOTTOM: 2px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; FONT-FAMILY: Arial Narrow; FONT-SIZE: 12px; PADDING-TOP: 2px">------------------ Original ------------------</DIV>
<DIV style="PADDING-BOTTOM: 8px; PADDING-LEFT: 8px; PADDING-RIGHT: 8px; BACKGROUND: #efefef; FONT-SIZE: 12px; PADDING-TOP: 8px">
<DIV><B>From: </B> "openstack-dev-request";<openstack-dev-request@lists.openstack.org>;</DIV>
<DIV><B>Date: </B> Mon, Apr 13, 2015 04:59 PM</DIV>
<DIV><B>To: </B> "openstack-dev"<openstack-dev@lists.openstack.org>; <WBR></DIV>
<DIV></DIV>
<DIV><B>Subject: </B> OpenStack-dev Digest, Vol 36, Issue 32</DIV></DIV>
<DIV><BR></DIV>Send OpenStack-dev mailing list submissions to<BR>openstack-dev@lists.openstack.org<BR><BR>To subscribe or unsubscribe via the World Wide Web, visit<BR>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>or, via email, send a message with subject or body 'help' to<BR>openstack-dev-request@lists.openstack.org<BR><BR>You can reach the person managing the list at<BR>openstack-dev-owner@lists.openstack.org<BR><BR>When replying, please edit your Subject line so it is more specific<BR>than "Re: Contents of OpenStack-dev digest..."<BR><BR><BR>Today's Topics:<BR><BR> 1. Re: [Nova] VMware CI (Davanum Srinivas)<BR> 2. Re: [Nova] VMware CI (Gary Kotton)<BR> 3. Re: [TripleO] Consistent variable documentation for<BR> diskimage-builder elements (Gregory Haynes)<BR> 4. Re: [neutron] Neutron scaling datapoints? (Joshua Harlow)<BR> 5. Re: [OpenStack-docs] What's Up Doc? Apr 10 2015 (Monty Taylor)<BR> 6. Re: [neutron] Neutron scaling datapoints? (Kevin Benton)<BR> 7. Re: [neutron] Neutron scaling datapoints? (Kevin Benton)<BR> 8. [all][pbr] splitting our deployment vs install dependencies<BR> (Robert Collins)<BR> 9. Re: [all][pbr] splitting our deployment vs install<BR> dependencies (Monty Taylor)<BR> 10. Re: [all][pbr] splitting our deployment vs install<BR> dependencies (James Polley)<BR> 11. Re: [all][pbr] splitting our deployment vs install<BR> dependencies (Monty Taylor)<BR> 12. Re: [all][pbr] splitting our deployment vs install<BR> dependencies (Robert Collins)<BR> 13. Re: [all][pbr] splitting our deployment vs install<BR> dependencies (Robert Collins)<BR> 14. [all] Problems with keystoneclient stable branch (and maybe<BR> yours too) (Brant Knudson)<BR> 15. Re: In loving memory of Chris Yeoh (Michael Still)<BR> 16. Re: [all][pbr] splitting our deployment vs install<BR> dependencies (Robert Collins)<BR> 17. Re: [neutron] Neutron scaling datapoints? (joehuang)<BR> 18. Re: [neutron] Neutron scaling datapoints? (Joshua Harlow)<BR> 19. Re: [neutron] Neutron scaling datapoints? (Joshua Harlow)<BR> 20. Re: [neutron] Neutron scaling datapoints? (Joshua Harlow)<BR> 21. Re: [puppet] Puppet PTL (Emilien Macchi)<BR> 22. Re: In loving memory of Chris Yeoh (Gary Kotton)<BR> 23. Re: [neutron] Neutron scaling datapoints? (Attila Fazekas)<BR> 24. Re: [Neutron] Regarding neutron bug # 1432582 (Kevin Benton)<BR> 25. ?magnum?About clean none use container imag<BR> (=?gb18030?B?NDQ5MTcxMzQy?=)<BR> 26. Re: ?magnum?About clean none use container imag (Jay Lau)<BR> 27. Re: [neutron] Neutron scaling datapoints? (Attila Fazekas)<BR> 28. Re: In loving memory of Chris Yeoh (wu jiang)<BR> 29. Re: [oslo] eventlet 0.17.3 is now fully Python 3 compatible<BR> (Victor Stinner)<BR> 30. [Fuel] Nominate Andrey Skedzinskiy for fuel-qa(devops) core<BR> (Anastasia Urlapova)<BR> 31. Re: [Fuel] Nominate Andrey Skedzinskiy for fuel-qa(devops)<BR> core (Alexander Kislitsky)<BR> 32. Re: [all][pbr] splitting our deployment vs install<BR> dependencies (Miguel Angel Ajo Pelayo)<BR> 33. ??: [neutron] Neutron scaling datapoints? (Wangbibo)<BR><BR><BR>----------------------------------------------------------------------<BR><BR>Message: 1<BR>Date: Sun, 12 Apr 2015 08:04:43 -0400<BR>From: Davanum Srinivas <davanum@gmail.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [Nova] VMware CI<BR>Message-ID:<BR><CANw6fcHxxWT215_AtJeX5LjvwnMrTvGpqXXuGi=oFj9prw_SyA@mail.gmail.com><BR>Content-Type: text/plain; charset=UTF-8<BR><BR>Gary, John,<BR><BR>Just to speed things up, i filed a backport:<BR>https://review.openstack.org/#/c/172710/<BR><BR>thanks,<BR>dims<BR><BR>On Sun, Apr 12, 2015 at 4:23 AM, John Garbutt <john@johngarbutt.com> wrote:<BR>> I have updated the bug so it's high priority and tagged with<BR>> kilo-rc-potential, and added your note from below as a comment on the bug.<BR>><BR>> It looks like it might be worth a backport so it gets into RC2? Can anyone<BR>> take that bit on please?<BR>><BR>> Thanks,<BR>> John<BR>><BR>><BR>> On Sunday, April 12, 2015, Gary Kotton <gkotton@vmware.com> wrote:<BR>>><BR>>> Hi,<BR>>> Can a core please take a look at https://review.openstack.org/#/c/171037.<BR>>> The CI is broken due to commit e7ae5bb7fbdd5b79bde8937958dd0a645554a5f0.<BR>>> Thanks<BR>>> Gary<BR>><BR>><BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>><BR><BR><BR><BR>-- <BR>Davanum Srinivas :: https://twitter.com/dims<BR><BR><BR><BR>------------------------------<BR><BR>Message: 2<BR>Date: Sun, 12 Apr 2015 12:36:51 +0000<BR>From: Gary Kotton <gkotton@vmware.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [Nova] VMware CI<BR>Message-ID: <D150418B.7456D%gkotton@vmware.com><BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>Thanks!<BR><BR>On 4/12/15, 3:04 PM, "Davanum Srinivas" <davanum@gmail.com> wrote:<BR><BR>>Gary, John,<BR>><BR>>Just to speed things up, i filed a backport:<BR>>https://review.openstack.org/#/c/172710/<BR>><BR>>thanks,<BR>>dims<BR>><BR>>On Sun, Apr 12, 2015 at 4:23 AM, John Garbutt <john@johngarbutt.com><BR>>wrote:<BR>>> I have updated the bug so it's high priority and tagged with<BR>>> kilo-rc-potential, and added your note from below as a comment on the<BR>>>bug.<BR>>><BR>>> It looks like it might be worth a backport so it gets into RC2? Can<BR>>>anyone<BR>>> take that bit on please?<BR>>><BR>>> Thanks,<BR>>> John<BR>>><BR>>><BR>>> On Sunday, April 12, 2015, Gary Kotton <gkotton@vmware.com> wrote:<BR>>>><BR>>>> Hi,<BR>>>> Can a core please take a look at<BR>>>>https://review.openstack.org/#/c/171037.<BR>>>> The CI is broken due to commit<BR>>>>e7ae5bb7fbdd5b79bde8937958dd0a645554a5f0.<BR>>>> Thanks<BR>>>> Gary<BR>>><BR>>><BR>>> <BR>>>_________________________________________________________________________<BR>>>_<BR>>> OpenStack Development Mailing List (not for usage questions)<BR>>> Unsubscribe: <BR>>>OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>>><BR>><BR>><BR>><BR>>-- <BR>>Davanum Srinivas ::<BR>>https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_dims&d=Aw<BR>>ICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JY<BR>>Bk8YTeq9N3-diTlNj4GyNc&m=O_vdKYuE0xFSaX6xbIHw3qdu0asR94NVcbUKhC9t2vs&s=zv9<BR>>uaaxIRcEZR4SDIuS8EJW7YjE4-2QEZKZtxKcl4ow&e=<BR>><BR>>__________________________________________________________________________<BR>>OpenStack Development Mailing List (not for usage questions)<BR>>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR><BR><BR><BR><BR>------------------------------<BR><BR>Message: 3<BR>Date: Sun, 12 Apr 2015 16:36:32 +0000<BR>From: Gregory Haynes <greg@greghaynes.net><BR>To: openstack-dev <openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [TripleO] Consistent variable<BR>documentation for diskimage-builder elements<BR>Message-ID: <1428855849-sup-8142@greghaynes0.opus.gah><BR>Content-Type: text/plain; charset=UTF-8<BR><BR>Excerpts from Clint Byrum's message of 2015-04-08 23:11:29 +0000:<BR>> <BR>> I discussed a format for something similar here:<BR>> <BR>> https://review.openstack.org/#/c/162267/<BR>> <BR>> Perhaps we could merge the effort.<BR>> <BR>> The design and implementation in that might take some time, but if we<BR>> can document the variables at the same time we prepare the inputs for<BR>> isolation, that seems like a winning path forward.<BR>> <BR><BR>The solution presented there would be awesome for not having to document<BR>the variables manually at all - we can do some sphinx plugin magic to<BR>autogen the doc sections and even get some annoying to write out<BR>features like static links for each var (Im sure you knew this, just<BR>spelling it out).<BR><BR>I agree that itd be better to not put a lot of effort into switching all<BR>the README's over right now and instead work on the argument isolation.<BR>My hope is that in the meanwhile new elements we create and possibly<BR>README's we end up editing get moved over to this new format. Then, we<BR>can try and autogen something that is pretty similar when the time<BR>comes.<BR><BR>Now, lets get that arg isolation donw already. ;)<BR><BR>Cheers,<BR>Greg<BR><BR><BR><BR>------------------------------<BR><BR>Message: 4<BR>Date: Sun, 12 Apr 2015 09:38:20 -0700<BR>From: Joshua Harlow <harlowja@outlook.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>Message-ID: <BLU437-SMTP29438D4D9324695F8F13EFD8F80@phx.gbl><BR>Content-Type: text/plain; charset="UTF-8"; format=flowed<BR><BR>Kevin Benton wrote:<BR>> So IIUC tooz would be handling the liveness detection for the agents.<BR>> That would be nice to get ride of that logic in Neutron and just<BR>> register callbacks for rescheduling the dead.<BR>><BR>> Where does it store that state, does it persist timestamps to the DB<BR>> like Neutron does? If so, how would that scale better? If not, who does<BR>> a given node ask to know if an agent is online or offline when making a<BR>> scheduling decision?<BR><BR>Timestamps are just one way (and likely the most primitive), using redis <BR>(or memcache) key/value and expiry are another (and letting memcache or <BR>redis expire using its own internal algorithms), using zookeeper <BR>ephemeral nodes[1] are another... The point being that its backend <BR>specific and tooz supports varying backends.<BR><BR>><BR>> However, before (what I assume is) the large code change to implement<BR>> tooz, I would like to quantify that the heartbeats are actually a<BR>> bottleneck. When I was doing some profiling of them on the master branch<BR>> a few months ago, processing a heartbeat took an order of magnitude less<BR>> time (<50ms) than the 'sync routers' task of the l3 agent (~300ms). A<BR>> few query optimizations might buy us a lot more headroom before we have<BR>> to fall back to large refactors.<BR><BR>Sure, always good to avoid prematurely optimizing things...<BR><BR>Although this is relevant for u I think anyway:<BR><BR>https://review.openstack.org/#/c/138607/ (same thing/nearly same in nova)...<BR><BR>https://review.openstack.org/#/c/172502/ (a WIP implementation of the <BR>latter).<BR><BR>[1] <BR>https://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#Ephemeral+Nodes<BR><BR>><BR>> Kevin Benton wrote:<BR>><BR>><BR>> One of the most common is the heartbeat from each agent. However, I<BR>> don't think we can't eliminate them because they are used to determine<BR>> if the agents are still alive for scheduling purposes. Did you have<BR>> something else in mind to determine if an agent is alive?<BR>><BR>><BR>> Put each agent in a tooz[1] group; have each agent periodically<BR>> heartbeat[2], have whoever needs to schedule read the active members of<BR>> that group (or use [3] to get notified via a callback), profit...<BR>><BR>> Pick from your favorite (supporting) driver at:<BR>><BR>> http://docs.openstack.org/__developer/tooz/compatibility.__html<BR>> <http://docs.openstack.org/developer/tooz/compatibility.html><BR>><BR>> [1]<BR>> http://docs.openstack.org/__developer/tooz/compatibility.__html#grouping<BR>> <http://docs.openstack.org/developer/tooz/compatibility.html#grouping><BR>> [2]<BR>> https://github.com/openstack/__tooz/blob/0.13.1/tooz/__coordination.py#L315<BR>> <https://github.com/openstack/tooz/blob/0.13.1/tooz/coordination.py#L315><BR>> [3]<BR>> http://docs.openstack.org/__developer/tooz/tutorial/group___membership.html#watching-__group-changes<BR>> <http://docs.openstack.org/developer/tooz/tutorial/group_membership.html#watching-group-changes><BR>><BR>><BR>> ______________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe:<BR>> OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe<BR>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><BR>> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev<BR>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev><BR>><BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR><BR><BR><BR>------------------------------<BR><BR>Message: 5<BR>Date: Sun, 12 Apr 2015 13:43:04 -0400<BR>From: Monty Taylor <mordred@inaugust.com><BR>To: Bernd Bausch <berndbausch@gmail.com>, "'OpenStack Development<BR>Mailing List (not for usage questions)'"<BR><openstack-dev@lists.openstack.org>,<BR>openstack-docs@lists.openstack.org, openstack-i18n@lists.openstack.org<BR>Cc: 'Jesse Noller' <jesse.noller@rackspace.com><BR>Subject: Re: [openstack-dev] [OpenStack-docs] What's Up Doc? Apr 10<BR>2015<BR>Message-ID: <552AAEA8.3020409@inaugust.com><BR>Content-Type: text/plain; charset=windows-1252<BR><BR>On 04/12/2015 04:16 AM, Bernd Bausch wrote:<BR>> There is nothing like a good rage on a Sunday (yes Sunday) afternoon. Many<BR>> thanks, Monty. You helped me make glance work for my particular case; I will<BR>> limit any further messages to the docs mailing list.<BR><BR>Rage on a Sunday followed up by rage coding:<BR><BR>https://review.openstack.org/172728<BR><BR>I figured I should stop flapping my mouth and write some code.<BR><BR>> For now I will use API v1 (export OS_IMAGE_API_VERSION=1), pending further<BR>> discussions in the install guide team. To me, install guides are more a way<BR>> to enter the OpenStack world than an official installation guide; no need to<BR>> expose newbies including myself to the complexity of v2.<BR>> <BR>> Bernd<BR>> <BR>> -----Original Message-----<BR>> From: Monty Taylor [mailto:mordred@inaugust.com] <BR>> Sent: Sunday, April 12, 2015 6:22 AM<BR>> To: OpenStack Development Mailing List (not for usage questions);<BR>> openstack-docs@lists.openstack.org; openstack-i18n@lists.openstack.org<BR>> Cc: Jesse Noller<BR>> Subject: Re: [OpenStack-docs] [openstack-dev] What's Up Doc? Apr 10 2015<BR>> <BR>> Sorry for top posting - I wasn't subscribed to the doc list before clarkb<BR>> told me about this thread. Warning ... rage coming ... if you don't want to<BR>> read rage on a Saturday, I recommend skipping this email.<BR>> <BR>> a) There may be a doc bug here, but I'm not 100% convinced it's a doc bug -<BR>> I'll try to characterize it in this way:<BR>> <BR>> "As a user, I do not know what version of glance I am or should be<BR>> interacting with"<BR>> <BR>> That part of this is about the default version that python-glanceclient may<BR>> or may not use and what version you may or may not need to provide on the<BR>> command line is a badness I'll get to in a second - but a clear "so you want<BR>> to upload an image, here's what you need to know" is, I think, what Bernd<BR>> was looking for<BR>> <BR>> b) Glance is categorically broken in all regards related to this topic.<BR>> This thing is the most painful and most broken of everything that exists in<BR>> OpenStack. It is the source of MONTHS of development to deal with it in<BR>> Infra, and even the workarounds are terrible.<BR>> <BR>> Let me expand:<BR>> <BR>> glance image-upload MAY OR MAY NOT work on your cloud, and there is<BR>> absolutely no way you as a user can tell. You just have to try and find out.<BR>> <BR>> IF glance image-upload does not work for you, it may be because of two<BR>> things, neither of which are possible for you as a user to find out:<BR>> <BR>> Either:<BR>> <BR>> - Your cloud has decided to not enable image upload permissions in their<BR>> policy.json file, which is a completely opaque choice that you as a user<BR>> have no way of finding out. If this is the case you have no recourse, sorry.<BR>> - Your cloud has deployed a recent glance and has configured it for glance<BR>> v2 and has configured it in the policy.json file to ONLY allow v2 and to<BR>> disallow image-upload<BR>> <BR>> If the second is true, which you have no way to discover except for trying,<BR>> what you need to do is:<BR>> <BR>> - upload the image to swift<BR>> - glance task-create --type=import --input='{"import_from":<BR>> "$PATH_TO_IMAGE_IN_SWIFT", "image_properties" : {"name": "Human Readable<BR>> Image Name"}}'<BR>> <BR>> Yes, you do have to pass JSON on the command line, because BONGHITS (/me<BR>> glares at the now absent Brian Waldon with withering disdain for having<BR>> inflicted such an absolutely craptastic API on the world.)<BR>> <BR>> Then, you need to poll glance task-status for the status of the import_from<BR>> task until your image has imported.<BR>> <BR>> c) The python-glanceclient command line client should encapsulate that<BR>> ridiculous logic for you, but it does not<BR>> <BR>> d) It should be possible to discover from the cloud which of the approaches<BR>> you should take, but it isn't<BR>> <BR>> Now - I'm honestly not sure how far the docs team should take working around<BR>> this - because fully describing how to successfully upload an image without<BR>> resorting to calling people names is impossible - but is it really the Docs<BR>> team job to make an impossible API seem user friendly? Or, should we not<BR>> treat this as a docs bug and instead treat it as a Glance bug and demand a<BR>> v3 API that rolls back the task interface?<BR>> <BR>> I vote for the latter.<BR>> <BR>> BTW - the shade library encodes as much of the logic above as it can.<BR>> That it exists makes me sad.<BR>> <BR>> Monty<BR>> <BR>> On Sat, Apr 11, 2015 at 10:50 AM, Matt Kassawara <mkassawara at gmail.com><BR>> wrote:<BR>> <BR>>> Sounds like a problem with one or more packages (perhaps<BR>>> python-glanceclient?) because that command using the source version <BR>>> (not<BR>>> packages) returns the normal list of help items. Maybe try the source <BR>>> version using "pip install python-glanceclient"?<BR>>><BR>>> On Sat, Apr 11, 2015 at 5:55 AM, Bernd Bausch <berndbausch at <BR>>> gmail.com><BR>>> wrote:<BR>>><BR>>>> glance help image-create. Sorry for being vague.<BR>>>><BR>>>> When running glance with the parameters from the install guide (the <BR>>>> trunk version), I am told that I am not doing it correctly; I don't <BR>>>> have the precise message handy.<BR>>>><BR>>>><BR>>>><BR>>>> My fear is that I will hit similar problems later. You solving the <BR>>>> problem would be nice but not enough :)<BR>>>><BR>>>><BR>>>><BR>>>> *From:* Matt Kassawara [mailto:mkassawara at gmail.com]<BR>>>> *Sent:* Saturday, April 11, 2015 1:59 PM<BR>>>> *To:* Bernd Bausch<BR>>>> *Cc:* openstack-docs at lists.openstack.org<BR>>>><BR>>>> *Subject:* Re: [OpenStack-docs] [install-guide] RE: What's Up Doc? <BR>>>> Apr<BR>>>> 10 2015<BR>>>><BR>>>><BR>>>><BR>>>> When you run "glance help image-create" or just "glance image-create"<BR>>>> with no arguments?<BR>>>><BR>>>><BR>>>><BR>>>> On Fri, Apr 10, 2015 at 11:45 PM, Bernd Bausch <berndbausch at <BR>>>> gmail.com><BR>>>> wrote:<BR>>>><BR>>>> This is what I get when running glance image-create:<BR>>>><BR>>>><BR>>>><BR>>>> usage: glance image-create [--property <key=value>] <BR>>>> [--file <FILE>]<BR>>>><BR>>>><BR>>>> [--progress]<BR>>>><BR>>>><BR>>>> <unavailable><BR>>>><BR>>>><BR>>>><BR>>>> Create a new image.<BR>>>><BR>>>><BR>>>><BR>>>> Positional arguments:<BR>>>><BR>>>> <unavailable> Please run with connection<BR>>>> parameters set to retrieve<BR>>>><BR>>>> the schema for <BR>>>> generating help for this command<BR>>>><BR>>>><BR>>>><BR>>>> So I wonder how I can get to the bottom of this.<BR>>>><BR>>>><BR>>>><BR>>>> *From:* Matt Kassawara [mailto:mkassawara at gmail.com]<BR>>>> *Sent:* Saturday, April 11, 2015 1:39 PM<BR>>>> *To:* Bernd Bausch; openstack-docs at lists.openstack.org<BR>>>> *Subject:* Re: [OpenStack-docs] [install-guide] RE: What's Up Doc? <BR>>>> Apr<BR>>>> 10 2015<BR>>>><BR>>>><BR>>>><BR>>>> I'd use the conventional python-*client for all services except <BR>>>> keystone because the Openstack client doesn't seem very complete for <BR>>>> them. If<BR>> you're<BR>>>> using the glance client, it defaults to the v1 API and the commands <BR>>>> from the Juno installation guide should work. If you use the v2 API, <BR>>>> one thing changes with how to set public/private visibility.<BR>>>><BR>>>><BR>>>><BR>>>> On Fri, Apr 10, 2015 at 8:11 PM, Bernd Bausch <berndbausch at <BR>>>> gmail.com><BR>>>> wrote:<BR>>>><BR>>>> Regarding the installation guide, I need some advice. Perhaps the <BR>>>> docs community can help?<BR>>>><BR>>>> I am trying to install Kilo on yum-based systems using a repo from <BR>>>> the RDO project. I have hit a few roadblocks that I have been able to <BR>>>> deal with, but I am unsure what to do with the current one.<BR>>>><BR>>>> My questions are: Is it appropriate to ask developers about the <BR>>>> intended way of doing things, if the old ways don't work anymore? If <BR>>>> yes, what are the best channels - chat, dev mailing list, personal <BR>>>> email, .? If no,<BR>> what<BR>>>> else can I do? Do developers make such changes public somewhere?<BR>>>><BR>>>> Below is the problem I am currently trying to solve. **Note** that I <BR>>>> am including it as an illustration what I am struggling with (more <BR>>>> problems will show up as I continue working on this); I am not asking <BR>>>> you to solve this particular problem for me.<BR>>>><BR>>>> So far, to upload an image to Glance, the "glance image-create" <BR>>>> command is used. This command doesn't work anymore as in the past, <BR>>>> and I don't understand what the "glance help image-create" is trying <BR>>>> to say. On the other hand, I haven't found an equivalent command in the<BR>> new "openstack"<BR>>>> CLI client. So my question is - what is the correct way to upload an<BR>> image<BR>>>> these days.<BR>>>><BR>>>> Have a great weekend,<BR>>>><BR>>>> Bernd<BR>>>><BR>>>> From: Anne Gentle [mailto:annegentle at justwriteclick.com]<BR>>>> Sent: Saturday, April 11, 2015 12:24 AM<BR>>>> To: openstack-docs at lists.openstack.org; OpenStack Development <BR>>>> Mailing List; openstack-i18n at lists.openstack.org<BR>>>> Cc: Jesse Noller<BR>>>> Subject: [OpenStack-docs] What's Up Doc? Apr 10 2015<BR>>>><BR>>>> Hi all,<BR>>>><BR>>>> As you probably saw from PTL nominations last week, I'm happy to hand <BR>>>> the docs PTL baton to Lana Brindley! I loved leading this group and <BR>>>> thank you all for supporting me. Thank you Lana for your willingness <BR>>>> to lead. I'm still here to bring us to the Kilo release, so this <BR>>>> week's What's Up Doc brings sharp focus requests to everyone to work <BR>>>> on docs. These are<BR>> the top<BR>>>> priorities that we all need to work on - devs, writers, testers, <BR>>>> gaters, everyone.<BR>>>><BR>>>> 1. Bug triaging and fixing, especially for openstack-manuals. There <BR>>>> are nearly 300 DocImpact bugs logged that we need developers to <BR>>>> circle<BR>> back to.<BR>>>> With nearly 600 bugs overall, we need lots of focus here. To that <BR>>>> end, I propose we hold a bug triage day. I'll send details in a separate<BR>> email.<BR>>>><BR>>>> 2. Install Guide testing and reviewing. The Install Guide team has a <BR>>>> published spec that will help reviewers see what's changing with the <BR>>>> Kilo Install guide:<BR>>>><BR>> http://specs.openstack.org/openstack/docs-specs/specs/kilo/installguide-kilo<BR>> .html<BR>>>> Join them for weekly meetings Tuesdays at at 13:00 UTC (8:00 AM US<BR>> CDT) in<BR>>>> Google Hangout:<BR>>>><BR>> https://plus.google.com/hangouts/_/calendar/a2FyaW4ua2F0aG9kZUBnbWFpbC5jb20.<BR>> jj2lu2nbj71a0dan11vatdav3k<BR>>>><BR>>>> If you do nothing else but these two focus areas we'll be in good shape.<BR>>>> There are other activities going on leading up to Vancouver but those <BR>>>> two are top priorities.<BR>>>><BR>>>> _RST Migration_<BR>>>><BR>>>> We are working to resolve translation tool expectations with the i18N <BR>>>> team. I want to publish the RST-based English End User Guide and<BR>> Admin User<BR>>>> Guide once we're all comfortable with the way forward. Daisy will <BR>>>> discuss the implications at the next i18N team meeting Thursday at <BR>>>> 0800 UTC, and we'll implement and communicate the plan.<BR>>>><BR>>>> _Networking Guide_<BR>>>><BR>>>> Next on the list is Networking Guide testing and reviewing. The <BR>>>> Networking Guide team has a talk in Vancouver and needs to get their<BR>> guide<BR>>>> in shape for publishing. The neutron team is holding a doc day April 23.<BR>>>> Please join in -- they'll post details in their notes.<BR>>>><BR>>>> _First App Tutorial_<BR>>>><BR>>>> There's also the First Application Tutorial that needs to finish the <BR>>>> spec and needs an editing cleanup prior to publishing. Ideally that <BR>>>> will<BR>> happen<BR>>>> before Vancouver, we need to get it to the finish line.<BR>>>><BR>>>> _HA Guide_<BR>>>><BR>>>> With everything else going on we need an updated spec for the HA <BR>>>> Guide - the wiki page isn't enough. Based on this week's doc team <BR>>>> meeting it<BR>> sounds<BR>>>> like that can go to RST as well but we need it in the spec so we can <BR>>>> plan and cross-coordinate with the other priorities leading up to<BR>> Vancouver.<BR>>>><BR>>>> _Vancouver Summit _<BR>>>> The docs team has four Fishbowl time slots, 2 Workroom slots, and 1 <BR>>>> Meetup allocated now. If you'd like to discuss a cross-project idea,<BR>> please<BR>>>> use the form to suggest new ideas:<BR>>>> http://goo.gl/forms/S69HM6XEeb. You can see the current suggestions <BR>>>> already posted here:<BR>>>><BR>>>><BR>> https://docs.google.com/spreadsheets/d/1vCTZBJKCMZ2xBhglnuK3ciKo3E8UMFo5S5lm<BR>> IAYMCSE/edit?usp=sharing<BR>>>><BR>>>> Lana or I will send out an etherpad in the next week or so with topic <BR>>>> suggestions for our allocation.<BR>>>><BR>>>> Thanks,<BR>>>> Anne<BR>>>><BR>>>> --<BR>>>> Anne Gentle<BR>>>> annegentle at justwriteclick.com<BR>>>><BR>>>> _______________________________________________<BR>>>> OpenStack-docs mailing list<BR>>>> OpenStack-docs at lists.openstack.org <BR>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs<BR>>>><BR>>>><BR>>>><BR>>>><BR>>>><BR>>><BR>>><BR>>> _______________________________________________<BR>>> OpenStack-docs mailing list<BR>>> OpenStack-docs at lists.openstack.org<BR>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs<BR>>><BR>>><BR>> <BR>> _______________________________________________<BR>> OpenStack-docs mailing list<BR>> OpenStack-docs@lists.openstack.org<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs<BR>> <BR>> <BR><BR><BR><BR><BR>------------------------------<BR><BR>Message: 6<BR>Date: Sun, 12 Apr 2015 12:40:07 -0700<BR>From: Kevin Benton <blak111@gmail.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>Message-ID:<BR><CAO_F6JMFRGSGAQu_CyXGZZmkuHmy8vuO2gCUWHcL+DMeuyxd1Q@mail.gmail.com><BR>Content-Type: text/plain; charset="utf-8"<BR><BR>>I assumed that all agents are connected to same IP address of RabbitMQ,<BR>then the connection will exceed the port ranges limitation.<BR><BR>Only if the clients are all using the same IP address. If connections<BR>weren't scoped by source IP, busy servers would be completely unreliable<BR>because clients would keep having source port collisions.<BR><BR>For example, the following is a netstat output from a server with two<BR>connections to a service running on port 4000 with both clients using<BR>source port 50000: http://paste.openstack.org/show/203211/<BR><BR>>the client should be aware of the cluster member failure, and reconnect to<BR>other survive member. No such mechnism has been implemented yet.<BR><BR>If I understand what you are suggesting, it already has been implemented<BR>that way. The neutron agents and servers can be configured with multiple<BR>rabbitmq servers and they will cycle through the list whenever there is a<BR>failure.<BR><BR>The only downside to that approach is that every neutron agent and server<BR>has to be configured with every rabbitmq server address. This gets tedious<BR>to manage if you want to add cluster members dynamically so using a load<BR>balancer can help relieve that.<BR><BR>Hi, Kevin,<BR><BR><BR><BR>I assumed that all agents are connected to same IP address of RabbitMQ,<BR>then the connection will exceed the port ranges limitation.<BR><BR><BR><BR>For a RabbitMQ cluster, for sure the client can connect to any one of<BR>member in the cluster, but in this case, the client has to be designed in<BR>fail-safe manner: the client should be aware of the cluster member failure,<BR>and reconnect to other survive member. No such mechnism has<BR>been implemented yet.<BR><BR><BR><BR>Other way is to use LVS or DNS based like load balancer, or something else.<BR>If you put one load balancer ahead of a cluster, then we have to take care<BR>of the port number limitation, there are so many agents will require<BR>connection concurrently, 100k level, and the requests can not be rejected.<BR><BR><BR><BR>Best Regards<BR><BR><BR><BR>Chaoyi Huang ( joehuang )<BR><BR><BR> ------------------------------<BR>*From:* Kevin Benton [blak111@gmail.com]<BR>*Sent:* 12 April 2015 9:59<BR>*To:* OpenStack Development Mailing List (not for usage questions)<BR>*Subject:* Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR><BR> The TCP/IP stack keeps track of connections as a combination of IP + TCP<BR>port. The two byte port limit doesn't matter unless all of the agents are<BR>connecting from the same IP address, which shouldn't be the case unless<BR>compute nodes connect to the rabbitmq server via one IP address running<BR>port address translation.<BR><BR> Either way, the agents don't connect directly to the Neutron server, they<BR>connect to the rabbit MQ cluster. Since as many Neutron server processes<BR>can be launched as necessary, the bottlenecks will likely show up at the<BR>messaging or DB layer.<BR><BR>On Sat, Apr 11, 2015 at 6:46 PM, joehuang <joehuang@huawei.com> wrote:<BR><BR>> As Kevin talking about agents, I want to remind that in TCP/IP stack,<BR>> port ( not Neutron Port ) is a two bytes field, i.e. port ranges from 0 ~<BR>> 65535, supports maximum 64k port number.<BR>><BR>><BR>><BR>> " above 100k managed node " means more than 100k L2 agents/L3 agents...<BR>> will be alive under Neutron.<BR>><BR>><BR>><BR>> Want to know the detail design how to support 99.9% possibility for<BR>> scaling Neutron in this way, and PoC and test would be a good support for<BR>> this idea.<BR>><BR>><BR>><BR>> "I'm 99.9% sure, for scaling above 100k managed node,<BR>> we do not really need to split the openstack to multiple smaller openstack,<BR>> or use significant number of extra controller machine."<BR>><BR>><BR>><BR>> Best Regards<BR>><BR>><BR>><BR>> Chaoyi Huang ( joehuang )<BR>><BR>><BR>> ------------------------------<BR>> *From:* Kevin Benton [blak111@gmail.com]<BR>> *Sent:* 11 April 2015 12:34<BR>> *To:* OpenStack Development Mailing List (not for usage questions)<BR>> *Subject:* Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>><BR>> Which periodic updates did you have in mind to eliminate? One of the<BR>> few remaining ones I can think of is sync_routers but it would be great if<BR>> you can enumerate the ones you observed because eliminating overhead in<BR>> agents is something I've been working on as well.<BR>><BR>> One of the most common is the heartbeat from each agent. However, I<BR>> don't think we can't eliminate them because they are used to determine if<BR>> the agents are still alive for scheduling purposes. Did you have something<BR>> else in mind to determine if an agent is alive?<BR>><BR>> On Fri, Apr 10, 2015 at 2:18 AM, Attila Fazekas <afazekas@redhat.com><BR>> wrote:<BR>><BR>>> I'm 99.9% sure, for scaling above 100k managed node,<BR>>> we do not really need to split the openstack to multiple smaller<BR>>> openstack,<BR>>> or use significant number of extra controller machine.<BR>>><BR>>> The problem is openstack using the right tools SQL/AMQP/(zk),<BR>>> but in a wrong way.<BR>>><BR>>> For example.:<BR>>> Periodic updates can be avoided almost in all cases<BR>>><BR>>> The new data can be pushed to the agent just when it needed.<BR>>> The agent can know when the AMQP connection become unreliable (queue or<BR>>> connection loose),<BR>>> and needs to do full sync.<BR>>> https://bugs.launchpad.net/neutron/+bug/1438159<BR>>><BR>>> Also the agents when gets some notification, they start asking for<BR>>> details via the<BR>>> AMQP -> SQL. Why they do not know it already or get it with the<BR>>> notification ?<BR>>><BR>>><BR>>> ----- Original Message -----<BR>>> > From: "Neil Jerram" <Neil.Jerram@metaswitch.com><BR>>> > To: "OpenStack Development Mailing List (not for usage questions)" <<BR>>> openstack-dev@lists.openstack.org><BR>>> > Sent: Thursday, April 9, 2015 5:01:45 PM<BR>>> > Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>>> ><BR>>> > Hi Joe,<BR>>> ><BR>>> > Many thanks for your reply!<BR>>> ><BR>>> > On 09/04/15 03:34, joehuang wrote:<BR>>> > > Hi, Neil,<BR>>> > ><BR>>> > > From theoretic, Neutron is like a "broadcast" domain, for example,<BR>>> > > enforcement of DVR and security group has to touch each regarding<BR>>> host<BR>>> > > where there is VM of this project resides. Even using SDN<BR>>> controller, the<BR>>> > > "touch" to regarding host is inevitable. If there are plenty of<BR>>> physical<BR>>> > > hosts, for example, 10k, inside one Neutron, it's very hard to<BR>>> overcome<BR>>> > > the "broadcast storm" issue under concurrent operation, that's the<BR>>> > > bottleneck for scalability of Neutron.<BR>>> ><BR>>> > I think I understand that in general terms - but can you be more<BR>>> > specific about the broadcast storm? Is there one particular message<BR>>> > exchange that involves broadcasting? Is it only from the server to<BR>>> > agents, or are there 'broadcasts' in other directions as well?<BR>>> ><BR>>> > (I presume you are talking about control plane messages here, i.e.<BR>>> > between Neutron components. Is that right? Obviously there can also be<BR>>> > broadcast storm problems in the data plane - but I don't think that's<BR>>> > what you are talking about here.)<BR>>> ><BR>>> > > We need layered architecture in Neutron to solve the "broadcast<BR>>> domain"<BR>>> > > bottleneck of scalability. The test report from OpenStack cascading<BR>>> shows<BR>>> > > that through layered architecture "Neutron cascading", Neutron can<BR>>> > > supports up to million level ports and 100k level physical hosts. You<BR>>> can<BR>>> > > find the report here:<BR>>> > ><BR>>> http://www.slideshare.net/JoeHuang7/test-report-for-open-stack-cascading-solution-to-support-1-million-v-ms-in-100-data-centers<BR>>> ><BR>>> > Many thanks, I will take a look at this.<BR>>> ><BR>>> > > "Neutron cascading" also brings extra benefit: One cascading Neutron<BR>>> can<BR>>> > > have many cascaded Neutrons, and different cascaded Neutron can<BR>>> leverage<BR>>> > > different SDN controller, maybe one is ODL, the other one is<BR>>> OpenContrail.<BR>>> > ><BR>>> > > ----------------Cascading Neutron-------------------<BR>>> > > / \<BR>>> > > --cascaded Neutron-- --cascaded Neutron-----<BR>>> > > | |<BR>>> > > ---------ODL------ ----OpenContrail--------<BR>>> > ><BR>>> > ><BR>>> > > And furthermore, if using Neutron cascading in multiple data centers,<BR>>> the<BR>>> > > DCI controller (Data center inter-connection controller) can also be<BR>>> used<BR>>> > > under cascading Neutron, to provide NaaS ( network as a service )<BR>>> across<BR>>> > > data centers.<BR>>> > ><BR>>> > > ---------------------------Cascading Neutron--------------------------<BR>>> > > / | \<BR>>> > > --cascaded Neutron-- -DCI controller- --cascaded Neutron-----<BR>>> > > | | |<BR>>> > > ---------ODL------ | ----OpenContrail--------<BR>>> > > |<BR>>> > > --(Data center 1)-- --(DCI networking)-- --(Data center 2)--<BR>>> > ><BR>>> > > Is it possible for us to discuss this in OpenStack Vancouver summit?<BR>>> ><BR>>> > Most certainly, yes. I will be there from mid Monday afternoon through<BR>>> > to end Friday. But it will be my first summit, so I have no idea yet as<BR>>> > to how I might run into you - please can you suggest!<BR>>> ><BR>>> > > Best Regards<BR>>> > > Chaoyi Huang ( Joe Huang )<BR>>> ><BR>>> > Regards,<BR>>> > Neil<BR>>> ><BR>>> ><BR>>> __________________________________________________________________________<BR>>> > OpenStack Development Mailing List (not for usage questions)<BR>>> > Unsubscribe:<BR>>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>>> ><BR>>><BR>>> __________________________________________________________________________<BR>>> OpenStack Development Mailing List (not for usage questions)<BR>>> Unsubscribe:<BR>>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>>><BR>><BR>><BR>><BR>> --<BR>> Kevin Benton<BR>><BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>><BR>><BR><BR><BR> --<BR> Kevin Benton<BR><BR>__________________________________________________________________________<BR>OpenStack Development Mailing List (not for usage questions)<BR>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150412/ea01d543/attachment-0001.html><BR><BR>------------------------------<BR><BR>Message: 7<BR>Date: Sun, 12 Apr 2015 12:51:30 -0700<BR>From: Kevin Benton <blak111@gmail.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>Message-ID:<BR><CAO_F6JM61uqXNY_ebNNXKxFNV5-C7wr7A3LSZC_0RY+NMQKcdw@mail.gmail.com><BR>Content-Type: text/plain; charset="utf-8"<BR><BR>>Timestamps are just one way (and likely the most primitive), using redis<BR>(or memcache) key/value and expiry are another (and letting memcache or<BR>redis expire using its own internal algorithms), using zookeeper ephemeral<BR>nodes[1] are another... The point being that its backend specific and tooz<BR>supports varying backends.<BR><BR>Very cool. Is the backend completely transparent so a deployer could choose<BR>a service they are comfortable maintaining, or will that change the<BR>properties WRT to resiliency of state on node restarts, partitions, etc?<BR><BR>The Nova implementation of Tooz seemed pretty straight-forward, although it<BR>looked like it had pluggable drivers for service management already. Before<BR>I dig into it much further I'll file a spec on the Neutron side to see if I<BR>can get some other cores onboard to do the review work if I push a change<BR>to tooz.<BR><BR><BR>On Sun, Apr 12, 2015 at 9:38 AM, Joshua Harlow <harlowja@outlook.com> wrote:<BR><BR>> Kevin Benton wrote:<BR>><BR>>> So IIUC tooz would be handling the liveness detection for the agents.<BR>>> That would be nice to get ride of that logic in Neutron and just<BR>>> register callbacks for rescheduling the dead.<BR>>><BR>>> Where does it store that state, does it persist timestamps to the DB<BR>>> like Neutron does? If so, how would that scale better? If not, who does<BR>>> a given node ask to know if an agent is online or offline when making a<BR>>> scheduling decision?<BR>>><BR>><BR>> Timestamps are just one way (and likely the most primitive), using redis<BR>> (or memcache) key/value and expiry are another (and letting memcache or<BR>> redis expire using its own internal algorithms), using zookeeper ephemeral<BR>> nodes[1] are another... The point being that its backend specific and tooz<BR>> supports varying backends.<BR>><BR>><BR>>> However, before (what I assume is) the large code change to implement<BR>>> tooz, I would like to quantify that the heartbeats are actually a<BR>>> bottleneck. When I was doing some profiling of them on the master branch<BR>>> a few months ago, processing a heartbeat took an order of magnitude less<BR>>> time (<50ms) than the 'sync routers' task of the l3 agent (~300ms). A<BR>>> few query optimizations might buy us a lot more headroom before we have<BR>>> to fall back to large refactors.<BR>>><BR>><BR>> Sure, always good to avoid prematurely optimizing things...<BR>><BR>> Although this is relevant for u I think anyway:<BR>><BR>> https://review.openstack.org/#/c/138607/ (same thing/nearly same in<BR>> nova)...<BR>><BR>> https://review.openstack.org/#/c/172502/ (a WIP implementation of the<BR>> latter).<BR>><BR>> [1] https://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#<BR>> Ephemeral+Nodes<BR>><BR>><BR>>> Kevin Benton wrote:<BR>>><BR>>><BR>>> One of the most common is the heartbeat from each agent. However, I<BR>>> don't think we can't eliminate them because they are used to determine<BR>>> if the agents are still alive for scheduling purposes. Did you have<BR>>> something else in mind to determine if an agent is alive?<BR>>><BR>>><BR>>> Put each agent in a tooz[1] group; have each agent periodically<BR>>> heartbeat[2], have whoever needs to schedule read the active members of<BR>>> that group (or use [3] to get notified via a callback), profit...<BR>>><BR>>> Pick from your favorite (supporting) driver at:<BR>>><BR>>> http://docs.openstack.org/__developer/tooz/compatibility.__html<BR>>> <http://docs.openstack.org/developer/tooz/compatibility.html><BR>>><BR>>> [1]<BR>>> http://docs.openstack.org/__developer/tooz/compatibility.__html#grouping<BR>>> <http://docs.openstack.org/developer/tooz/compatibility.html#grouping><BR>>> [2]<BR>>> https://github.com/openstack/__tooz/blob/0.13.1/tooz/__<BR>>> coordination.py#L315<BR>>> <https://github.com/openstack/tooz/blob/0.13.1/tooz/coordination.py#L315><BR>>> [3]<BR>>> http://docs.openstack.org/__developer/tooz/tutorial/group_<BR>>> __membership.html#watching-__group-changes<BR>>> <http://docs.openstack.org/developer/tooz/tutorial/group_<BR>>> membership.html#watching-group-changes><BR>>><BR>>><BR>>> ____________________________________________________________<BR>>> __________________<BR>>> OpenStack Development Mailing List (not for usage questions)<BR>>> Unsubscribe:<BR>>> OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe<BR>>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><BR>>> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev<BR>>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev><BR>>><BR>>> ____________________________________________________________<BR>>> ______________<BR>>> OpenStack Development Mailing List (not for usage questions)<BR>>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:<BR>>> unsubscribe<BR>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>>><BR>><BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>><BR><BR><BR><BR>-- <BR>Kevin Benton<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150412/c5c3d2dc/attachment-0001.html><BR><BR>------------------------------<BR><BR>Message: 8<BR>Date: Mon, 13 Apr 2015 10:43:57 +1200<BR>From: Robert Collins <robertc@robertcollins.net><BR>To: OpenStack Development Mailing List<BR><openstack-dev@lists.openstack.org><BR>Subject: [openstack-dev] [all][pbr] splitting our deployment vs<BR>install dependencies<BR>Message-ID:<BR><CAJ3HoZ2JLwPJUBRgTLyBZ-z00sVO4TyOupmR4LprjkNMHg9o0g@mail.gmail.com><BR>Content-Type: text/plain; charset=UTF-8<BR><BR>Right now we do something that upstream pip considers wrong: we make<BR>our requirements.txt be our install_requires.<BR><BR>Upstream there are two separate concepts.<BR><BR>install_requirements, which are meant to document what *must* be<BR>installed to import the package, and should encode any mandatory<BR>version constraints while being as loose as otherwise possible. E.g.<BR>if package A depends on package B version 1.5 or above, it should say<BR>B>=1.5 in A's install_requires. They should not specify maximum<BR>versions except when that is known to be a problem: they shouldn't<BR>borrow trouble.<BR><BR>deploy requirements - requirements.txt - which are meant to be *local<BR>to a deployment*, and are commonly expected to specify very narrow (or<BR>even exact fit) versions.<BR><BR>What pbr, which nearly if not all OpenStack projects use, does, is to<BR>map the contents of requirements.txt into install_requires. And then<BR>we use the same requirements.txt in our CI to control whats deployed<BR>in our test environment[*]. and there we often have tight constraints<BR>like seen here -<BR>http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n63<BR><BR>I'd like to align our patterns with those of upstream, so that we're<BR>not fighting our tooling so much.<BR><BR>Concretely, I think we need to:<BR> - teach pbr to read in install_requires from setup.cfg, not requirements.txt<BR> - when there are requirements in setup.cfg, stop reading requirements.txt<BR> - separate out the global intall_requirements from the global CI<BR>requirements, and update our syncing code to be aware of this<BR><BR>Then, setup.cfg contains more open requirements suitable for being on<BR>PyPI, requirements.txt is the local CI set we know works - and can be<BR>much more restrictive as needed.<BR><BR>Thoughts? If there's broad apathy-or-agreement I can turn this into a<BR>spec for fine coverage of ramifications and corner cases.<BR><BR>-Rob<BR><BR>-- <BR>Robert Collins <rbtcollins@hp.com><BR>Distinguished Technologist<BR>HP Converged Cloud<BR><BR><BR><BR>------------------------------<BR><BR>Message: 9<BR>Date: Sun, 12 Apr 2015 19:12:38 -0400<BR>From: Monty Taylor <mordred@inaugust.com><BR>To: openstack-dev@lists.openstack.org<BR>Subject: Re: [openstack-dev] [all][pbr] splitting our deployment vs<BR>install dependencies<BR>Message-ID: <552AFBE6.4010606@inaugust.com><BR>Content-Type: text/plain; charset=windows-1252<BR><BR>On 04/12/2015 06:43 PM, Robert Collins wrote:<BR>> Right now we do something that upstream pip considers wrong: we make<BR>> our requirements.txt be our install_requires.<BR>> <BR>> Upstream there are two separate concepts.<BR>> <BR>> install_requirements, which are meant to document what *must* be<BR>> installed to import the package, and should encode any mandatory<BR>> version constraints while being as loose as otherwise possible. E.g.<BR>> if package A depends on package B version 1.5 or above, it should say<BR>> B>=1.5 in A's install_requires. They should not specify maximum<BR>> versions except when that is known to be a problem: they shouldn't<BR>> borrow trouble.<BR>> <BR>> deploy requirements - requirements.txt - which are meant to be *local<BR>> to a deployment*, and are commonly expected to specify very narrow (or<BR>> even exact fit) versions.<BR><BR>tl;dr - I'm mostly in support of what you're saying - but I'm going to<BR>bludgeon it some.<BR><BR>To be either fair or unfair, depending on how you look at it - some<BR>people upstream consider those two to be a pattern, but it is not<BR>encoded anywhere except in hidden lore that is shared between secret<BR>people. Upstream's tools have bumpkiss for support for this, and if we<BR>hadn't drawn a line in the sand encoding SOME behavior there would still<BR>be nothing.<BR><BR>Nor, btw, is it the right split. It optimizes for the wrong thing.<BR><BR>rust gets it wright. There is a Cargo.toml and a Cargo.lock, which are<BR>understood by the tooling in a manner similar to what you have<BR>described, and it is not just understood but DOCUMENTED that an<BR>_application_ should ship with a Cargo.lock and a _library_ should not.<BR><BR>Without the library/application distinction, the effort in<BR>differentiating is misplaced, I believe - because it's libraries that<BR>need flexible depends - and applications where the specific set of<BR>depends that were tested in CI become important to consumers.<BR><BR>> What pbr, which nearly if not all OpenStack projects use, does, is to<BR>> map the contents of requirements.txt into install_requires. And then<BR>> we use the same requirements.txt in our CI to control whats deployed<BR>> in our test environment[*]. and there we often have tight constraints<BR>> like seen here -<BR>> http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n63<BR><BR>That is, btw, because that's what the overwhelming majority of consumers<BR>assume those files mean. I take "overwhelming majority" from the days<BR>when we had files but did not process them automatically and everyone<BR>was confused.<BR><BR>> I'd like to align our patterns with those of upstream, so that we're<BR>> not fighting our tooling so much.<BR><BR>Ok. I mean, they don't have a better answer, but if it makes "python"<BR>hate us less, sweet.<BR><BR>> Concretely, I think we need to:<BR>> - teach pbr to read in install_requires from setup.cfg, not requirements.txt<BR>> - when there are requirements in setup.cfg, stop reading requirements.txt<BR>> - separate out the global intall_requirements from the global CI<BR>> requirements, and update our syncing code to be aware of this<BR>> <BR>> Then, setup.cfg contains more open requirements suitable for being on<BR>> PyPI, requirements.txt is the local CI set we know works - and can be<BR>> much more restrictive as needed.<BR>> <BR>> Thoughts? If there's broad apathy-or-agreement I can turn this into a<BR>> spec for fine coverage of ramifications and corner cases.<BR><BR>I'm concerned that it adds a layer of difference that is confusing to<BR>people for the sole benefit of pleasing someone else's pedantic worldview.<BR><BR>I'm also concerned that dstufft is actively wanting to move towards a<BR>world where the build tooling is not needed or used as part of the<BR>install pipeline (metadata 2.0) -- so I'm concerned that we're aligning<BR>with a pattern that isn't very robust and isn't supported by tooling<BR>directly and that we're going to need to change understood usage<BR>patterns across a large developer based to chase something that _still_<BR>isn't going to be "how people do it"<BR><BR>I'm concerned that "how people do it" is a myth not worth chasing.<BR><BR>I'm not _opposed_ to making this richer and more useful for people. I<BR>just don't know what's broken currently for us.<BR><BR>Monty<BR><BR><BR><BR>------------------------------<BR><BR>Message: 10<BR>Date: Mon, 13 Apr 2015 10:01:44 +1000<BR>From: James Polley <jp@jamezpolley.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [all][pbr] splitting our deployment vs<BR>install dependencies<BR>Message-ID:<BR><CAPtRfUEoLc0KQoqPaHffxXevGwCiXaExm3Kx2oJWzNGFjL3NWA@mail.gmail.com><BR>Content-Type: text/plain; charset="utf-8"<BR><BR>On Mon, Apr 13, 2015 at 9:12 AM, Monty Taylor <mordred@inaugust.com> wrote:<BR><BR>> On 04/12/2015 06:43 PM, Robert Collins wrote:<BR>> > Right now we do something that upstream pip considers wrong: we make<BR>> > our requirements.txt be our install_requires.<BR>> ><BR>> > Upstream there are two separate concepts.<BR>> ><BR>> > install_requirements, which are meant to document what *must* be<BR>> > installed to import the package, and should encode any mandatory<BR>> > version constraints while being as loose as otherwise possible. E.g.<BR>> > if package A depends on package B version 1.5 or above, it should say<BR>> > B>=1.5 in A's install_requires. They should not specify maximum<BR>> > versions except when that is known to be a problem: they shouldn't<BR>> > borrow trouble.<BR>> ><BR>> > deploy requirements - requirements.txt - which are meant to be *local<BR>> > to a deployment*, and are commonly expected to specify very narrow (or<BR>> > even exact fit) versions.<BR>><BR><BR>That sounds, to me, very similar to a discussion we had a few weeks ago in<BR>the context of our stable branches.<BR><BR>In that context, we have two competing requirements. One requirement is<BR>that our CI system wants a very tightly pinned requirements, as do<BR>downstream CI systems and deployers that want to test and deploy exact<BR>known-tested versions of things. On the other hand, downstream distributors<BR>(including OS packagers) need to balance OpenStack's version requirements<BR>with version requirements from all the other packages in their<BR>distribution; the tighter the requirements we list are, the harder it is<BR>for the requirements to work with the requirements of other packages in the<BR>distribution.<BR><BR><BR>> tl;dr - I'm mostly in support of what you're saying - but I'm going to<BR>> bludgeon it some.<BR>><BR>> To be either fair or unfair, depending on how you look at it - some<BR>> people upstream consider those two to be a pattern, but it is not<BR>> encoded anywhere except in hidden lore that is shared between secret<BR>> people. Upstream's tools have bumpkiss for support for this, and if we<BR>> hadn't drawn a line in the sand encoding SOME behavior there would still<BR>> be nothing.<BR>><BR>> Nor, btw, is it the right split. It optimizes for the wrong thing.<BR>><BR>> rust gets it wright. There is a Cargo.toml and a Cargo.lock, which are<BR>> understood by the tooling in a manner similar to what you have<BR>> described, and it is not just understood but DOCUMENTED that an<BR>> _application_ should ship with a Cargo.lock and a _library_ should not.<BR>><BR><BR>This sounds similar to a solution that was proposed for the stable<BR>branches: a requirements.in with mandatory version constraints while being<BR>as loose as otherwise possible, which is used to generate a<BR>requirements.txt which has the "local to deployment" exact versions that<BR>are used in our CI. The details of the proposal are in<BR>https://review.openstack.org/#/c/161047/<BR><BR><BR>> Without the library/application distinction, the effort in<BR>> differentiating is misplaced, I believe - because it's libraries that<BR>> need flexible depends - and applications where the specific set of<BR>> depends that were tested in CI become important to consumers.<BR>><BR>> > What pbr, which nearly if not all OpenStack projects use, does, is to<BR>> > map the contents of requirements.txt into install_requires. And then<BR>> > we use the same requirements.txt in our CI to control whats deployed<BR>> > in our test environment[*]. and there we often have tight constraints<BR>> > like seen here -<BR>> ><BR>> http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n63<BR>><BR>> That is, btw, because that's what the overwhelming majority of consumers<BR>> assume those files mean. I take "overwhelming majority" from the days<BR>> when we had files but did not process them automatically and everyone<BR>> was confused.<BR>><BR>> > I'd like to align our patterns with those of upstream, so that we're<BR>> > not fighting our tooling so much.<BR>><BR>> Ok. I mean, they don't have a better answer, but if it makes "python"<BR>> hate us less, sweet.<BR>><BR>> > Concretely, I think we need to:<BR>> > - teach pbr to read in install_requires from setup.cfg, not<BR>> requirements.txt<BR>> > - when there are requirements in setup.cfg, stop reading<BR>> requirements.txt<BR>> > - separate out the global intall_requirements from the global CI<BR>> > requirements, and update our syncing code to be aware of this<BR>> ><BR>> > Then, setup.cfg contains more open requirements suitable for being on<BR>> > PyPI, requirements.txt is the local CI set we know works - and can be<BR>> > much more restrictive as needed.<BR>> ><BR>> > Thoughts? If there's broad apathy-or-agreement I can turn this into a<BR>> > spec for fine coverage of ramifications and corner cases.<BR>><BR>> I'm concerned that it adds a layer of difference that is confusing to<BR>> people for the sole benefit of pleasing someone else's pedantic worldview.<BR>><BR>> I'm also concerned that dstufft is actively wanting to move towards a<BR>> world where the build tooling is not needed or used as part of the<BR>> install pipeline (metadata 2.0) -- so I'm concerned that we're aligning<BR>> with a pattern that isn't very robust and isn't supported by tooling<BR>> directly and that we're going to need to change understood usage<BR>> patterns across a large developer based to chase something that _still_<BR>> isn't going to be "how people do it"<BR>><BR>> I'm concerned that "how people do it" is a myth not worth chasing.<BR>><BR>> I'm not _opposed_ to making this richer and more useful for people. I<BR>> just don't know what's broken currently for us.<BR>><BR><BR>To be clear, I don't mean to suggest that the solution proposed in<BR>https://review.openstack.org/#/c/161047/ is necessarily the correct<BR>solution to this problem - but I do think that it is illustrative of at<BR>last one thing that's currently broken for us.<BR><BR><BR>> Monty<BR>><BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150413/4e267c09/attachment-0001.html><BR><BR>------------------------------<BR><BR>Message: 11<BR>Date: Sun, 12 Apr 2015 20:53:50 -0400<BR>From: Monty Taylor <mordred@inaugust.com><BR>To: openstack-dev@lists.openstack.org<BR>Subject: Re: [openstack-dev] [all][pbr] splitting our deployment vs<BR>install dependencies<BR>Message-ID: <552B139E.5010007@inaugust.com><BR>Content-Type: text/plain; charset=windows-1252<BR><BR>On 04/12/2015 08:01 PM, James Polley wrote:<BR>> On Mon, Apr 13, 2015 at 9:12 AM, Monty Taylor <mordred@inaugust.com> wrote:<BR>> <BR>>> On 04/12/2015 06:43 PM, Robert Collins wrote:<BR>>>> Right now we do something that upstream pip considers wrong: we make<BR>>>> our requirements.txt be our install_requires.<BR>>>><BR>>>> Upstream there are two separate concepts.<BR>>>><BR>>>> install_requirements, which are meant to document what *must* be<BR>>>> installed to import the package, and should encode any mandatory<BR>>>> version constraints while being as loose as otherwise possible. E.g.<BR>>>> if package A depends on package B version 1.5 or above, it should say<BR>>>> B>=1.5 in A's install_requires. They should not specify maximum<BR>>>> versions except when that is known to be a problem: they shouldn't<BR>>>> borrow trouble.<BR>>>><BR>>>> deploy requirements - requirements.txt - which are meant to be *local<BR>>>> to a deployment*, and are commonly expected to specify very narrow (or<BR>>>> even exact fit) versions.<BR>>><BR>> <BR>> That sounds, to me, very similar to a discussion we had a few weeks ago in<BR>> the context of our stable branches.<BR>> <BR>> In that context, we have two competing requirements. One requirement is<BR>> that our CI system wants a very tightly pinned requirements, as do<BR>> downstream CI systems and deployers that want to test and deploy exact<BR>> known-tested versions of things. On the other hand, downstream distributors<BR>> (including OS packagers) need to balance OpenStack's version requirements<BR>> with version requirements from all the other packages in their<BR>> distribution; the tighter the requirements we list are, the harder it is<BR>> for the requirements to work with the requirements of other packages in the<BR>> distribution.<BR><BR>This is not accurate. During distro packaging activities, pbr does not<BR>process dependencies at all. So no matter how we pin things in<BR>OpenStack, it does not make it harder for the distros.<BR><BR>>> tl;dr - I'm mostly in support of what you're saying - but I'm going to<BR>>> bludgeon it some.<BR>>><BR>>> To be either fair or unfair, depending on how you look at it - some<BR>>> people upstream consider those two to be a pattern, but it is not<BR>>> encoded anywhere except in hidden lore that is shared between secret<BR>>> people. Upstream's tools have bumpkiss for support for this, and if we<BR>>> hadn't drawn a line in the sand encoding SOME behavior there would still<BR>>> be nothing.<BR>>><BR>>> Nor, btw, is it the right split. It optimizes for the wrong thing.<BR>>><BR>>> rust gets it wright. There is a Cargo.toml and a Cargo.lock, which are<BR>>> understood by the tooling in a manner similar to what you have<BR>>> described, and it is not just understood but DOCUMENTED that an<BR>>> _application_ should ship with a Cargo.lock and a _library_ should not.<BR>>><BR>> <BR>> This sounds similar to a solution that was proposed for the stable<BR>> branches: a requirements.in with mandatory version constraints while being<BR>> as loose as otherwise possible, which is used to generate a<BR>> requirements.txt which has the "local to deployment" exact versions that<BR>> are used in our CI. The details of the proposal are in<BR>> https://review.openstack.org/#/c/161047/<BR><BR>I disagree with this proposal. It's also not helping any users. Because<BR>of what I said above, there is no flexibility that we lose downstream by<BR>being strict and pedantic with our versions. So, having the "lose" and<BR>the "strict" file just gets us two files and doubles the confusion.<BR>Having a list of what we know the state to be is great. We should give<BR>that to users. If they want to use something other than pip to install,<BR>awesome - the person in charge of curating that content can test the<BR>version interactions in their environment.<BR><BR>What we have in the gate is the thing that produces the artifacts that<BR>someone installing using the pip tool would get. Shipping anything with<BR>those artifacts other that a direct communication of what we tested is<BR>just mean to our end users.<BR><BR>> <BR>>> Without the library/application distinction, the effort in<BR>>> differentiating is misplaced, I believe - because it's libraries that<BR>>> need flexible depends - and applications where the specific set of<BR>>> depends that were tested in CI become important to consumers.<BR>>><BR>>>> What pbr, which nearly if not all OpenStack projects use, does, is to<BR>>>> map the contents of requirements.txt into install_requires. And then<BR>>>> we use the same requirements.txt in our CI to control whats deployed<BR>>>> in our test environment[*]. and there we often have tight constraints<BR>>>> like seen here -<BR>>>><BR>>> http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n63<BR>>><BR>>> That is, btw, because that's what the overwhelming majority of consumers<BR>>> assume those files mean. I take "overwhelming majority" from the days<BR>>> when we had files but did not process them automatically and everyone<BR>>> was confused.<BR>>><BR>>>> I'd like to align our patterns with those of upstream, so that we're<BR>>>> not fighting our tooling so much.<BR>>><BR>>> Ok. I mean, they don't have a better answer, but if it makes "python"<BR>>> hate us less, sweet.<BR>>><BR>>>> Concretely, I think we need to:<BR>>>> - teach pbr to read in install_requires from setup.cfg, not<BR>>> requirements.txt<BR>>>> - when there are requirements in setup.cfg, stop reading<BR>>> requirements.txt<BR>>>> - separate out the global intall_requirements from the global CI<BR>>>> requirements, and update our syncing code to be aware of this<BR>>>><BR>>>> Then, setup.cfg contains more open requirements suitable for being on<BR>>>> PyPI, requirements.txt is the local CI set we know works - and can be<BR>>>> much more restrictive as needed.<BR>>>><BR>>>> Thoughts? If there's broad apathy-or-agreement I can turn this into a<BR>>>> spec for fine coverage of ramifications and corner cases.<BR>>><BR>>> I'm concerned that it adds a layer of difference that is confusing to<BR>>> people for the sole benefit of pleasing someone else's pedantic worldview.<BR>>><BR>>> I'm also concerned that dstufft is actively wanting to move towards a<BR>>> world where the build tooling is not needed or used as part of the<BR>>> install pipeline (metadata 2.0) -- so I'm concerned that we're aligning<BR>>> with a pattern that isn't very robust and isn't supported by tooling<BR>>> directly and that we're going to need to change understood usage<BR>>> patterns across a large developer based to chase something that _still_<BR>>> isn't going to be "how people do it"<BR>>><BR>>> I'm concerned that "how people do it" is a myth not worth chasing.<BR>>><BR>>> I'm not _opposed_ to making this richer and more useful for people. I<BR>>> just don't know what's broken currently for us.<BR>>><BR>> <BR>> To be clear, I don't mean to suggest that the solution proposed in<BR>> https://review.openstack.org/#/c/161047/ is necessarily the correct<BR>> solution to this problem - but I do think that it is illustrative of at<BR>> last one thing that's currently broken for us.<BR><BR>I disagree that anything is broken for us that is not caused by our<BR>inability to remember that distro packaging concerns are not the same as<BR>our concerns, and that the mechanism already exists for distro pacakgers<BR>to do what they want. Furthermore, it is caused by an insistence that we<BR>need to keep versions "open" for some ephemeral reason such as "upstream<BR>might release a bug fix" Since we all know that "if it's not tested,<BR>it's broken" - any changes to upstream software should be considered<BR>broken until proven otherwise. History over the last 5 years has shown<BR>this to be accurate more than the other thing.<BR><BR>If we pin the stable branches with hard pins of direct and indirect<BR>dependencies, we can have our stable branch artifacts be installable.<BR>Thats awesome. IF there is a bugfix release or a security update to a<BR>dependent library - someone can propose it. Otherwise, the stable<BR>release should not be moving.<BR><BR>Monty<BR><BR><BR><BR>------------------------------<BR><BR>Message: 12<BR>Date: Mon, 13 Apr 2015 13:02:13 +1200<BR>From: Robert Collins <robertc@robertcollins.net><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [all][pbr] splitting our deployment vs<BR>install dependencies<BR>Message-ID:<BR><CAJ3HoZ2N9+EvsN0WkO2tiQLPKDi9q2tX_Qk8JRskdz+EX5+vBw@mail.gmail.com><BR>Content-Type: text/plain; charset=UTF-8<BR><BR>On 13 April 2015 at 12:01, James Polley <jp@jamezpolley.com> wrote:<BR>><BR>><BR><BR>> That sounds, to me, very similar to a discussion we had a few weeks ago in<BR>> the context of our stable branches.<BR>><BR>> In that context, we have two competing requirements. One requirement is that<BR>> our CI system wants a very tightly pinned requirements, as do downstream CI<BR>> systems and deployers that want to test and deploy exact known-tested<BR>> versions of things. On the other hand, downstream distributors (including OS<BR>> packagers) need to balance OpenStack's version requirements with version<BR>> requirements from all the other packages in their distribution; the tighter<BR>> the requirements we list are, the harder it is for the requirements to work<BR>> with the requirements of other packages in the distribution.<BR><BR>They are analogous yes.<BR>..<BR>>> rust gets it wright. There is a Cargo.toml and a Cargo.lock, which are<BR>>> understood by the tooling in a manner similar to what you have<BR>>> described, and it is not just understood but DOCUMENTED that an<BR>>> _application_ should ship with a Cargo.lock and a _library_ should not.<BR>><BR>> This sounds similar to a solution that was proposed for the stable branches:<BR>> a requirements.in with mandatory version constraints while being as loose as<BR>> otherwise possible, which is used to generate a requirements.txt which has<BR>> the "local to deployment" exact versions that are used in our CI. The<BR>> details of the proposal are in https://review.openstack.org/#/c/161047/<BR><BR>That proposal is still under discussion, and seems stuck between the<BR>distro and -infra folk. *if* it ends up doing the transitive thing, I<BR>think that that would make a sensible requirements.txt, yes. However<BR>see the spec for that thread of discussion.<BR>.<BR>>> I'm also concerned that dstufft is actively wanting to move towards a<BR>>> world where the build tooling is not needed or used as part of the<BR>>> install pipeline (metadata 2.0) -- so I'm concerned that we're aligning<BR>>> with a pattern that isn't very robust and isn't supported by tooling<BR>>> directly and that we're going to need to change understood usage<BR>>> patterns across a large developer based to chase something that _still_<BR>>> isn't going to be "how people do it"<BR><BR>Monty:<BR>So wheels are already in that space. metadata-2.0 is about bringing<BR>that declarative stuff forward in the pipeline, from binary packages<BR>to source packages. I'm currently using frustration based development<BR>to bring it in at the start - for developers, in the lead-in to source<BR>packages.<BR><BR>So you're concerned - but about what specifically? What goes wrong<BR>with wheels (not wheels with C code). Whats not robust about the<BR>pattern? The cargo package manager you referred to is entirely<BR>declarative....<BR><BR>James: I don't think the binary distribution stuff is relevant to my<BR>discussion, since I'm talking entirely about 'using-pip' use cases,<BR>whereas dpkg and rpm packages don't use that at all.<BR><BR>-Rob<BR><BR>-- <BR>Robert Collins <rbtcollins@hp.com><BR>Distinguished Technologist<BR>HP Converged Cloud<BR><BR><BR><BR>------------------------------<BR><BR>Message: 13<BR>Date: Mon, 13 Apr 2015 13:09:44 +1200<BR>From: Robert Collins <robertc@robertcollins.net><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [all][pbr] splitting our deployment vs<BR>install dependencies<BR>Message-ID:<BR><CAJ3HoZ0_O6y3tmc15xaO-P_04R8zFGUceQEUmd_6w9Q7Bk_vOg@mail.gmail.com><BR>Content-Type: text/plain; charset=UTF-8<BR><BR>On 13 April 2015 at 12:53, Monty Taylor <mordred@inaugust.com> wrote:<BR><BR>> What we have in the gate is the thing that produces the artifacts that<BR>> someone installing using the pip tool would get. Shipping anything with<BR>> those artifacts other that a direct communication of what we tested is<BR>> just mean to our end users.<BR><BR>Actually its not.<BR><BR>What we test is point in time. At 2:45 UTC on Monday installing this<BR>git ref of nova worked.<BR><BR>Noone can reconstruct that today.<BR><BR>I entirely agree with the sentiment you're expressing, but we're not<BR>delivering that sentiment today.<BR><BR>We need to balance the inability to atomically update things - which<BR>forces a degree of freedom on install_requires - with being able to<BR>give someone the same install that we tested.<BR><BR>That is the fundamental tension that we're not handling well, nor have<BR>I seen a proposal to tackle it so far.<BR><BR>I'll have to spend some time noodling on this, but one of the clear<BR>constraints is that install_requires cannot both be:<BR> - flexible enough to permit us to upgrade requirements across many<BR>git based packages [because we could do coordinated releases of sdists<BR>to approximate atomic bulk changes]<BR> - tight enough enough to give the next person trying to run that ref<BR>of the package the same things we installed in CI.<BR><BR>-> I think we need something other than install_requires<BR><BR>..<BR>> I disagree that anything is broken for us that is not caused by our<BR>> inability to remember that distro packaging concerns are not the same as<BR>> our concerns, and that the mechanism already exists for distro pacakgers<BR>> to do what they want. Furthermore, it is caused by an insistence that we<BR>> need to keep versions "open" for some ephemeral reason such as "upstream<BR>> might release a bug fix" Since we all know that "if it's not tested,<BR>> it's broken" - any changes to upstream software should be considered<BR>> broken until proven otherwise. History over the last 5 years has shown<BR>> this to be accurate more than the other thing.<BR><BR>This seems like a strong argument for really being able to reconstruct<BR>what was in CI.<BR><BR>> If we pin the stable branches with hard pins of direct and indirect<BR>> dependencies, we can have our stable branch artifacts be installable.<BR>> Thats awesome. IF there is a bugfix release or a security update to a<BR>> dependent library - someone can propose it. Otherwise, the stable<BR>> release should not be moving.<BR><BR>Can we do that in stable branches? We've still got the problem of<BR>bumping dependencies across multiple packages.<BR><BR>-Rob<BR><BR>-- <BR>Robert Collins <rbtcollins@hp.com><BR>Distinguished Technologist<BR>HP Converged Cloud<BR><BR><BR><BR>------------------------------<BR><BR>Message: 14<BR>Date: Sun, 12 Apr 2015 20:14:00 -0500<BR>From: Brant Knudson <blk@acm.org><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: [openstack-dev] [all] Problems with keystoneclient stable<BR>branch (and maybe yours too)<BR>Message-ID:<BR><CAHjeE=Qw1E=bKfKCuEvqckgZpG0VOjAsjYpdVJjOF0fBtVTEJA@mail.gmail.com><BR>Content-Type: text/plain; charset="utf-8"<BR><BR>There were several problems with the keystoneclient stable/juno branch that<BR>have been or are in the process of being fixed since its creation.<BR>Hopefully this note will be useful to other projects that create stable<BR>branches for their libraries.<BR><BR><BR>1) Unit tests didn't pass with earlier packages<BR><BR>The supported versions of several of the packages in requirements.txt in<BR>the stable branch are in the process of being capped[0], so that the tests<BR>are now running with older versions of the packages. Since we don't<BR>normally test with the older packages we didn't know that the<BR>keystoneclient unit tests don't actually pass with the old version of the<BR>package. This is fixed by correcting the tests to work with the older<BR>versions of the packages.[1][2]<BR><BR>[0] https://review.openstack.org/#/c/172220/<BR>[1] https://review.openstack.org/#/c/172655/<BR>[2] https://review.openstack.org/#/c/172256/<BR><BR>It would be great if we were testing with the minimum versions of the<BR>packages that we say we support somehow since that would have caught this.<BR><BR><BR>2) Incorrect cap in requirements.txt<BR><BR>python-keystoneclient in stable/juno was capped at <=1.1.0, and 1.1.0 is<BR>the version tagged for the stable branch. When you create a review in<BR>stable/juno it installs python-keystoneclient and now the system has got a<BR>version like 1.1.0.post1, which is >1.1.0, so now python-keystoneclient<BR>doesn't match the requirements and swift-proxy fails to start (swift-proxy<BR>is very good at catching this problem for whatever reason). The cap should<BR>have been <1.2.0 so that we can propose patches and also make fix releases<BR>(1.1.1, 1.1.2, etc.).[3]<BR><BR>[3] https://review.openstack.org/#/c/172718/<BR><BR>I tried to recap all of the clients but that didn't pass Jenkins, probably<BR>because one or more clients didn't use semver correctly and have<BR>requirements updates in a micro release.[4]<BR><BR>[4] https://review.openstack.org/#/c/172719/<BR><BR><BR>3) Unsupported functional tests<BR><BR>We added support for functional tests (tox -e functional) in K, but Jenkins<BR>was configured to run the functional job on all branches and it fails when<BR>the tox target doesn't exist. The fix was to exclude the current stable/<BR>branches for keystoneclient.[5]<BR><BR>[5] https://review.openstack.org/#/c/172658/<BR><BR><BR>4) Tempest -juno job?<BR><BR>For some reason keystoneclient has 2 tempest-neutron jobs:<BR>gate-tempest-dsvm-neutron-src-python-keystoneclient and<BR>..-keystoneclient-juno , and the -juno job is failing in stable/juno. It<BR>didn't make sense to me that we needed to run both in python-keystoneclient<BR>stable/juno. I was told that we didn't need the -juno one anymore on any<BR>branch since we have a stable/juno branch, so that job is removed.[6]<BR><BR>[6] https://review.openstack.org/#/c/172662/<BR><BR><BR>Hopefully with these changes the python-keystoneclient stable/juno branch<BR>will be working.<BR><BR>- Brant<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150412/2a0e52d7/attachment-0001.html><BR><BR>------------------------------<BR><BR>Message: 15<BR>Date: Mon, 13 Apr 2015 11:33:25 +1000<BR>From: Michael Still <mikal@stillhq.com><BR>To: OpenStack Development Mailing List<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] In loving memory of Chris Yeoh<BR>Message-ID:<BR><CAEd1pt7j2JutUjihkx1-S1ikZ_mZ_QHrMEhNMsUTkx7G7gY-GQ@mail.gmail.com><BR>Content-Type: text/plain; charset=UTF-8<BR><BR>Hi, as promised I now have details of a charity for people to donate<BR>to in Chris' memory:<BR><BR> http://participate.freetobreathe.org/site/TR?px=1582460&fr_id=2710&pg=personal#.VSscH5SUd90<BR><BR>In the words of the family:<BR><BR>"We would prefer that people donate to lung cancer research in lieu of<BR>flowers. Lung cancer has the highest mortality rate out of all the<BR>cancers, and the lowest funding out of all the cancers. There is a<BR>stigma attached that lung cancer is a smoker's disease, and that<BR>sufferers deserve their fate. They bring it on through lifestyle<BR>choice. Except that Chris has never smoked in his life, like a<BR>surprisingly large percentage of lung cancer sufferers. These people<BR>suffer for the incorrect beliefs of the masses, and those that are<BR>left behind are equally innocent. We shouldn't be doing this now. He<BR>shouldn't be gone. We need to do more to fix this. There will be<BR>charity envelopes available at the funeral, or you can choose your<BR>preferred research to fund, should you wish to do so. You have our<BR>thanks."<BR><BR>Michael<BR><BR>On Wed, Apr 8, 2015 at 2:49 PM, Michael Still <mikal@stillhq.com> wrote:<BR>> It is my sad duty to inform the community that Chris Yeoh passed away this<BR>> morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will<BR>> remember Chris as the clever and caring person that I will remember him as.<BR>> I haven?t had a chance to confirm with the family if they want flowers or a<BR>> donation to a charity. As soon as I know those details I will reply to this<BR>> email.<BR>><BR>> Chris worked on open source for a very long time, with OpenStack being just<BR>> the most recent in a long chain of contributions. He worked tirelessly on<BR>> his contributions to Nova, including mentoring other developers. He was<BR>> dedicated to the cause, with a strong vision of what OpenStack could become.<BR>> He even named his cat after the project.<BR>><BR>> Chris might be the only person to have ever sent an email to his coworkers<BR>> explaining what his code review strategy would be after brain surgery. It<BR>> takes phenomenal strength to carry on in the face of that kind of adversity,<BR>> but somehow he did. Frankly, I think I would have just sat on the beach.<BR>><BR>> Chris was also a contributor to the Linux Standards Base (LSB), where he<BR>> helped improve the consistency and interoperability between Linux<BR>> distributions. He ran the ?Hackfest? programming contests for a number of<BR>> years at Australia?s open source conference -- linux.conf.au. He supported<BR>> local Linux user groups in South Australia and Canberra, including<BR>> involvement at installfests and speaking at local meetups. He competed in a<BR>> programming challenge called Loki Hack, and beat out the world to win the<BR>> event[1].<BR>><BR>> Alyssa?s memories of her dad need to last her a long time, so we?ve decided<BR>> to try and collect some fond memories of Chris to help her along the way. If<BR>> you feel comfortable doing so, please contribute a memory or two at<BR>> https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform<BR>><BR>> Chris was humble, helpful and honest. The OpenStack and broader Open Source<BR>> communities are poorer for his passing.<BR>><BR>> Michael<BR>><BR>> [1] http://www.lokigames.com/hack/<BR><BR><BR><BR>-- <BR>Rackspace Australia<BR><BR><BR><BR>------------------------------<BR><BR>Message: 16<BR>Date: Mon, 13 Apr 2015 13:53:36 +1200<BR>From: Robert Collins <robertc@robertcollins.net><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [all][pbr] splitting our deployment vs<BR>install dependencies<BR>Message-ID:<BR><CAJ3HoZ3RKSi8TQLnbS=eWFekOxztVtkE2EE+xFoXWvVnKUoBWw@mail.gmail.com><BR>Content-Type: text/plain; charset=UTF-8<BR><BR>On 13 April 2015 at 13:09, Robert Collins <robertc@robertcollins.net> wrote:<BR>> On 13 April 2015 at 12:53, Monty Taylor <mordred@inaugust.com> wrote:<BR>><BR>>> What we have in the gate is the thing that produces the artifacts that<BR>>> someone installing using the pip tool would get. Shipping anything with<BR>>> those artifacts other that a direct communication of what we tested is<BR>>> just mean to our end users.<BR>><BR>> Actually its not.<BR>><BR>> What we test is point in time. At 2:45 UTC on Monday installing this<BR>> git ref of nova worked.<BR>><BR>> Noone can reconstruct that today.<BR>><BR>> I entirely agree with the sentiment you're expressing, but we're not<BR>> delivering that sentiment today.<BR><BR>This observation led to yet more IRC discussion and eventually<BR>https://etherpad.openstack.org/p/stable-omg-deps<BR><BR>In short, the proposal is that we:<BR> - stop trying to use install_requires to reproduce exactly what<BR>works, and instead use it to communicate known constraints (> X, Y is<BR>broken etc).<BR> - use a requirements.txt file we create *during* CI to capture<BR>exactly what worked, and also capture the dpkg and rpm versions of<BR>packages that were present when it worked, and so on. So we'll build a<BR>git tree where its history is an audit trail of exactly what worked<BR>for everything that passed CI, formatted to make it really really easy<BR>for other people to consume.<BR><BR>-Rob<BR><BR>-- <BR>Robert Collins <rbtcollins@hp.com><BR>Distinguished Technologist<BR>HP Converged Cloud<BR><BR><BR><BR>------------------------------<BR><BR>Message: 17<BR>Date: Mon, 13 Apr 2015 02:17:22 +0000<BR>From: joehuang <joehuang@huawei.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>Message-ID:<BR><5E7A3D1BF5FD014E86E5F971CF446EFF54256EDB@szxema505-mbs.china.huawei.com><BR><BR>Content-Type: text/plain; charset="utf-8"<BR><BR>Hi, Kevin and Joshua,<BR><BR>As my understanding, Tooz only addresses the issue of agent status management, but how to solve the concurrent dynamic load impact on large scale ( for example 100k managed nodes with the dynamic load like security goup rule update, routers_updated, etc )<BR><BR>And one more question is, if we have 100k managed nodes, how to do the partition? Or all nodes will be managed by one Tooz service, like Zookeeper? Can Zookeeper manage 100k nodes status?<BR><BR>Best Regards<BR>Chaoyi Huang ( Joe Huang )<BR><BR>From: Kevin Benton [mailto:blak111@gmail.com]<BR>Sent: Monday, April 13, 2015 3:52 AM<BR>To: OpenStack Development Mailing List (not for usage questions)<BR>Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR><BR>>Timestamps are just one way (and likely the most primitive), using redis (or memcache) key/value and expiry are another (and letting memcache or redis expire using its own internal algorithms), using zookeeper ephemeral nodes[1] are another... The point being that its backend specific and tooz supports varying backends.<BR><BR>Very cool. Is the backend completely transparent so a deployer could choose a service they are comfortable maintaining, or will that change the properties WRT to resiliency of state on node restarts, partitions, etc?<BR><BR>The Nova implementation of Tooz seemed pretty straight-forward, although it looked like it had pluggable drivers for service management already. Before I dig into it much further I'll file a spec on the Neutron side to see if I can get some other cores onboard to do the review work if I push a change to tooz.<BR><BR><BR>On Sun, Apr 12, 2015 at 9:38 AM, Joshua Harlow <harlowja@outlook.com<mailto:harlowja@outlook.com>> wrote:<BR>Kevin Benton wrote:<BR>So IIUC tooz would be handling the liveness detection for the agents.<BR>That would be nice to get ride of that logic in Neutron and just<BR>register callbacks for rescheduling the dead.<BR><BR>Where does it store that state, does it persist timestamps to the DB<BR>like Neutron does? If so, how would that scale better? If not, who does<BR>a given node ask to know if an agent is online or offline when making a<BR>scheduling decision?<BR><BR>Timestamps are just one way (and likely the most primitive), using redis (or memcache) key/value and expiry are another (and letting memcache or redis expire using its own internal algorithms), using zookeeper ephemeral nodes[1] are another... The point being that its backend specific and tooz supports varying backends.<BR><BR>However, before (what I assume is) the large code change to implement<BR>tooz, I would like to quantify that the heartbeats are actually a<BR>bottleneck. When I was doing some profiling of them on the master branch<BR>a few months ago, processing a heartbeat took an order of magnitude less<BR>time (<50ms) than the 'sync routers' task of the l3 agent (~300ms). A<BR>few query optimizations might buy us a lot more headroom before we have<BR>to fall back to large refactors.<BR><BR>Sure, always good to avoid prematurely optimizing things...<BR><BR>Although this is relevant for u I think anyway:<BR><BR>https://review.openstack.org/#/c/138607/ (same thing/nearly same in nova)...<BR><BR>https://review.openstack.org/#/c/172502/ (a WIP implementation of the latter).<BR><BR>[1] https://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#Ephemeral+Nodes<BR><BR>Kevin Benton wrote:<BR><BR><BR> One of the most common is the heartbeat from each agent. However, I<BR> don't think we can't eliminate them because they are used to determine<BR> if the agents are still alive for scheduling purposes. Did you have<BR> something else in mind to determine if an agent is alive?<BR><BR><BR>Put each agent in a tooz[1] group; have each agent periodically<BR>heartbeat[2], have whoever needs to schedule read the active members of<BR>that group (or use [3] to get notified via a callback), profit...<BR><BR>Pick from your favorite (supporting) driver at:<BR><BR>http://docs.openstack.org/__developer/tooz/compatibility.__html<BR><http://docs.openstack.org/developer/tooz/compatibility.html><BR><BR>[1]<BR>http://docs.openstack.org/__developer/tooz/compatibility.__html#grouping<BR><http://docs.openstack.org/developer/tooz/compatibility.html#grouping><BR>[2]<BR>https://github.com/openstack/__tooz/blob/0.13.1/tooz/__coordination.py#L315<BR><https://github.com/openstack/tooz/blob/0.13.1/tooz/coordination.py#L315><BR>[3]<BR>http://docs.openstack.org/__developer/tooz/tutorial/group___membership.html#watching-__group-changes<BR><http://docs.openstack.org/developer/tooz/tutorial/group_membership.html#watching-group-changes><BR><BR><BR>______________________________________________________________________________<BR>OpenStack Development Mailing List (not for usage questions)<BR>Unsubscribe:<BR>OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe<http://openstack.org?subject:__unsubscribe><BR><http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><BR>http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev<BR><http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev><BR><BR>__________________________________________________________________________<BR>OpenStack Development Mailing List (not for usage questions)<BR>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><BR>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR><BR>__________________________________________________________________________<BR>OpenStack Development Mailing List (not for usage questions)<BR>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><BR>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR><BR><BR><BR>--<BR>Kevin Benton<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150413/710773cf/attachment-0001.html><BR><BR>------------------------------<BR><BR>Message: 18<BR>Date: Sun, 12 Apr 2015 20:06:02 -0700<BR>From: Joshua Harlow <harlowja@outlook.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>Message-ID: <BLU436-SMTP198723039606360764ABB95D8E70@phx.gbl><BR>Content-Type: text/plain; charset="UTF-8"; format=flowed<BR><BR>Kevin Benton wrote:<BR>> >Timestamps are just one way (and likely the most primitive), using<BR>> redis (or memcache) key/value and expiry are another (and letting<BR>> memcache or redis expire using its own internal algorithms), using<BR>> zookeeper ephemeral nodes[1] are another... The point being that its<BR>> backend specific and tooz supports varying backends.<BR>><BR>> Very cool. Is the backend completely transparent so a deployer could<BR>> choose a service they are comfortable maintaining, or will that change<BR>> the properties WRT to resiliency of state on node restarts, partitions, etc?<BR><BR>Of course... we tried to make it 'completely' transparent, but in <BR>reality certain backends (zookeeper which uses a paxos-like algorithm <BR>and redis with sentinel support...) are better (more resilient, more <BR>consistent, handle partitions/restarts better...) than others (memcached <BR>is after all just a distributed cache). This is just the nature of the <BR>game...<BR><BR>><BR>> The Nova implementation of Tooz seemed pretty straight-forward, although<BR>> it looked like it had pluggable drivers for service management already.<BR>> Before I dig into it much further I'll file a spec on the Neutron side<BR>> to see if I can get some other cores onboard to do the review work if I<BR>> push a change to tooz.<BR><BR>Sounds good to me.<BR><BR>><BR>><BR>> On Sun, Apr 12, 2015 at 9:38 AM, Joshua Harlow <harlowja@outlook.com<BR>> <mailto:harlowja@outlook.com>> wrote:<BR>><BR>> Kevin Benton wrote:<BR>><BR>> So IIUC tooz would be handling the liveness detection for the<BR>> agents.<BR>> That would be nice to get ride of that logic in Neutron and just<BR>> register callbacks for rescheduling the dead.<BR>><BR>> Where does it store that state, does it persist timestamps to the DB<BR>> like Neutron does? If so, how would that scale better? If not,<BR>> who does<BR>> a given node ask to know if an agent is online or offline when<BR>> making a<BR>> scheduling decision?<BR>><BR>><BR>> Timestamps are just one way (and likely the most primitive), using<BR>> redis (or memcache) key/value and expiry are another (and letting<BR>> memcache or redis expire using its own internal algorithms), using<BR>> zookeeper ephemeral nodes[1] are another... The point being that its<BR>> backend specific and tooz supports varying backends.<BR>><BR>><BR>> However, before (what I assume is) the large code change to<BR>> implement<BR>> tooz, I would like to quantify that the heartbeats are actually a<BR>> bottleneck. When I was doing some profiling of them on the<BR>> master branch<BR>> a few months ago, processing a heartbeat took an order of<BR>> magnitude less<BR>> time (<50ms) than the 'sync routers' task of the l3 agent<BR>> (~300ms). A<BR>> few query optimizations might buy us a lot more headroom before<BR>> we have<BR>> to fall back to large refactors.<BR>><BR>><BR>> Sure, always good to avoid prematurely optimizing things...<BR>><BR>> Although this is relevant for u I think anyway:<BR>><BR>> https://review.openstack.org/#__/c/138607/<BR>> <https://review.openstack.org/#/c/138607/> (same thing/nearly same<BR>> in nova)...<BR>><BR>> https://review.openstack.org/#__/c/172502/<BR>> <https://review.openstack.org/#/c/172502/> (a WIP implementation of<BR>> the latter).<BR>><BR>> [1]<BR>> https://zookeeper.apache.org/__doc/trunk/__zookeeperProgrammers.html#__Ephemeral+Nodes<BR>> <https://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#Ephemeral+Nodes><BR>><BR>><BR>> Kevin Benton wrote:<BR>><BR>><BR>> One of the most common is the heartbeat from each agent.<BR>> However, I<BR>> don't think we can't eliminate them because they are used<BR>> to determine<BR>> if the agents are still alive for scheduling purposes. Did<BR>> you have<BR>> something else in mind to determine if an agent is alive?<BR>><BR>><BR>> Put each agent in a tooz[1] group; have each agent periodically<BR>> heartbeat[2], have whoever needs to schedule read the active<BR>> members of<BR>> that group (or use [3] to get notified via a callback), profit...<BR>><BR>> Pick from your favorite (supporting) driver at:<BR>><BR>> http://docs.openstack.org/____developer/tooz/compatibility.____html<BR>> <http://docs.openstack.org/__developer/tooz/compatibility.__html><BR>> <http://docs.openstack.org/__developer/tooz/compatibility.__html<BR>> <http://docs.openstack.org/developer/tooz/compatibility.html>><BR>><BR>> [1]<BR>> http://docs.openstack.org/____developer/tooz/compatibility.____html#grouping<BR>> <http://docs.openstack.org/__developer/tooz/compatibility.__html#grouping><BR>> <http://docs.openstack.org/__developer/tooz/compatibility.__html#grouping<BR>> <http://docs.openstack.org/developer/tooz/compatibility.html#grouping>><BR>> [2]<BR>> https://github.com/openstack/____tooz/blob/0.13.1/tooz/____coordination.py#L315<BR>> <https://github.com/openstack/__tooz/blob/0.13.1/tooz/__coordination.py#L315><BR>> <https://github.com/openstack/__tooz/blob/0.13.1/tooz/__coordination.py#L315<BR>> <https://github.com/openstack/tooz/blob/0.13.1/tooz/coordination.py#L315>><BR>> [3]<BR>> http://docs.openstack.org/____developer/tooz/tutorial/group_____membership.html#watching-____group-changes<BR>> <http://docs.openstack.org/__developer/tooz/tutorial/group___membership.html#watching-__group-changes><BR>> <http://docs.openstack.org/__developer/tooz/tutorial/group___membership.html#watching-__group-changes<BR>> <http://docs.openstack.org/developer/tooz/tutorial/group_membership.html#watching-group-changes>><BR>><BR>><BR>> __________________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe:<BR>> OpenStack-dev-request@lists.____openstack.org?subject:____unsubscribe<BR>> <http://openstack.org?subject:__unsubscribe><BR>> <http://OpenStack-dev-request@__lists.openstack.org?subject:__unsubscribe<BR>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>><BR>> http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-dev<BR>> <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev><BR>> <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev<BR>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>><BR>><BR>> ______________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe:<BR>> OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><BR>> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev<BR>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev><BR>><BR>><BR>> ______________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe:<BR>> OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe<BR>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><BR>> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev><BR>><BR>><BR>><BR>><BR>> --<BR>> Kevin Benton<BR>><BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR><BR><BR><BR>------------------------------<BR><BR>Message: 19<BR>Date: Sun, 12 Apr 2015 20:10:41 -0700<BR>From: Joshua Harlow <harlowja@outlook.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>Message-ID: <BLU437-SMTP392487FC50F749804A13DDD8E70@phx.gbl><BR>Content-Type: text/plain; charset="UTF-8"; format=flowed<BR><BR>joehuang wrote:<BR>> Hi, Kevin and Joshua,<BR>><BR>> As my understanding, Tooz only addresses the issue of agent status<BR>> management, but how to solve the concurrent dynamic load impact on large<BR>> scale ( for example 100k managed nodes with the dynamic load like<BR>> security goup rule update, routers_updated, etc )<BR><BR>Yes, that is correct, let's not confuse status/liveness management with <BR>updates... since IMHO they are to very different things (the latter can <BR>be eventually consistent IMHO will the liveness 'question' probably <BR>should not be...).<BR><BR>><BR>> And one more question is, if we have 100k managed nodes, how to do the<BR>> partition? Or all nodes will be managed by one Tooz service, like<BR>> Zookeeper? Can Zookeeper manage 100k nodes status?<BR><BR>I can get u some data/numbers from some studies I've seen, but what u <BR>are talking about is highly specific as to what u are doing with <BR>zookeeper... There is no one solution for all the things IMHO; choose <BR>what's best from your tool-belt for each problem...<BR><BR>><BR>> Best Regards<BR>><BR>> Chaoyi Huang ( Joe Huang )<BR>><BR>> *From:*Kevin Benton [mailto:blak111@gmail.com]<BR>> *Sent:* Monday, April 13, 2015 3:52 AM<BR>> *To:* OpenStack Development Mailing List (not for usage questions)<BR>> *Subject:* Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>><BR>>>Timestamps are just one way (and likely the most primitive), using redis<BR>> (or memcache) key/value and expiry are another (and letting memcache or<BR>> redis expire using its own internal algorithms), using zookeeper<BR>> ephemeral nodes[1] are another... The point being that its backend<BR>> specific and tooz supports varying backends.<BR>><BR>> Very cool. Is the backend completely transparent so a deployer could<BR>> choose a service they are comfortable maintaining, or will that change<BR>> the properties WRT to resiliency of state on node restarts, partitions, etc?<BR>><BR>> The Nova implementation of Tooz seemed pretty straight-forward, although<BR>> it looked like it had pluggable drivers for service management already.<BR>> Before I dig into it much further I'll file a spec on the Neutron side<BR>> to see if I can get some other cores onboard to do the review work if I<BR>> push a change to tooz.<BR>><BR>> On Sun, Apr 12, 2015 at 9:38 AM, Joshua Harlow <harlowja@outlook.com<BR>> <mailto:harlowja@outlook.com>> wrote:<BR>><BR>> Kevin Benton wrote:<BR>><BR>> So IIUC tooz would be handling the liveness detection for the agents.<BR>> That would be nice to get ride of that logic in Neutron and just<BR>> register callbacks for rescheduling the dead.<BR>><BR>> Where does it store that state, does it persist timestamps to the DB<BR>> like Neutron does? If so, how would that scale better? If not, who does<BR>> a given node ask to know if an agent is online or offline when making a<BR>> scheduling decision?<BR>><BR>><BR>> Timestamps are just one way (and likely the most primitive), using redis<BR>> (or memcache) key/value and expiry are another (and letting memcache or<BR>> redis expire using its own internal algorithms), using zookeeper<BR>> ephemeral nodes[1] are another... The point being that its backend<BR>> specific and tooz supports varying backends.<BR>><BR>><BR>> However, before (what I assume is) the large code change to implement<BR>> tooz, I would like to quantify that the heartbeats are actually a<BR>> bottleneck. When I was doing some profiling of them on the master branch<BR>> a few months ago, processing a heartbeat took an order of magnitude less<BR>> time (<50ms) than the 'sync routers' task of the l3 agent (~300ms). A<BR>> few query optimizations might buy us a lot more headroom before we have<BR>> to fall back to large refactors.<BR>><BR>><BR>> Sure, always good to avoid prematurely optimizing things...<BR>><BR>> Although this is relevant for u I think anyway:<BR>><BR>> https://review.openstack.org/#/c/138607/ (same thing/nearly same in nova)...<BR>><BR>> https://review.openstack.org/#/c/172502/ (a WIP implementation of the<BR>> latter).<BR>><BR>> [1]<BR>> https://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#Ephemeral+Nodes<BR>> <https://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#Ephemeral+Nodes><BR>><BR>><BR>> Kevin Benton wrote:<BR>><BR>><BR>> One of the most common is the heartbeat from each agent. However, I<BR>> don't think we can't eliminate them because they are used to determine<BR>> if the agents are still alive for scheduling purposes. Did you have<BR>> something else in mind to determine if an agent is alive?<BR>><BR>><BR>> Put each agent in a tooz[1] group; have each agent periodically<BR>> heartbeat[2], have whoever needs to schedule read the active members of<BR>> that group (or use [3] to get notified via a callback), profit...<BR>><BR>> Pick from your favorite (supporting) driver at:<BR>><BR>> http://docs.openstack.org/__developer/tooz/compatibility.__html<BR>> <http://docs.openstack.org/developer/tooz/compatibility.html><BR>><BR>> [1]<BR>> http://docs.openstack.org/__developer/tooz/compatibility.__html#grouping<BR>> <http://docs.openstack.org/developer/tooz/compatibility.html#grouping><BR>> [2]<BR>> https://github.com/openstack/__tooz/blob/0.13.1/tooz/__coordination.py#L315<BR>> <https://github.com/openstack/tooz/blob/0.13.1/tooz/coordination.py#L315><BR>> [3]<BR>> http://docs.openstack.org/__developer/tooz/tutorial/group___membership.html#watching-__group-changes<BR>> <http://docs.openstack.org/developer/tooz/tutorial/group_membership.html#watching-group-changes><BR>><BR>><BR>> ______________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe:<BR>> OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe<BR>> <http://openstack.org?subject:__unsubscribe><BR>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><BR>> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev<BR>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev><BR>><BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe:<BR>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>><BR>><BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe:<BR>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>><BR>><BR>><BR>> --<BR>><BR>> Kevin Benton<BR>><BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR><BR><BR><BR>------------------------------<BR><BR>Message: 20<BR>Date: Sun, 12 Apr 2015 20:14:51 -0700<BR>From: Joshua Harlow <harlowja@outlook.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>Message-ID: <BLU436-SMTP1166EE6F77C4A1152DAEC4AD8E70@phx.gbl><BR>Content-Type: text/plain; charset="ISO-8859-1"; format=flowed<BR><BR>Joshua Harlow wrote:<BR>> Kevin Benton wrote:<BR>>> >Timestamps are just one way (and likely the most primitive), using<BR>>> redis (or memcache) key/value and expiry are another (and letting<BR>>> memcache or redis expire using its own internal algorithms), using<BR>>> zookeeper ephemeral nodes[1] are another... The point being that its<BR>>> backend specific and tooz supports varying backends.<BR>>><BR>>> Very cool. Is the backend completely transparent so a deployer could<BR>>> choose a service they are comfortable maintaining, or will that change<BR>>> the properties WRT to resiliency of state on node restarts,<BR>>> partitions, etc?<BR>><BR>> Of course... we tried to make it 'completely' transparent, but in<BR>> reality certain backends (zookeeper which uses a paxos-like algorithm<BR>> and redis with sentinel support...) are better (more resilient, more<BR>> consistent, handle partitions/restarts better...) than others (memcached<BR>> is after all just a distributed cache). This is just the nature of the<BR>> game...<BR>><BR><BR>And for some more reading fun:<BR><BR>https://aphyr.com/posts/315-call-me-maybe-rabbitmq<BR><BR>https://aphyr.com/posts/291-call-me-maybe-zookeeper<BR><BR>https://aphyr.com/posts/283-call-me-maybe-redis<BR><BR>https://aphyr.com/posts/316-call-me-maybe-etcd-and-consul<BR><BR>.. (aphyr.com has alot of these neat posts)...<BR><BR>>><BR>>> The Nova implementation of Tooz seemed pretty straight-forward, although<BR>>> it looked like it had pluggable drivers for service management already.<BR>>> Before I dig into it much further I'll file a spec on the Neutron side<BR>>> to see if I can get some other cores onboard to do the review work if I<BR>>> push a change to tooz.<BR>><BR>> Sounds good to me.<BR>><BR>>><BR>>><BR>>> On Sun, Apr 12, 2015 at 9:38 AM, Joshua Harlow <harlowja@outlook.com<BR>>> <mailto:harlowja@outlook.com>> wrote:<BR>>><BR>>> Kevin Benton wrote:<BR>>><BR>>> So IIUC tooz would be handling the liveness detection for the<BR>>> agents.<BR>>> That would be nice to get ride of that logic in Neutron and just<BR>>> register callbacks for rescheduling the dead.<BR>>><BR>>> Where does it store that state, does it persist timestamps to the DB<BR>>> like Neutron does? If so, how would that scale better? If not,<BR>>> who does<BR>>> a given node ask to know if an agent is online or offline when<BR>>> making a<BR>>> scheduling decision?<BR>>><BR>>><BR>>> Timestamps are just one way (and likely the most primitive), using<BR>>> redis (or memcache) key/value and expiry are another (and letting<BR>>> memcache or redis expire using its own internal algorithms), using<BR>>> zookeeper ephemeral nodes[1] are another... The point being that its<BR>>> backend specific and tooz supports varying backends.<BR>>><BR>>><BR>>> However, before (what I assume is) the large code change to<BR>>> implement<BR>>> tooz, I would like to quantify that the heartbeats are actually a<BR>>> bottleneck. When I was doing some profiling of them on the<BR>>> master branch<BR>>> a few months ago, processing a heartbeat took an order of<BR>>> magnitude less<BR>>> time (<50ms) than the 'sync routers' task of the l3 agent<BR>>> (~300ms). A<BR>>> few query optimizations might buy us a lot more headroom before<BR>>> we have<BR>>> to fall back to large refactors.<BR>>><BR>>><BR>>> Sure, always good to avoid prematurely optimizing things...<BR>>><BR>>> Although this is relevant for u I think anyway:<BR>>><BR>>> https://review.openstack.org/#__/c/138607/<BR>>> <https://review.openstack.org/#/c/138607/> (same thing/nearly same<BR>>> in nova)...<BR>>><BR>>> https://review.openstack.org/#__/c/172502/<BR>>> <https://review.openstack.org/#/c/172502/> (a WIP implementation of<BR>>> the latter).<BR>>><BR>>> [1]<BR>>> https://zookeeper.apache.org/__doc/trunk/__zookeeperProgrammers.html#__Ephemeral+Nodes<BR>>><BR>>> <https://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#Ephemeral+Nodes><BR>>><BR>>><BR>>><BR>>> Kevin Benton wrote:<BR>>><BR>>><BR>>> One of the most common is the heartbeat from each agent.<BR>>> However, I<BR>>> don't think we can't eliminate them because they are used<BR>>> to determine<BR>>> if the agents are still alive for scheduling purposes. Did<BR>>> you have<BR>>> something else in mind to determine if an agent is alive?<BR>>><BR>>><BR>>> Put each agent in a tooz[1] group; have each agent periodically<BR>>> heartbeat[2], have whoever needs to schedule read the active<BR>>> members of<BR>>> that group (or use [3] to get notified via a callback), profit...<BR>>><BR>>> Pick from your favorite (supporting) driver at:<BR>>><BR>>> http://docs.openstack.org/____developer/tooz/compatibility.____html<BR>>> <http://docs.openstack.org/__developer/tooz/compatibility.__html><BR>>> <http://docs.openstack.org/__developer/tooz/compatibility.__html<BR>>> <http://docs.openstack.org/developer/tooz/compatibility.html>><BR>>><BR>>> [1]<BR>>> http://docs.openstack.org/____developer/tooz/compatibility.____html#grouping<BR>>><BR>>> <http://docs.openstack.org/__developer/tooz/compatibility.__html#grouping><BR>>><BR>>> <http://docs.openstack.org/__developer/tooz/compatibility.__html#grouping<BR>>> <http://docs.openstack.org/developer/tooz/compatibility.html#grouping>><BR>>> [2]<BR>>> https://github.com/openstack/____tooz/blob/0.13.1/tooz/____coordination.py#L315<BR>>><BR>>> <https://github.com/openstack/__tooz/blob/0.13.1/tooz/__coordination.py#L315><BR>>><BR>>> <https://github.com/openstack/__tooz/blob/0.13.1/tooz/__coordination.py#L315<BR>>><BR>>> <https://github.com/openstack/tooz/blob/0.13.1/tooz/coordination.py#L315>><BR>>><BR>>> [3]<BR>>> http://docs.openstack.org/____developer/tooz/tutorial/group_____membership.html#watching-____group-changes<BR>>><BR>>> <http://docs.openstack.org/__developer/tooz/tutorial/group___membership.html#watching-__group-changes><BR>>><BR>>> <http://docs.openstack.org/__developer/tooz/tutorial/group___membership.html#watching-__group-changes<BR>>><BR>>> <http://docs.openstack.org/developer/tooz/tutorial/group_membership.html#watching-group-changes>><BR>>><BR>>><BR>>><BR>>> __________________________________________________________________________________<BR>>><BR>>> OpenStack Development Mailing List (not for usage questions)<BR>>> Unsubscribe:<BR>>> OpenStack-dev-request@lists.____openstack.org?subject:____unsubscribe<BR>>> <http://openstack.org?subject:__unsubscribe><BR>>> <http://OpenStack-dev-request@__lists.openstack.org?subject:__unsubscribe<BR>>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>><BR>>> http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-dev<BR>>> <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev><BR>>> <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev<BR>>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>><BR>>><BR>>> ______________________________________________________________________________<BR>>><BR>>> OpenStack Development Mailing List (not for usage questions)<BR>>> Unsubscribe:<BR>>> OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe<BR>>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><BR>>> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev<BR>>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev><BR>>><BR>>><BR>>> ______________________________________________________________________________<BR>>><BR>>> OpenStack Development Mailing List (not for usage questions)<BR>>> Unsubscribe:<BR>>> OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe<BR>>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><BR>>> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev<BR>>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev><BR>>><BR>>><BR>>><BR>>><BR>>> --<BR>>> Kevin Benton<BR>>><BR>>> __________________________________________________________________________<BR>>><BR>>> OpenStack Development Mailing List (not for usage questions)<BR>>> Unsubscribe:<BR>>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>><BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR><BR><BR><BR>------------------------------<BR><BR>Message: 21<BR>Date: Sun, 12 Apr 2015 23:23:13 -0400<BR>From: Emilien Macchi <emilien@redhat.com><BR>To: puppet-openstack@puppetlabs.com, openstack-dev@lists.openstack.org<BR>Subject: Re: [openstack-dev] [puppet] Puppet PTL<BR>Message-ID: <552B36A1.6030009@redhat.com><BR>Content-Type: text/plain; charset="utf-8"<BR><BR><BR><BR>On 04/10/2015 06:58 PM, Colleen Murphy wrote:<BR>> Just to make it official: since we only had one nominee for PTL, we will<BR>> go ahead and name Emilien Macchi as our new PTL without proceeding with<BR>> an election process. Thanks, Emilien, for all your hard work and for<BR>> taking on this responsibility!<BR><BR>Well, I think this is a great opportunity to me to say something here.<BR>First of all, thank you for your trust and I'll do my best to succeed in<BR>this new position. You know me enough I'm always open to any feedback,<BR>so please do.<BR><BR>Also, I would like to thank our whole community (core & non-core) for<BR>the hard work we all did these years.<BR>I truly think we will succeed under the big tent only if we continue to<BR>work *together* as a team. But I'm confident, this is part of our DNA<BR>and this is why we are at this stage today.<BR><BR>I'm really looking forward to seeing you at the next Summit.<BR>Thanks,<BR><BR>> <BR>> Colleen (crinkle)<BR>> <BR>> -- <BR>> <BR>> To unsubscribe from this group and stop receiving emails from it, send<BR>> an email to puppet-openstack+unsubscribe@puppetlabs.com<BR>> <mailto:puppet-openstack+unsubscribe@puppetlabs.com>.<BR><BR>-- <BR>Emilien Macchi<BR><BR>-------------- next part --------------<BR>A non-text attachment was scrubbed...<BR>Name: signature.asc<BR>Type: application/pgp-signature<BR>Size: 473 bytes<BR>Desc: OpenPGP digital signature<BR>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150412/4e811715/attachment-0001.pgp><BR><BR>------------------------------<BR><BR>Message: 22<BR>Date: Mon, 13 Apr 2015 05:03:52 +0000<BR>From: Gary Kotton <gkotton@vmware.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] In loving memory of Chris Yeoh<BR>Message-ID: <D15127AD.74647%gkotton@vmware.com><BR>Content-Type: text/plain; charset="Windows-1252"<BR><BR>Hi,<BR>I am very saddened to read this. Not only will Chris be missed on a<BR>professional level but on a personal level. He was a real mensh<BR>(http://www.thefreedictionary.com/mensh). He was always helpful and<BR>supportive. Wishing his family a long life.<BR>Thanks<BR>Gary<BR><BR>On 4/13/15, 4:33 AM, "Michael Still" <mikal@stillhq.com> wrote:<BR><BR>>Hi, as promised I now have details of a charity for people to donate<BR>>to in Chris' memory:<BR>><BR>> <BR>>https://urldefense.proofpoint.com/v2/url?u=http-3A__participate.freetobrea<BR>>the.org_site_TR-3Fpx-3D1582460-26fr-5Fid-3D2710-26pg-3Dpersonal-23.VSscH5S<BR>>Ud90&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzk<BR>>WT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=IFwED7YYaddl7JbqZ5OLChF6gtEGxYkxfFHwjWRm<BR>>sD8&s=B3EgunFqBdY8twmv-iJ7G7xvKZ4Th48oB4HKSv2uGKg&e=<BR>><BR>>In the words of the family:<BR>><BR>>"We would prefer that people donate to lung cancer research in lieu of<BR>>flowers. Lung cancer has the highest mortality rate out of all the<BR>>cancers, and the lowest funding out of all the cancers. There is a<BR>>stigma attached that lung cancer is a smoker's disease, and that<BR>>sufferers deserve their fate. They bring it on through lifestyle<BR>>choice. Except that Chris has never smoked in his life, like a<BR>>surprisingly large percentage of lung cancer sufferers. These people<BR>>suffer for the incorrect beliefs of the masses, and those that are<BR>>left behind are equally innocent. We shouldn't be doing this now. He<BR>>shouldn't be gone. We need to do more to fix this. There will be<BR>>charity envelopes available at the funeral, or you can choose your<BR>>preferred research to fund, should you wish to do so. You have our<BR>>thanks."<BR>><BR>>Michael<BR>><BR>>On Wed, Apr 8, 2015 at 2:49 PM, Michael Still <mikal@stillhq.com> wrote:<BR>>> It is my sad duty to inform the community that Chris Yeoh passed away<BR>>>this<BR>>> morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will<BR>>> remember Chris as the clever and caring person that I will remember him<BR>>>as.<BR>>> I haven?t had a chance to confirm with the family if they want flowers<BR>>>or a<BR>>> donation to a charity. As soon as I know those details I will reply to<BR>>>this<BR>>> email.<BR>>><BR>>> Chris worked on open source for a very long time, with OpenStack being<BR>>>just<BR>>> the most recent in a long chain of contributions. He worked tirelessly<BR>>>on<BR>>> his contributions to Nova, including mentoring other developers. He was<BR>>> dedicated to the cause, with a strong vision of what OpenStack could<BR>>>become.<BR>>> He even named his cat after the project.<BR>>><BR>>> Chris might be the only person to have ever sent an email to his<BR>>>coworkers<BR>>> explaining what his code review strategy would be after brain surgery.<BR>>>It<BR>>> takes phenomenal strength to carry on in the face of that kind of<BR>>>adversity,<BR>>> but somehow he did. Frankly, I think I would have just sat on the beach.<BR>>><BR>>> Chris was also a contributor to the Linux Standards Base (LSB), where he<BR>>> helped improve the consistency and interoperability between Linux<BR>>> distributions. He ran the ?Hackfest? programming contests for a number<BR>>>of<BR>>> years at Australia?s open source conference -- linux.conf.au. He<BR>>>supported<BR>>> local Linux user groups in South Australia and Canberra, including<BR>>> involvement at installfests and speaking at local meetups. He competed<BR>>>in a<BR>>> programming challenge called Loki Hack, and beat out the world to win<BR>>>the<BR>>> event[1].<BR>>><BR>>> Alyssa?s memories of her dad need to last her a long time, so we?ve<BR>>>decided<BR>>> to try and collect some fond memories of Chris to help her along the<BR>>>way. If<BR>>> you feel comfortable doing so, please contribute a memory or two at<BR>>> <BR>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_form<BR>>>s_d_1kX-2DePqAO7Cuudppwqz1cqgBXAsJx27GkdM-2DeCZ0c1V8_viewform&d=AwIGaQ&c=<BR>>>Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTe<BR>>>q9N3-diTlNj4GyNc&m=IFwED7YYaddl7JbqZ5OLChF6gtEGxYkxfFHwjWRmsD8&s=iihsaOMe<BR>>>lNeIR3VZapWKjr5KLgMQArZ3nifKDo1yy8o&e=<BR>>><BR>>> Chris was humble, helpful and honest. The OpenStack and broader Open<BR>>>Source<BR>>> communities are poorer for his passing.<BR>>><BR>>> Michael<BR>>><BR>>> [1] <BR>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lokigames.com_hac<BR>>>k_&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkW<BR>>>T5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=IFwED7YYaddl7JbqZ5OLChF6gtEGxYkxfFHwjWRm<BR>>>sD8&s=9SJI7QK-jzCsVUN2hTXSthqiXNEbq2Fvl9JqQiX9tfo&e=<BR>><BR>><BR>><BR>>-- <BR>>Rackspace Australia<BR>><BR>>__________________________________________________________________________<BR>>OpenStack Development Mailing List (not for usage questions)<BR>>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR><BR><BR><BR><BR>------------------------------<BR><BR>Message: 23<BR>Date: Mon, 13 Apr 2015 02:21:59 -0400 (EDT)<BR>From: Attila Fazekas <afazekas@redhat.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>Message-ID:<BR><147828721.17010859.1428906119294.JavaMail.zimbra@redhat.com><BR>Content-Type: text/plain; charset=utf-8<BR><BR><BR><BR><BR><BR>----- Original Message -----<BR>> From: "Kevin Benton" <blak111@gmail.com><BR>> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org><BR>> Sent: Sunday, April 12, 2015 4:17:29 AM<BR>> Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>> <BR>> <BR>> <BR>> So IIUC tooz would be handling the liveness detection for the agents. That<BR>> would be nice to get ride of that logic in Neutron and just register<BR>> callbacks for rescheduling the dead.<BR>> <BR>> Where does it store that state, does it persist timestamps to the DB like<BR>> Neutron does? If so, how would that scale better? If not, who does a given<BR>> node ask to know if an agent is online or offline when making a scheduling<BR>> decision?<BR>> <BR>You might find interesting the proposed solution in this bug:<BR>https://bugs.launchpad.net/nova/+bug/1437199<BR><BR>> However, before (what I assume is) the large code change to implement tooz, I<BR>> would like to quantify that the heartbeats are actually a bottleneck. When I<BR>> was doing some profiling of them on the master branch a few months ago,<BR>> processing a heartbeat took an order of magnitude less time (<50ms) than the<BR>> 'sync routers' task of the l3 agent (~300ms). A few query optimizations<BR>> might buy us a lot more headroom before we have to fall back to large<BR>> refactors.<BR>> Kevin Benton wrote:<BR>> <BR>> <BR>> <BR>> One of the most common is the heartbeat from each agent. However, I<BR>> don't think we can't eliminate them because they are used to determine<BR>> if the agents are still alive for scheduling purposes. Did you have<BR>> something else in mind to determine if an agent is alive?<BR>> <BR>> Put each agent in a tooz[1] group; have each agent periodically heartbeat[2],<BR>> have whoever needs to schedule read the active members of that group (or use<BR>> [3] to get notified via a callback), profit...<BR>> <BR>> Pick from your favorite (supporting) driver at:<BR>> <BR>> http://docs.openstack.org/ developer/tooz/compatibility. html<BR>> <BR>> [1] http://docs.openstack.org/ developer/tooz/compatibility. html#grouping<BR>> [2] https://github.com/openstack/ tooz/blob/0.13.1/tooz/ coordination.py#L315<BR>> [3] http://docs.openstack.org/ developer/tooz/tutorial/group_<BR>> membership.html#watching- group-changes<BR>> <BR>> <BR>> ______________________________ ______________________________ ______________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists. openstack.org?subject: unsubscribe<BR>> http://lists.openstack.org/ cgi-bin/mailman/listinfo/ openstack-dev<BR>> <BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>> <BR><BR><BR><BR>------------------------------<BR><BR>Message: 24<BR>Date: Sun, 12 Apr 2015 23:26:10 -0700<BR>From: Kevin Benton <blak111@gmail.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [Neutron] Regarding neutron bug # 1432582<BR>Message-ID:<BR><CAO_F6JP673t3trD4QudmHZKgUekPGVtqihg3zDHyhGf=7HpQrQ@mail.gmail.com><BR>Content-Type: text/plain; charset="utf-8"<BR><BR>I would like to see some form of this merged at least as an error message.<BR>If a server has a bad CMOS battery and suffers a power outage, it's clock<BR>could easily be several years behind. In that scenario, the NTP daemon<BR>could refuse to sync due to a sanity check.<BR><BR>On Wed, Apr 8, 2015 at 10:46 AM, Sudipto Biswas <sbiswas7@linux.vnet.ibm.com<BR>> wrote:<BR><BR>> Hi Guys, I'd really appreciate your feedback on this.<BR>><BR>> Thanks,<BR>> Sudipto<BR>><BR>><BR>> On Monday 30 March 2015 12:11 PM, Sudipto Biswas wrote:<BR>><BR>>> Someone from my team had installed the OS on baremetal with a wrong 'date'<BR>>> When this node was added to the Openstack controller, the logs from the<BR>>> neutron-agent on the compute node showed - "AMQP connected". But the<BR>>> neutron<BR>>> agent-list command would not list this agent at all.<BR>>><BR>>> I could figure out the problem when the neutron-server debug logs were<BR>>> enabled<BR>>> and it vaguely pointed at the rejection of AMQP connections due to a<BR>>> timestamp<BR>>> miss match. The neutron-server was treating these requests as stale due<BR>>> to the<BR>>> timestamp of the node being behind the neutron-server. However, there's no<BR>>> good way to detect this if the agent runs on a node which is ahead of<BR>>> time.<BR>>><BR>>> I recently raised a bug here: https://bugs.launchpad.net/<BR>>> neutron/+bug/1432582<BR>>><BR>>> And tried to resolve this with the review:<BR>>> https://review.openstack.org/#/c/165539/<BR>>><BR>>> It went through quite a few +2s after 15 odd patch sets but we still are<BR>>> not<BR>>> in common ground w.r.t addressing this situation.<BR>>><BR>>> My fix tries to log better and throw up an exception to the neutron agent<BR>>> on<BR>>> FIRST time boot of the agent for better detection of the problem.<BR>>><BR>>> I would like to get your thoughts on this fix. Whether this seems legit<BR>>> to have<BR>>> the fix per the patch OR could you suggest a approach to tackle this OR<BR>>> suggest<BR>>> just abandoning the change.<BR>>><BR>>><BR>>><BR>>> __________________________________________________________________________<BR>>><BR>>> OpenStack Development Mailing List (not for usage questions)<BR>>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:<BR>>> unsubscribe<BR>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>>><BR>>><BR>>><BR>>><BR>><BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>><BR><BR><BR><BR>-- <BR>Kevin Benton<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150412/b8eef87a/attachment-0001.html><BR><BR>------------------------------<BR><BR>Message: 25<BR>Date: Mon, 13 Apr 2015 14:51:05 +0800<BR>From: "=?gb18030?B?NDQ5MTcxMzQy?=" <449171342@qq.com><BR>To: "=?gb18030?B?b3BlbnN0YWNrLWRldg==?="<BR><openstack-dev@lists.openstack.org><BR>Subject: [openstack-dev] ?magnum?About clean none use container imag<BR>Message-ID: <tencent_1B594E50513691B07D1B8F9E@qq.com><BR>Content-Type: text/plain; charset="gb18030"<BR><BR>From now on magnum had container create and delete api .The container create api will pull docker image from docker-registry.But the container delete api didn't delete image.It will let the image remain even though didn't had container use it.Is it much better we can clear the image in someway?<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150413/7072441b/attachment-0001.html><BR><BR>------------------------------<BR><BR>Message: 26<BR>Date: Mon, 13 Apr 2015 15:09:18 +0800<BR>From: Jay Lau <jay.lau.513@gmail.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] ?magnum?About clean none use container<BR>imag<BR>Message-ID:<BR><CAFyztAG6EOd97Ho5zir7U0Gmywq=J=AErH9WJAi-2yswx2E5Ng@mail.gmail.com><BR>Content-Type: text/plain; charset="utf-8"<BR><BR>Interesting topic, pulling image is time consuming, so someone might not<BR>want to delete the container; But for some cases, if the image was not<BR>used, then it is better to remove them from disk to release space. You may<BR>want to send out an email to [openstack][magnum] ML to get more feedback ;-)<BR><BR>2015-04-13 14:51 GMT+08:00 449171342 <449171342@qq.com>:<BR><BR>><BR>><BR>> From now on magnum had container create and delete api .The container create api will pull docker image from docker-registry.But the container delete api didn't delete image.It will let the image remain even though didn't had container use it.Is it much better we can clear the image in someway?<BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>><BR>><BR><BR><BR>-- <BR>Thanks,<BR><BR>Jay Lau (Guangya Liu)<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150413/38091051/attachment-0001.html><BR><BR>------------------------------<BR><BR>Message: 27<BR>Date: Mon, 13 Apr 2015 03:18:34 -0400 (EDT)<BR>From: Attila Fazekas <afazekas@redhat.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>Message-ID:<BR><1115924511.17061105.1428909514804.JavaMail.zimbra@redhat.com><BR>Content-Type: text/plain; charset=utf-8<BR><BR><BR><BR><BR><BR>----- Original Message -----<BR>> From: "joehuang" <joehuang@huawei.com><BR>> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org><BR>> Sent: Sunday, April 12, 2015 1:20:48 PM<BR>> Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>> <BR>> <BR>> <BR>> Hi, Kevin,<BR>> <BR>> <BR>> <BR>> I assumed that all agents are connected to same IP address of RabbitMQ, then<BR>> the connection will exceed the port ranges limitation.<BR>> <BR>https://news.ycombinator.com/item?id=1571300<BR><BR>"TCP connections are identified by the (src ip, src port, dest ip, dest port) tuple."<BR><BR>"The server doesn't need multiple IPs to handle > 65535 connections. All the server connections to a given IP are to the same port. For a given client, the unique key for an http connection is (client-ip, PORT, server-ip, 80). The only number that can vary is PORT, and that's a value on the client. So, the client is limited to 65535 connections to the server. But, a second client could also have another 65K connections to the same server-ip:port."<BR><BR>> <BR>> For a RabbitMQ cluster, for sure the client can connect to any one of member<BR>> in the cluster, but in this case, the client has to be designed in fail-safe<BR>> manner: the client should be aware of the cluster member failure, and<BR>> reconnect to other survive member. No such mechnism has been implemented<BR>> yet.<BR>> <BR>> <BR>> <BR>> Other way is to use LVS or DNS based like load balancer, or something else.<BR>> If you put one load balancer ahead of a cluster, then we have to take care<BR>> of the port number limitation, there are so many agents will require<BR>> connection concurrently, 100k level, and the requests can not be rejected.<BR>> <BR>> <BR>> <BR>> Best Regards<BR>> <BR>> <BR>> <BR>> Chaoyi Huang ( joehuang )<BR>> <BR>> <BR>> <BR>> From: Kevin Benton [blak111@gmail.com]<BR>> Sent: 12 April 2015 9:59<BR>> To: OpenStack Development Mailing List (not for usage questions)<BR>> Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>> <BR>> The TCP/IP stack keeps track of connections as a combination of IP + TCP<BR>> port. The two byte port limit doesn't matter unless all of the agents are<BR>> connecting from the same IP address, which shouldn't be the case unless<BR>> compute nodes connect to the rabbitmq server via one IP address running port<BR>> address translation.<BR>> <BR>> Either way, the agents don't connect directly to the Neutron server, they<BR>> connect to the rabbit MQ cluster. Since as many Neutron server processes can<BR>> be launched as necessary, the bottlenecks will likely show up at the<BR>> messaging or DB layer.<BR>> <BR>> On Sat, Apr 11, 2015 at 6:46 PM, joehuang < joehuang@huawei.com > wrote:<BR>> <BR>> <BR>> <BR>> <BR>> <BR>> As Kevin talking about agents, I want to remind that in TCP/IP stack, port (<BR>> not Neutron Port ) is a two bytes field, i.e. port ranges from 0 ~ 65535,<BR>> supports maximum 64k port number.<BR>> <BR>> <BR>> <BR>> " above 100k managed node " means more than 100k L2 agents/L3 agents... will<BR>> be alive under Neutron.<BR>> <BR>> <BR>> <BR>> Want to know the detail design how to support 99.9% possibility for scaling<BR>> Neutron in this way, and PoC and test would be a good support for this idea.<BR>> <BR>> <BR>> <BR>> "I'm 99.9% sure, for scaling above 100k managed node,<BR>> we do not really need to split the openstack to multiple smaller openstack,<BR>> or use significant number of extra controller machine."<BR>> <BR>> <BR>> <BR>> Best Regards<BR>> <BR>> <BR>> <BR>> Chaoyi Huang ( joehuang )<BR>> <BR>> <BR>> <BR>> From: Kevin Benton [ blak111@gmail.com ]<BR>> Sent: 11 April 2015 12:34<BR>> To: OpenStack Development Mailing List (not for usage questions)<BR>> Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>> <BR>> Which periodic updates did you have in mind to eliminate? One of the few<BR>> remaining ones I can think of is sync_routers but it would be great if you<BR>> can enumerate the ones you observed because eliminating overhead in agents<BR>> is something I've been working on as well.<BR>> <BR>> One of the most common is the heartbeat from each agent. However, I don't<BR>> think we can't eliminate them because they are used to determine if the<BR>> agents are still alive for scheduling purposes. Did you have something else<BR>> in mind to determine if an agent is alive?<BR>> <BR>> On Fri, Apr 10, 2015 at 2:18 AM, Attila Fazekas < afazekas@redhat.com ><BR>> wrote:<BR>> <BR>> <BR>> I'm 99.9% sure, for scaling above 100k managed node,<BR>> we do not really need to split the openstack to multiple smaller openstack,<BR>> or use significant number of extra controller machine.<BR>> <BR>> The problem is openstack using the right tools SQL/AMQP/(zk),<BR>> but in a wrong way.<BR>> <BR>> For example.:<BR>> Periodic updates can be avoided almost in all cases<BR>> <BR>> The new data can be pushed to the agent just when it needed.<BR>> The agent can know when the AMQP connection become unreliable (queue or<BR>> connection loose),<BR>> and needs to do full sync.<BR>> https://bugs.launchpad.net/neutron/+bug/1438159<BR>> <BR>> Also the agents when gets some notification, they start asking for details<BR>> via the<BR>> AMQP -> SQL. Why they do not know it already or get it with the notification<BR>> ?<BR>> <BR>> <BR>> ----- Original Message -----<BR>> > From: "Neil Jerram" < Neil.Jerram@metaswitch.com ><BR>> > To: "OpenStack Development Mailing List (not for usage questions)" <<BR>> > openstack-dev@lists.openstack.org ><BR>> > Sent: Thursday, April 9, 2015 5:01:45 PM<BR>> > Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>> > <BR>> > Hi Joe,<BR>> > <BR>> > Many thanks for your reply!<BR>> > <BR>> > On 09/04/15 03:34, joehuang wrote:<BR>> > > Hi, Neil,<BR>> > > <BR>> > > From theoretic, Neutron is like a "broadcast" domain, for example,<BR>> > > enforcement of DVR and security group has to touch each regarding host<BR>> > > where there is VM of this project resides. Even using SDN controller, the<BR>> > > "touch" to regarding host is inevitable. If there are plenty of physical<BR>> > > hosts, for example, 10k, inside one Neutron, it's very hard to overcome<BR>> > > the "broadcast storm" issue under concurrent operation, that's the<BR>> > > bottleneck for scalability of Neutron.<BR>> > <BR>> > I think I understand that in general terms - but can you be more<BR>> > specific about the broadcast storm? Is there one particular message<BR>> > exchange that involves broadcasting? Is it only from the server to<BR>> > agents, or are there 'broadcasts' in other directions as well?<BR>> > <BR>> > (I presume you are talking about control plane messages here, i.e.<BR>> > between Neutron components. Is that right? Obviously there can also be<BR>> > broadcast storm problems in the data plane - but I don't think that's<BR>> > what you are talking about here.)<BR>> > <BR>> > > We need layered architecture in Neutron to solve the "broadcast domain"<BR>> > > bottleneck of scalability. The test report from OpenStack cascading shows<BR>> > > that through layered architecture "Neutron cascading", Neutron can<BR>> > > supports up to million level ports and 100k level physical hosts. You can<BR>> > > find the report here:<BR>> > > http://www.slideshare.net/JoeHuang7/test-report-for-open-stack-cascading-solution-to-support-1-million-v-ms-in-100-data-centers<BR>> > <BR>> > Many thanks, I will take a look at this.<BR>> > <BR>> > > "Neutron cascading" also brings extra benefit: One cascading Neutron can<BR>> > > have many cascaded Neutrons, and different cascaded Neutron can leverage<BR>> > > different SDN controller, maybe one is ODL, the other one is<BR>> > > OpenContrail.<BR>> > > <BR>> > > ----------------Cascading Neutron-------------------<BR>> > > / \<BR>> > > --cascaded Neutron-- --cascaded Neutron-----<BR>> > > | | <BR>> > > ---------ODL------ ----OpenContrail--------<BR>> > > <BR>> > > <BR>> > > And furthermore, if using Neutron cascading in multiple data centers, the<BR>> > > DCI controller (Data center inter-connection controller) can also be used<BR>> > > under cascading Neutron, to provide NaaS ( network as a service ) across<BR>> > > data centers.<BR>> > > <BR>> > > ---------------------------Cascading Neutron--------------------------<BR>> > > / | \<BR>> > > --cascaded Neutron-- -DCI controller- --cascaded Neutron-----<BR>> > > | | | <BR>> > > ---------ODL------ | ----OpenContrail--------<BR>> > > | <BR>> > > --(Data center 1)-- --(DCI networking)-- --(Data center 2)--<BR>> > > <BR>> > > Is it possible for us to discuss this in OpenStack Vancouver summit?<BR>> > <BR>> > Most certainly, yes. I will be there from mid Monday afternoon through<BR>> > to end Friday. But it will be my first summit, so I have no idea yet as<BR>> > to how I might run into you - please can you suggest!<BR>> > <BR>> > > Best Regards<BR>> > > Chaoyi Huang ( Joe Huang )<BR>> > <BR>> > Regards,<BR>> > Neil<BR>> > <BR>> > __________________________________________________________________________<BR>> > OpenStack Development Mailing List (not for usage questions)<BR>> > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>> > <BR>> <BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>> <BR>> <BR>> <BR>> --<BR>> Kevin Benton<BR>> <BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>> <BR>> <BR>> <BR>> <BR>> --<BR>> Kevin Benton<BR>> <BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>> <BR><BR><BR><BR>------------------------------<BR><BR>Message: 28<BR>Date: Mon, 13 Apr 2015 15:23:21 +0800<BR>From: wu jiang <wingwj@gmail.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] In loving memory of Chris Yeoh<BR>Message-ID:<BR><CAEfJYtTacCxQ2MQXzqQQ2b_VoX6o_Pxr=WmoaXB=HDp5EmZ92w@mail.gmail.com><BR>Content-Type: text/plain; charset="utf-8"<BR><BR>What bad news.. Chris helped me a lot, we lost a mentor and friend.<BR>May God bless his/her soul.<BR><BR>WingWJ<BR><BR>On Mon, Apr 13, 2015 at 1:03 PM, Gary Kotton <gkotton@vmware.com> wrote:<BR><BR>> Hi,<BR>> I am very saddened to read this. Not only will Chris be missed on a<BR>> professional level but on a personal level. He was a real mensh<BR>> (http://www.thefreedictionary.com/mensh). He was always helpful and<BR>> supportive. Wishing his family a long life.<BR>> Thanks<BR>> Gary<BR>><BR>> On 4/13/15, 4:33 AM, "Michael Still" <mikal@stillhq.com> wrote:<BR>><BR>> >Hi, as promised I now have details of a charity for people to donate<BR>> >to in Chris' memory:<BR>> ><BR>> ><BR>> ><BR>> https://urldefense.proofpoint.com/v2/url?u=http-3A__participate.freetobrea<BR>> >the.org_site_TR-3Fpx-3D1582460-26fr-5Fid-3D2710-26pg-3Dpersonal-23.VSscH5S<BR>> >Ud90&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzk<BR>> >WT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=IFwED7YYaddl7JbqZ5OLChF6gtEGxYkxfFHwjWRm<BR>> >sD8&s=B3EgunFqBdY8twmv-iJ7G7xvKZ4Th48oB4HKSv2uGKg&e=<BR>> ><BR>> >In the words of the family:<BR>> ><BR>> >"We would prefer that people donate to lung cancer research in lieu of<BR>> >flowers. Lung cancer has the highest mortality rate out of all the<BR>> >cancers, and the lowest funding out of all the cancers. There is a<BR>> >stigma attached that lung cancer is a smoker's disease, and that<BR>> >sufferers deserve their fate. They bring it on through lifestyle<BR>> >choice. Except that Chris has never smoked in his life, like a<BR>> >surprisingly large percentage of lung cancer sufferers. These people<BR>> >suffer for the incorrect beliefs of the masses, and those that are<BR>> >left behind are equally innocent. We shouldn't be doing this now. He<BR>> >shouldn't be gone. We need to do more to fix this. There will be<BR>> >charity envelopes available at the funeral, or you can choose your<BR>> >preferred research to fund, should you wish to do so. You have our<BR>> >thanks."<BR>> ><BR>> >Michael<BR>> ><BR>> >On Wed, Apr 8, 2015 at 2:49 PM, Michael Still <mikal@stillhq.com> wrote:<BR>> >> It is my sad duty to inform the community that Chris Yeoh passed away<BR>> >>this<BR>> >> morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will<BR>> >> remember Chris as the clever and caring person that I will remember him<BR>> >>as.<BR>> >> I haven?t had a chance to confirm with the family if they want flowers<BR>> >>or a<BR>> >> donation to a charity. As soon as I know those details I will reply to<BR>> >>this<BR>> >> email.<BR>> >><BR>> >> Chris worked on open source for a very long time, with OpenStack being<BR>> >>just<BR>> >> the most recent in a long chain of contributions. He worked tirelessly<BR>> >>on<BR>> >> his contributions to Nova, including mentoring other developers. He was<BR>> >> dedicated to the cause, with a strong vision of what OpenStack could<BR>> >>become.<BR>> >> He even named his cat after the project.<BR>> >><BR>> >> Chris might be the only person to have ever sent an email to his<BR>> >>coworkers<BR>> >> explaining what his code review strategy would be after brain surgery.<BR>> >>It<BR>> >> takes phenomenal strength to carry on in the face of that kind of<BR>> >>adversity,<BR>> >> but somehow he did. Frankly, I think I would have just sat on the beach.<BR>> >><BR>> >> Chris was also a contributor to the Linux Standards Base (LSB), where he<BR>> >> helped improve the consistency and interoperability between Linux<BR>> >> distributions. He ran the ?Hackfest? programming contests for a number<BR>> >>of<BR>> >> years at Australia?s open source conference -- linux.conf.au. He<BR>> >>supported<BR>> >> local Linux user groups in South Australia and Canberra, including<BR>> >> involvement at installfests and speaking at local meetups. He competed<BR>> >>in a<BR>> >> programming challenge called Loki Hack, and beat out the world to win<BR>> >>the<BR>> >> event[1].<BR>> >><BR>> >> Alyssa?s memories of her dad need to last her a long time, so we?ve<BR>> >>decided<BR>> >> to try and collect some fond memories of Chris to help her along the<BR>> >>way. If<BR>> >> you feel comfortable doing so, please contribute a memory or two at<BR>> >><BR>> >><BR>> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_form<BR>> >>s_d_1kX-2DePqAO7Cuudppwqz1cqgBXAsJx27GkdM-2DeCZ0c1V8_viewform&d=AwIGaQ&c=<BR>> >>Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTe<BR>> >>q9N3-diTlNj4GyNc&m=IFwED7YYaddl7JbqZ5OLChF6gtEGxYkxfFHwjWRmsD8&s=iihsaOMe<BR>> >>lNeIR3VZapWKjr5KLgMQArZ3nifKDo1yy8o&e=<BR>> >><BR>> >> Chris was humble, helpful and honest. The OpenStack and broader Open<BR>> >>Source<BR>> >> communities are poorer for his passing.<BR>> >><BR>> >> Michael<BR>> >><BR>> >> [1]<BR>> >><BR>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lokigames.com_hac<BR>> >>k_&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkW<BR>> >>T5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=IFwED7YYaddl7JbqZ5OLChF6gtEGxYkxfFHwjWRm<BR>> >>sD8&s=9SJI7QK-jzCsVUN2hTXSthqiXNEbq2Fvl9JqQiX9tfo&e=<BR>> ><BR>> ><BR>> ><BR>> >--<BR>> >Rackspace Australia<BR>> ><BR>> >__________________________________________________________________________<BR>> >OpenStack Development Mailing List (not for usage questions)<BR>> >Unsubscribe:<BR>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>><BR>><BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150413/9e436bfd/attachment-0001.html><BR><BR>------------------------------<BR><BR>Message: 29<BR>Date: Mon, 13 Apr 2015 04:03:49 -0400 (EDT)<BR>From: Victor Stinner <vstinner@redhat.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [oslo] eventlet 0.17.3 is now fully<BR>Python 3 compatible<BR>Message-ID:<BR><868807730.15816798.1428912229323.JavaMail.zimbra@redhat.com><BR>Content-Type: text/plain; charset=utf-8<BR><BR>> Worth noting we've already switched to using PyMySQL in nodepool,<BR>> storyboard and some of the subunit2sql tooling. It's been working<BR>> out great so far.<BR><BR>Great. Did you notice a performance regression? Mike wrote that PyMySQL is much slower than MySQL-Python.<BR><BR>Victor<BR><BR><BR><BR>------------------------------<BR><BR>Message: 30<BR>Date: Mon, 13 Apr 2015 11:22:38 +0300<BR>From: Anastasia Urlapova <aurlapova@mirantis.com><BR>To: Andrey Sledzinskiy <asledzinskiy@mirantis.com>,<BR>"mos-qa@mirantis.com" <mos-qa@mirantis.com>, "OpenStack Development<BR>Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: [openstack-dev] [Fuel] Nominate Andrey Skedzinskiy for<BR>fuel-qa(devops) core<BR>Message-ID:<BR><CAC+Xjbbpm9jGap+j=qYayiJY8teqbRkJPjvZ0qieYVDDUFphOg@mail.gmail.com><BR>Content-Type: text/plain; charset="utf-8"<BR><BR>Guys,<BR>I would like to nominate Andrey Skedzinskiy[1] for<BR>fuel-qa[2]/fuel-devops[3] core team.<BR><BR>Andrey is one of the strongest reviewers, under his watchful eye are such<BR>features as:<BR>- updrade/rollback master node<BR>- collect usage information<BR>- OS patching<BR>- UI tests<BR>and others<BR><BR>Please vote for Andrey!<BR><BR><BR>Nastya.<BR><BR>[1]http://stackalytics.com/?project_type=stackforge&user_id=asledzinskiy<BR>[2]https://github.com/stackforge/fuel-qa<BR>[3]https://github.com/stackforge/fuel-devops<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150413/92ee8866/attachment-0001.html><BR><BR>------------------------------<BR><BR>Message: 31<BR>Date: Mon, 13 Apr 2015 11:37:44 +0300<BR>From: Alexander Kislitsky <akislitsky@mirantis.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Cc: "mos-qa@mirantis.com" <mos-qa@mirantis.com><BR>Subject: Re: [openstack-dev] [Fuel] Nominate Andrey Skedzinskiy for<BR>fuel-qa(devops) core<BR>Message-ID:<BR><CAHWr6fkksK1-i3vSKvC01X5F7sGBQAgBt9W6q4CJjtQqNFLv=g@mail.gmail.com><BR>Content-Type: text/plain; charset="utf-8"<BR><BR>Andrew shows great attention to the details. +1 for him.<BR><BR>On Mon, Apr 13, 2015 at 11:22 AM, Anastasia Urlapova <aurlapova@mirantis.com<BR>> wrote:<BR><BR>> Guys,<BR>> I would like to nominate Andrey Skedzinskiy[1] for<BR>> fuel-qa[2]/fuel-devops[3] core team.<BR>><BR>> Andrey is one of the strongest reviewers, under his watchful eye are such<BR>> features as:<BR>> - updrade/rollback master node<BR>> - collect usage information<BR>> - OS patching<BR>> - UI tests<BR>> and others<BR>><BR>> Please vote for Andrey!<BR>><BR>><BR>> Nastya.<BR>><BR>> [1]http://stackalytics.com/?project_type=stackforge&user_id=asledzinskiy<BR>> [2]https://github.com/stackforge/fuel-qa<BR>> [3]https://github.com/stackforge/fuel-devops<BR>><BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>><BR>><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150413/8239f0df/attachment-0001.html><BR><BR>------------------------------<BR><BR>Message: 32<BR>Date: Mon, 13 Apr 2015 10:52:11 +0200<BR>From: Miguel Angel Ajo Pelayo <majopela@redhat.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: Re: [openstack-dev] [all][pbr] splitting our deployment vs<BR>install dependencies<BR>Message-ID: <818AF012-6625-4766-B883-712D36A5851C@redhat.com><BR>Content-Type: text/plain; charset=us-ascii<BR><BR><BR>> On 13/4/2015, at 3:53, Robert Collins <robertc@robertcollins.net> wrote:<BR>> <BR>> On 13 April 2015 at 13:09, Robert Collins <robertc@robertcollins.net> wrote:<BR>>> On 13 April 2015 at 12:53, Monty Taylor <mordred@inaugust.com> wrote:<BR>>> <BR>>>> What we have in the gate is the thing that produces the artifacts that<BR>>>> someone installing using the pip tool would get. Shipping anything with<BR>>>> those artifacts other that a direct communication of what we tested is<BR>>>> just mean to our end users.<BR>>> <BR>>> Actually its not.<BR>>> <BR>>> What we test is point in time. At 2:45 UTC on Monday installing this<BR>>> git ref of nova worked.<BR>>> <BR>>> Noone can reconstruct that today.<BR>>> <BR>>> I entirely agree with the sentiment you're expressing, but we're not<BR>>> delivering that sentiment today.<BR>> <BR>> This observation led to yet more IRC discussion and eventually<BR>> https://etherpad.openstack.org/p/stable-omg-deps<BR>> <BR>> In short, the proposal is that we:<BR>> - stop trying to use install_requires to reproduce exactly what<BR>> works, and instead use it to communicate known constraints (> X, Y is<BR>> broken etc).<BR>> - use a requirements.txt file we create *during* CI to capture<BR>> exactly what worked, and also capture the dpkg and rpm versions of<BR>> packages that were present when it worked, and so on. So we'll build a<BR>> git tree where its history is an audit trail of exactly what worked<BR>> for everything that passed CI, formatted to make it really really easy<BR>> for other people to consume.<BR>> <BR><BR>That sounds like a very neat idea, this way we could look back, and backtrack<BR>to discover which package version change breaks the system.<BR><BR><BR>Miguel Angel Ajo<BR><BR><BR><BR><BR><BR><BR>------------------------------<BR><BR>Message: 33<BR>Date: Mon, 13 Apr 2015 08:51:39 +0000<BR>From: Wangbibo <wangbibo@huawei.com><BR>To: "OpenStack Development Mailing List (not for usage questions)"<BR><openstack-dev@lists.openstack.org><BR>Subject: [openstack-dev] ??: [neutron] Neutron scaling datapoints?<BR>Message-ID:<BR><EA5BE4191F3B3F4AB624BDC5B27A31A74E45D0A8@nkgeml504-mbs.china.huawei.com><BR><BR>Content-Type: text/plain; charset="utf-8"<BR><BR>Hi Kevin,<BR><BR>Totally agree with you that heartbeat from each agent is something that we cannot eliminate currently. Agent status depends on it, and further scheduler and HA depends on agent status.<BR><BR>I proposed a Liberty spec for introducing open framework/pluggable agent status drivers.[1][2] It allows us to use some other 3rd party backend to monitor agent status, such as zookeeper, memcached. Meanwhile, it guarantees backward compatibility so that users could still use db-based status monitoring mechanism as their default choice.<BR><BR>Base on that, we may do further optimization on issues Attila and you mentioned. Thanks.<BR><BR>[1] BP - https://blueprints.launchpad.net/neutron/+spec/agent-group-and-status-drivers<BR>[2] Liberty Spec proposed - https://review.openstack.org/#/c/168921/<BR><BR>Best,<BR>Robin<BR><BR><BR><BR><BR>???: Kevin Benton [mailto:blak111@gmail.com]<BR>????: 2015?4?11? 12:35<BR>???: OpenStack Development Mailing List (not for usage questions)<BR>??: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR><BR>Which periodic updates did you have in mind to eliminate? One of the few remaining ones I can think of is sync_routers but it would be great if you can enumerate the ones you observed because eliminating overhead in agents is something I've been working on as well.<BR><BR>One of the most common is the heartbeat from each agent. However, I don't think we can't eliminate them because they are used to determine if the agents are still alive for scheduling purposes. Did you have something else in mind to determine if an agent is alive?<BR><BR>On Fri, Apr 10, 2015 at 2:18 AM, Attila Fazekas <afazekas@redhat.com<mailto:afazekas@redhat.com>> wrote:<BR>I'm 99.9% sure, for scaling above 100k managed node,<BR>we do not really need to split the openstack to multiple smaller openstack,<BR>or use significant number of extra controller machine.<BR><BR>The problem is openstack using the right tools SQL/AMQP/(zk),<BR>but in a wrong way.<BR><BR>For example.:<BR>Periodic updates can be avoided almost in all cases<BR><BR>The new data can be pushed to the agent just when it needed.<BR>The agent can know when the AMQP connection become unreliable (queue or connection loose),<BR>and needs to do full sync.<BR>https://bugs.launchpad.net/neutron/+bug/1438159<BR><BR>Also the agents when gets some notification, they start asking for details via the<BR>AMQP -> SQL. Why they do not know it already or get it with the notification ?<BR><BR><BR>----- Original Message -----<BR>> From: "Neil Jerram" <Neil.Jerram@metaswitch.com<mailto:Neil.Jerram@metaswitch.com>><BR>> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>><BR>> Sent: Thursday, April 9, 2015 5:01:45 PM<BR>> Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?<BR>><BR>> Hi Joe,<BR>><BR>> Many thanks for your reply!<BR>><BR>> On 09/04/15 03:34, joehuang wrote:<BR>> > Hi, Neil,<BR>> ><BR>> > From theoretic, Neutron is like a "broadcast" domain, for example,<BR>> > enforcement of DVR and security group has to touch each regarding host<BR>> > where there is VM of this project resides. Even using SDN controller, the<BR>> > "touch" to regarding host is inevitable. If there are plenty of physical<BR>> > hosts, for example, 10k, inside one Neutron, it's very hard to overcome<BR>> > the "broadcast storm" issue under concurrent operation, that's the<BR>> > bottleneck for scalability of Neutron.<BR>><BR>> I think I understand that in general terms - but can you be more<BR>> specific about the broadcast storm? Is there one particular message<BR>> exchange that involves broadcasting? Is it only from the server to<BR>> agents, or are there 'broadcasts' in other directions as well?<BR>><BR>> (I presume you are talking about control plane messages here, i.e.<BR>> between Neutron components. Is that right? Obviously there can also be<BR>> broadcast storm problems in the data plane - but I don't think that's<BR>> what you are talking about here.)<BR>><BR>> > We need layered architecture in Neutron to solve the "broadcast domain"<BR>> > bottleneck of scalability. The test report from OpenStack cascading shows<BR>> > that through layered architecture "Neutron cascading", Neutron can<BR>> > supports up to million level ports and 100k level physical hosts. You can<BR>> > find the report here:<BR>> > http://www.slideshare.net/JoeHuang7/test-report-for-open-stack-cascading-solution-to-support-1-million-v-ms-in-100-data-centers<BR>><BR>> Many thanks, I will take a look at this.<BR>><BR>> > "Neutron cascading" also brings extra benefit: One cascading Neutron can<BR>> > have many cascaded Neutrons, and different cascaded Neutron can leverage<BR>> > different SDN controller, maybe one is ODL, the other one is OpenContrail.<BR>> ><BR>> > ----------------Cascading Neutron-------------------<BR>> > / \<BR>> > --cascaded Neutron-- --cascaded Neutron-----<BR>> > | |<BR>> > ---------ODL------ ----OpenContrail--------<BR>> ><BR>> ><BR>> > And furthermore, if using Neutron cascading in multiple data centers, the<BR>> > DCI controller (Data center inter-connection controller) can also be used<BR>> > under cascading Neutron, to provide NaaS ( network as a service ) across<BR>> > data centers.<BR>> ><BR>> > ---------------------------Cascading Neutron--------------------------<BR>> > / | \<BR>> > --cascaded Neutron-- -DCI controller- --cascaded Neutron-----<BR>> > | | |<BR>> > ---------ODL------ | ----OpenContrail--------<BR>> > |<BR>> > --(Data center 1)-- --(DCI networking)-- --(Data center 2)--<BR>> ><BR>> > Is it possible for us to discuss this in OpenStack Vancouver summit?<BR>><BR>> Most certainly, yes. I will be there from mid Monday afternoon through<BR>> to end Friday. But it will be my first summit, so I have no idea yet as<BR>> to how I might run into you - please can you suggest!<BR>><BR>> > Best Regards<BR>> > Chaoyi Huang ( Joe Huang )<BR>><BR>> Regards,<BR>> Neil<BR>><BR>> __________________________________________________________________________<BR>> OpenStack Development Mailing List (not for usage questions)<BR>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><BR>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR>><BR><BR>__________________________________________________________________________<BR>OpenStack Development Mailing List (not for usage questions)<BR>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><BR>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR><BR><BR><BR>--<BR>Kevin Benton<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150413/2569d73e/attachment.html><BR><BR>------------------------------<BR><BR>_______________________________________________<BR>OpenStack-dev mailing list<BR>OpenStack-dev@lists.openstack.org<BR>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR><BR><BR>End of OpenStack-dev Digest, Vol 36, Issue 32<BR>*********************************************
<DIV></DIV></DIV>