| *** sarob has quit IRC | 00:01 | |
| *** sarob has joined #akanda | 01:23 | |
| *** sarob has quit IRC | 01:46 | |
| *** rods has joined #akanda | 10:15 | |
| *** openstack has quit IRC | 10:20 | |
| *** openstack has joined #akanda | 10:26 | |
| *** rods has quit IRC | 11:43 | |
| *** rods has joined #akanda | 12:36 | |
| *** rods has quit IRC | 14:22 | |
| *** rods has joined #akanda | 14:22 | |
| *** sarob has joined #akanda | 14:58 | |
| sarob | Dev meet moved to 11am pdt | 15:01 |
|---|---|---|
| *** sarob has quit IRC | 15:08 | |
| *** sarob has joined #akanda | 15:09 | |
| *** sarob has quit IRC | 15:17 | |
| openstackgerrit | Merged stackforge/akanda-rug: Fix get_instance_by_id, catch NotFound appopriately https://review.openstack.org/186216 | 15:48 |
| *** cleverdevil has joined #akanda | 15:48 | |
| openstackgerrit | Merged stackforge/akanda-rug: devstack: Update horizon paths https://review.openstack.org/183641 | 15:50 |
| openstackgerrit | Merged stackforge/akanda-rug: Migrate to oslo.serialization https://review.openstack.org/183149 | 15:50 |
| ryanpetrello | http://vignette1.wikia.nocookie.net/epic-rap-battles-of-cartoons/images/d/de/Marge-simpson1.png/revision/latest?cb=20131213015321 | 15:51 |
| ryanpetrello | MARGED | 15:51 |
| *** sarob has joined #akanda | 16:13 | |
| *** puranamr has joined #akanda | 16:15 | |
| *** puranamr has quit IRC | 16:32 | |
| *** puranamr has joined #akanda | 16:44 | |
| *** rods has quit IRC | 17:01 | |
| *** rods has joined #akanda | 17:01 | |
| davidlenwell | lol | 17:34 |
| *** rods has quit IRC | 17:41 | |
| *** rods has joined #akanda | 17:43 | |
| sarob | davidlenwell: did we miss a funny? | 17:53 |
| davidlenwell | ryanpetrello: said marged rather than merged and posted a picture of marge | 17:54 |
| davidlenwell | simpson | 17:54 |
| davidlenwell | it made me chuckle | 17:54 |
| davidlenwell | what channel is our meeting in? | 17:54 |
| *** cleverde_ has joined #akanda | 17:58 | |
| ryanpetrello | davidlenwell meeting-4, right? | 17:59 |
| sarob | openstack-meeting | 18:00 |
| ryanpetrello | k | 18:02 |
| ryanpetrello | omw | 18:02 |
| *** cleverdevil has quit IRC | 18:02 | |
| sarob | dev meet on #openstack-meeting | 18:03 |
| *** cleverde_ is now known as cleverdevil | 18:06 | |
| *** sarob has quit IRC | 19:01 | |
| openstackgerrit | Adam Gandelman proposed stackforge/akanda-rug: Do not hard-code requirements path when adding blessed https://review.openstack.org/187283 | 19:04 |
| adam_g | oh interesting, someone in #openstack-oslo was just asking about pbr and https://www.python.org/dev/peps/pep-0440/#local-version-identifiers | 19:07 |
| adam_g | i guess thats more downstream oriented and doesnt really fit our goals | 19:08 |
| adam_g | oh hey | 19:23 |
| adam_g | http://lists.openstack.org/pipermail/openstack-dev/2015-May/065211.html | 19:23 |
| *** ryanpetrello has quit IRC | 19:24 | |
| *** ryanpetrello has joined #akanda | 19:26 | |
| openstackgerrit | Adam Gandelman proposed stackforge/akanda-rug: Do not hard-code requirements path when adding blessed https://review.openstack.org/187283 | 19:28 |
| ryanpetrello | adam, a thought re: blessed | 19:29 |
| ryanpetrello | might we just forego it entirely as a requirement | 19:29 |
| ryanpetrello | and just have some logic in the browse command that tells you to install it? | 19:29 |
| ryanpetrello | I do something similar for a feature of pecan | 19:29 |
| ryanpetrello | e.g., | 19:29 |
| adam_g | a try: import except ImportError: ? | 19:29 |
| ryanpetrello | https://github.com/stackforge/pecan/blob/master/pecan/commands/serve.py#L139 | 19:29 |
| ryanpetrello | yep | 19:29 |
| adam_g | ya, that works | 19:30 |
| ryanpetrello | and just document it as a dependency you have to install by hand if you want to use that (optional) feature | 19:30 |
| adam_g | +1 | 19:30 |
| ryanpetrello | we'd just need to make sure we do it in such a way that it doesn't break things if it's not installed | 19:30 |
| ryanpetrello | it needs to be entirely segregated from other import chains | 19:30 |
| adam_g | ya | 19:30 |
| ryanpetrello | (i.e., if you start the rug, it shouldn't bitch at you) | 19:30 |
| ryanpetrello | if it works properly, though, I'm fine with that, to be honest | 19:30 |
| ryanpetrello | I don't think we really use it that much anyways because it can't really keep up with thousands of routers | 19:31 |
| ryanpetrello | might make things easier for you all, too | 19:31 |
| ryanpetrello | adam_g: you have a minute to chat about juno side migration stuff? | 19:34 |
| adam_g | ryanpetrello, ya | 19:34 |
| *** cleverde_ has joined #akanda | 19:57 | |
| *** cleverdevil has quit IRC | 20:00 | |
| *** sarob has joined #akanda | 20:09 | |
| openstackgerrit | Adam Gandelman proposed stackforge/akanda-rug: Do not hard-code requirements path when adding blessed https://review.openstack.org/187283 | 20:10 |
| *** sarob has quit IRC | 20:17 | |
| openstackgerrit | Adam Gandelman proposed stackforge/akanda-rug: Remove blessed from requirements https://review.openstack.org/187283 | 20:31 |
| *** puranamr has quit IRC | 20:32 | |
| *** sarob has joined #akanda | 20:32 | |
| *** puranamr has joined #akanda | 20:56 | |
| *** rods has quit IRC | 20:58 | |
| *** rods has joined #akanda | 20:58 | |
| *** rods has quit IRC | 21:03 | |
| openstackgerrit | Adam Gandelman proposed stackforge/akanda-rug: Remove blessed from requirements https://review.openstack.org/187283 | 21:04 |
| *** rods has joined #akanda | 21:04 | |
| *** sarob has quit IRC | 21:12 | |
| openstackgerrit | Adam Gandelman proposed stackforge/akanda-rug: Remove blessed from requirements https://review.openstack.org/187283 | 21:27 |
| *** stupidnic has joined #akanda | 21:42 | |
| puranamr | 21:59 | |
| puranamr | does the rug also see the messages that neutron plugins send across to neutron | 21:59 |
| puranamr | and other question, is does the rug also get to update the database in place of the neutron-agents | 22:01 |
| adam_g | puranamr, it subscribes to these based on routing_key | 22:02 |
| puranamr | adam_g, so if we need to, we could see the plugin messages too, right? | 22:03 |
| adam_g | puranamr, which messages specifically? | 22:03 |
| puranamr | if we subscribe to the plugin messages i mean | 22:03 |
| adam_g | puranamr, i think we could if not already. the akanda-neutron plugin should be getting those messages and acting on them there | 22:04 |
| puranamr | i do not remember if Doug touched upon it, in the last week walkthrough | 22:07 |
| *** openstackgerrit has quit IRC | 22:07 | |
| *** openstackgerrit has joined #akanda | 22:07 | |
| puranamr | sorry if i am sounding stupid. but in all the presentations (akanda) we have talked about L3 Agents and not sure whether that covers the plugins too? | 22:08 |
| *** rods has quit IRC | 22:09 | |
| adam_g | puranamr, we do here as well https://git.openstack.org/cgit/stackforge/akanda-rug/tree/akanda/rug/api/neutron.py#n248 | 22:12 |
| adam_g | puranamr, im still wrapping my head around the messaging layer too | 22:13 |
| puranamr | sure, i know it is tricky, but thank you that helps. | 22:13 |
| puranamr | so the for the second part of the question, we update the neutron database too ( i mean akanda-rug sends commands) | 22:14 |
| adam_g | puranamr, its my understanding that the subscribes to certain notification and message topics as a passive consumer in notifications.py (we listen to them but do not consume them entirely from the queue), and subscribe to the plugin topics for purposes of servicing agent certain RPC requests | 22:16 |
| adam_g | the latter being an active consumer, popping off messages from the queue and running RPCs | 22:16 |
| adam_g | markmcclain, is that accurate? | 22:16 |
| *** rods has joined #akanda | 22:17 | |
| *** rods has quit IRC | 22:17 | |
| *** rods1 has joined #akanda | 22:17 | |
| puranamr | so is it possible that we over-run the listening queue and ensure that the messages we r interested never gets serviced? | 22:17 |
| adam_g | puranamr, for some things (like notifications), we may be one of many things subscribed to the queue and interested. for those we want to get the message but not have it terminate at us, so that other things like ceilometer can see it. for other things like RPC, we want to get the message and service it | 22:20 |
| adam_g | for the former, that happens in the way queues are being setup in notifications.py.. we're declaring our own akanda.* queues on exchanges+topics we care about, and rabbit makes sure our akanda.* queues get copies of the messages | 22:21 |
| puranamr | adam_g, i agree, my thoughts are going bit wild to see if we can create a DOS attack | 22:21 |
| puranamr | adam_g, the context i was also thinking was sometimes service-vm becomes unresponsive | 22:28 |
| puranamr | may be because of (nova / neutron), but those SVMs have to be move to blocked list and bring up the rest, so was wondering if any kind of choking is happening | 22:29 |
| adam_g | puranamr, the service appliance itself isn't subscribed to any messaging | 22:30 |
| puranamr | adam_g, sorry if i confused you, i was checking on the case when we reach some 1200 or so SVMs on a single cluster, they slowly start responding slowly | 22:32 |
| puranamr | ignore if this is an invalid scenario | 22:32 |
| adam_g | puranamr, ah. yeah, we'd like to eventually start testing the control plane specifically for things like that | 22:33 |
| puranamr | so where is the possible bottleneck, in the nova/neutron or our rug not able to keep up? | 22:34 |
| puranamr | i know no quick answer / quickfix, but just was thinking | 22:34 |
| *** cleverde_ is now known as cleverdevil | 22:34 | |
| puranamr | adam_g, what about neutron-database access, does the rug write all the serviced commands / requests too? | 22:37 |
| adam_g | puranamr, some of that is nova + neutron's responsibility. one place we'd care about is how does the RUG handle managing many service VMs when the nova or neutron APIs become slow, or when service VMs are slow to repsond on their own REST APIs | 22:38 |
| adam_g | puranamr, we dont touch the neutron database | 22:38 |
| adam_g | not directly, at least | 22:38 |
| puranamr | yes, adapting to slow nova / neutron API becoming slow would make the rug pretty robust, | 22:39 |
| puranamr | adam_g, on a packet flow question, does all the packets / packet flows flow through the Service VM or once installed (rules) it becomes passive? | 22:40 |
| puranamr | adam_g, missed your earlier point, if we don't touch the database, then what happens to the create interface or delete interface / port command info gets stored? | 22:42 |
| adam_g | puranamr, the service vm hosts the network's router, so yea--northbound traffic does | 22:42 |
| puranamr | so there is a possibility of lower throughput? | 22:43 |
| adam_g | puranamr, nova and neutron are responsible for tracking their own state in their own dbs, we only interface with them via REST or RPC APIs | 22:43 |
| adam_g | we dont touch those DB's directly | 22:43 |
| adam_g | puranamr, yea | 22:43 |
| puranamr | adam_g, i suppose we may need datapoint for how the throughput varies with and without SVMs | 22:48 |
| adam_g | puranamr, ya, definitely | 22:50 |
| *** openstackgerrit has quit IRC | 22:51 | |
| puranamr | that may help us make a leaner and efficient SVM | 22:51 |
| *** openstackgerrit has joined #akanda | 22:51 | |
| puranamr | adam_g, i assume that after control plane traffic, the dataplane traffic does not pass through the SVM | 22:52 |
| adam_g | puranamr, i dont follow | 22:53 |
| puranamr | adam_g, say i have a SVM to take care of the router funtionality, after i install the routes, (read it as add/update) the packets no more go through the SVM | 22:54 |
| puranamr | same is the case for FwaaS, (after putting in the iptable rules for example) | 22:54 |
| adam_g | puranamr, im not sure about that | 23:00 |
| adam_g | i dont see why packets would stop go through the virtual router if its the router gateawy for a network? | 23:01 |
| puranamr | adam_g, yeah that makes sense, my understanding so far, was that it was a passive component and not a active one | 23:08 |
| adam_g | puranamr, the rug is passive in that its stateless and not critical to existing tenant things. that is to say, it can go away and existing VMs and networks will still function, but new things wouldn't be created | 23:09 |
| puranamr | yeah i agree abut rug, but my misunderstanding of the SVM | 23:10 |
| puranamr | i suppose the existing SVMs will work, till no commands are sent towards the rug | 23:11 |
| openstackgerrit | Adam Gandelman proposed stackforge/akanda-rug: Remove blessed from requirements https://review.openstack.org/187283 | 23:14 |
| openstackgerrit | Adam Gandelman proposed stackforge/akanda-rug: Remove blessed from requirements https://review.openstack.org/187283 | 23:34 |
| *** rods1 has quit IRC | 23:39 | |
| puranamr | adam_g, did not nit-pick on the change, though were debug commands! | 23:42 |
| adam_g | puranamr, i saw that, thanks. yea--im just trying to get a new devstack job passing. messing around with that one change, not expecting to merge it | 23:43 |
| puranamr | i did not want you to have a distraction though | 23:43 |
| *** cleverdevil has quit IRC | 23:57 | |
| *** puranamr has quit IRC | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
