21:00:00 <flaper87> #startmeeting Zaqar
21:00:01 <openstack> Meeting started Mon Nov 24 21:00:00 2014 UTC and is due to finish in 60 minutes.  The chair is flaper87. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:05 <openstack> The meeting name has been set to 'zaqar'
21:00:06 <flaper87> #topic Roll Call
21:00:14 <vkmc> o/
21:00:15 <flaper87> o/
21:00:39 <flwang1> o/
21:00:50 <flaper87> I guess kgriffs will show up later
21:00:54 <flaper87> lets move on
21:01:01 <flaper87> #topic Finalize specs review
21:01:15 <flaper87> #topic Previous meeting actions
21:01:22 <flaper87> actually
21:01:24 <flaper87> #undo
21:01:24 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x184a050>
21:01:25 <flaper87> #undo
21:01:26 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x184a1d0>
21:01:28 <flaper87> #topic Previous meeting actions
21:01:31 <flaper87> :P
21:01:34 * flaper87 is perfectionist
21:01:43 <flaper87> vkmc to add cpallares as a secondary contact
21:01:46 <flaper87> vkmc: ^
21:01:58 <vkmc> done https://review.openstack.org/#/c/134567/
21:02:30 <flaper87> #info cpallares has been added as a second contact to https://review.openstack.org/#/c/134567/
21:02:35 <flaper87> vkmc to evaluate serialization protocols for the websocket transport
21:02:38 <flaper87> vkmc: ^
21:02:54 <vkmc> done https://etherpad.openstack.org/p/zaqar-serialization-protocol-ws
21:03:11 <flaper87> #info Serialization protocols evaluated here: https://etherpad.openstack.org/p/zaqar-serialization-protocol-ws
21:03:30 <flaper87> vkmc: AFAIR, msgpack won
21:03:31 <vkmc> #info spoiler alert: msgpack wins
21:03:32 <flaper87> right?
21:03:44 <vkmc> right
21:03:48 <flaper87> #info msgpack will be used as the serialization protocol
21:03:54 <flaper87> flaper87 to clarify how notifications will be pushed to clients
21:04:00 * flaper87 can't remember
21:04:03 <flaper87> AFAIK, that's done
21:04:07 <vkmc> ask flaper87
21:04:15 * flaper87 asks flwang1
21:04:17 <flaper87> erm
21:04:19 * flaper87 asks flaper87
21:04:40 <flwang1> lol
21:04:43 <flaper87> ah yeah, that was the workers thingy
21:04:45 <flaper87> it's done
21:04:55 <flwang1> taskflow, IIRC?
21:05:00 <flaper87> #info Workers specification added to the spec https://review.openstack.org/#/c/129192/
21:05:02 <flaper87> flwang1: yeah
21:05:11 <flaper87> ok, we did everything
21:05:16 <vkmc> \o/
21:05:17 <flaper87> #topic Finalize specs review
21:05:33 <flaper87> #link https://review.openstack.org/#/c/129192/
21:05:40 <flaper87> flwang1: that's notifications
21:05:45 <flaper87> AFAIK, you already started working on it
21:05:51 <flaper87> vkmc: could you take a final look?
21:05:55 <flwang1> flaper87: yep
21:05:58 <flaper87> flwang1: already +1'd it
21:06:02 <vkmc> flaper87, of course
21:06:21 <flaper87> kgriffs hasn't gotten back to it but we need to move it forward
21:06:35 <flaper87> we can edit it later if really needed
21:07:23 <flwang1> flaper87: agree
21:07:25 <vkmc> +1 flaper87
21:07:32 <flaper87> vkmc: awesome
21:07:41 <flwang1> flaper87: for some details, we can improve them during code review
21:07:49 <flaper87> vkmc: I don't see your +1
21:07:53 <flwang1> for the overall design, it looks good for me
21:08:06 <flaper87> flwang1: agreed
21:08:15 <vkmc> flaper87, I'll read it carefully after the meeting
21:08:17 <flaper87> vkmc: ah lol
21:08:27 <flaper87> now I understood your +1 thing
21:08:31 <flaper87> hahaha, it was about my last message
21:08:34 * flaper87 slaps himself
21:08:41 <flaper87> ok, moving on
21:08:43 <flaper87> #link https://review.openstack.org/#/c/134567/
21:08:43 <vkmc> yeah :) haha
21:08:49 <flaper87> vkmc: that's persistent transports
21:08:55 <vkmc> I see that
21:09:04 <vkmc> ok so... kgriffs made a good point there
21:09:15 <flaper87> I'm 80% against socketio, socketjs and adabahnanadshdasawhatever
21:09:18 <vkmc> we didn't clarify what we are going to do in case there is no support for websockets
21:09:22 <flaper87> The reasons are expressed there
21:09:45 <vkmc> great, its good to count on your experience to make this decision
21:10:05 <flaper87> There were some good reasons to block websocket when it first came out
21:10:15 <flaper87> I'd like to understand what are nowadays motivations to do so
21:10:17 <vkmc> so.. the other options are tornado and ws4p
21:10:17 <vkmc> y
21:10:29 <flaper87> ws4p is just websocket
21:10:39 <flaper87> it doesn't have support for long-polling
21:10:40 <vkmc> beyond that, there are browsers that doesn't support it
21:10:54 <flaper87> very old browsers you mean, right?
21:11:15 <flaper87> http://caniuse.com/websockets
21:11:29 <flaper87> even IE has support for it
21:11:40 <vkmc> here is a list
21:11:41 <vkmc> http://tavendo.com/blog/post/websocket-why-what-can-i-use-it/
21:11:43 <vkmc> of where it works
21:11:53 * kgriffs joins
21:12:14 <flwang1> what's IE?
21:12:16 <vkmc> better... this is the source http://caniuse.com/#search=websockets
21:12:25 <vkmc> yeah please flaper87, clear that up
21:12:32 <vkmc> what does IE stands for?
21:12:39 <flaper87> IE = Internet Explorer
21:12:43 <flwang1> i'm kidding
21:12:46 <vkmc> still no clue
21:12:49 <flaper87> LOL
21:12:51 <flaper87> :D
21:12:55 <vkmc> :D
21:12:59 <flaper87> kgriffs: discussing persistent transports spec
21:13:33 <flaper87> What I'd like to understand is why would an OPs guy block websocket nowadays
21:13:39 <flaper87> there were some good reasons in the past
21:13:46 <flaper87> but I don't think those are valid anymore
21:13:54 <flaper87> I'm curious to know if there are new good reasons
21:14:34 <flaper87> the good thing aboud long-polling is that it plays well with LB
21:14:52 <flaper87> but again, the whole fallback thing doesn't work as it says it does
21:14:53 <kgriffs> some thoughts on blocking websocket
21:15:22 <kgriffs> first, is some firewalls and stuff are configured to kill http connections after a certain amount of time
21:15:39 <kragniz> o/
21:15:43 * kragniz lurks some
21:15:48 <kgriffs> there is a real cost to persistent connections on networking gear, although that cost is going down, still significant
21:16:28 <kgriffs> so, i have that first-hand from talking with ops people
21:16:33 <flaper87> kgriffs: ok, that's a good reason
21:16:34 <kgriffs> the second one is more speculation
21:16:59 <kgriffs> some people may be paranoid from a security standpoint and they will kill any traffic over port 80 or 443 that doesn't look like HTTP
21:17:29 <flaper87> kgriffs: right but deplying Zaqar + websocket is a manual process
21:17:44 <flaper87> which means OPs know they'll need it to be enabled in the firewall
21:18:01 <kgriffs> yes, but that is only one side
21:18:03 <flaper87> and they'll have to support long-living connections
21:19:19 <kgriffs> what I mean is that you can have one org or company talking to another org or company and you have to have both parties agree to let this traffic through
21:19:40 <flaper87> yup
21:19:41 <kgriffs> nowdays I expect it to work most of the time, but sometimes it won't.
21:19:50 <flaper87> yeah, that's true
21:20:02 <vkmc> that makes sense, but if they are deploying a messaging service like Zaqar I guess that is something they have to consider
21:20:02 <flwang1> kgriffs: +1
21:20:05 <flaper87> I don't have counter-arguments to that
21:20:23 <flaper87> I honestly see the long-poling transport as a separate one
21:20:32 <flaper87> once we have the websocket one setup, it should be fairly simple
21:21:00 * kgriffs is catching up on the comments on the spec
21:21:03 <flaper87> I'm concerned that falling back to long-polling if websocket is not enabled won't be as simple as it sounds from a pub-sub stand point
21:21:35 <flaper87> We'll have to implement the cross-api thingy before finilizing the transport itself
21:21:41 <flaper87> is this something we can revisit later?
21:22:20 <kgriffs> can we just fall back to short polling for now, and look at adding long-polling support later?
21:22:23 <flaper87> kgriffs: I mentioned before you joined that I'm 80% against fallback strategies for this specific thing but I'm happy to change my mind if we see it  can be done/maintained easily
21:22:33 <kgriffs> flaper87: oic
21:22:34 <flaper87> with that I'm not saying that if I don't change my mind we won't do it
21:22:39 <flaper87> it's just my personal opinion
21:22:58 <flaper87> kgriffs: +1 for falling back to short-polling but that's handled by the client
21:23:17 <flaper87> What I'm not happy with is having 1 transport that supports 2 different protocols
21:23:19 <vkmc> we have to make sure we deliver the simplest, fully functional, version of this transport soon
21:23:25 <kgriffs> flaper87: oic
21:23:31 <kgriffs> ala socket.io or SockJS
21:23:35 <flaper87> kgriffs: right
21:23:46 <flaper87> If the client fallsback to something else, I'm ok with that
21:23:50 <kgriffs> it's a question of where you want the fallback abstraction to live
21:24:03 <vkmc> of course, if not having a decent fallback is not acceptable then we have to plan things based on that
21:24:15 <flaper87> but again, it's a personal opinion a bit based on previous experiences that might not even be valid anymore
21:24:30 <kgriffs> I looked at socket.io
21:24:39 <kgriffs> I agree it isn't a great fit for us
21:24:52 <kgriffs> SockJS is more like what we might want
21:25:38 <kgriffs> but, as I said, it doesn't have a non-JS client library, so you have to just use raw websocket and then do your own fallback (to the REST API?) anyway, so it doesn't seem like you gain much from using the library
21:25:38 <vkmc> sockjs doesn't have the abstraction level socketio has
21:25:45 <vkmc> socketio is more like autobahn and wamp
21:26:11 <flaper87> kgriffs: right, at that point I'd rather use w4py which supports asyncio
21:26:28 <flaper87> and it also has a websocket client for python
21:27:24 <flaper87> ok, we need to agree on something there
21:27:32 <vkmc> w4py +1
21:27:34 <flaper87> we can revisit it later if needed
21:27:47 <flaper87> We need to start on the cross-api thingy anyway
21:27:58 <flaper87> so, we still have some time for last minute reviews
21:28:17 <flaper87> kgriffs: flwang1  ?
21:28:35 <flwang1> i'm ok
21:28:45 <vkmc> https://ws4py.readthedocs.org/en/latest/sources/performance/
21:29:25 <flaper87> we can contribute back to the library
21:29:30 <flaper87> and help making it faster, I guess
21:29:37 <vkmc> k
21:29:42 <flwang1> flaper87: oh, really? are we doing to do that?
21:29:48 <flaper87> https://github.com/methane/wsaccel
21:29:49 <kgriffs> if we want to use our persistent transport outside the browser, I think it makes sense to use raw websocket and have the client fallback to short-polling the REST API
21:30:03 <flaper87> kgriffs: +1
21:30:44 <flaper87> ok, I think we can approve that spec them. Would you guys mind casting your votes there?
21:30:45 <kgriffs> we should be able to abstract that away in the client, so apps don't care, other than that things go faster when websockets is available
21:30:52 <flaper87> I'll approve after the meeting
21:31:02 <flaper87> kgriffs: agreed
21:31:13 <vkmc> k
21:31:29 <kgriffs> I just know someone is going to ask about why we didn't use those other things, so be ready with a good reply. :p
21:31:45 <flwang1> kgriffs: lol
21:31:53 <flaper87> Btw, I'm assuming the specs those specs depend on are ok and I'll also approve them
21:32:03 <flaper87> I'm trying to take the most out of the time we have
21:32:09 <flaper87> kgriffs: yeah, I'm sure they will
21:32:19 <flaper87> vkmc: would you mind sumirizing this convo in a wiki page?
21:32:22 <flaper87> Websocket FAQ ?
21:32:27 <flaper87> or in the FAQ itself
21:32:31 <vkmc> flaper87, of course
21:32:36 <flaper87> vkmc: awesome
21:32:54 <vkmc> I'll start that ASAP so we can start with the implementation as well
21:32:56 <flaper87> #action vkmc to write a small FAQ of why we chose raw websocket over socketio sockjs
21:33:04 <flaper87> thanks a lot, girl!
21:33:10 <flaper87> Moving on
21:33:12 <vkmc> np
21:33:14 <flaper87> #link https://review.openstack.org/#/c/125986/
21:33:16 <flaper87> That's FIFO
21:33:24 <flaper87> kgriffs: I addressed your last comment
21:33:24 <kgriffs> question
21:33:43 <kgriffs> actually. nevermind
21:33:48 <flaper87> LOL
21:33:50 <flaper87> :D
21:33:54 <flaper87> don't be shy
21:34:04 <flaper87> flwang1: I also need your review on that spec
21:34:20 <flaper87> is there something you guys want to discuss about that spec?
21:34:29 <flwang1> flaper87: done
21:34:58 <flwang1> flaper87: I think most of the stuff about that have been touched on summit design session
21:35:15 <flaper87> flwang1: right
21:35:48 <kgriffs> flaper87: so, looking at the work items...
21:36:27 <kgriffs> First comment is just to keep in mind that capabilities may include whether or not claiming and deleting are supported (for Symantec's use case)?
21:36:54 <kgriffs> meaning, there are capabilities that have to do with guarantees and also that have to do with supported features
21:37:04 <kgriffs> s/features/operations
21:37:05 <flaper87> kgriffs: right
21:37:12 <flaper87> do we want to separate them ?
21:37:39 <flaper87> This is a draft of the storage capabilities thing: https://review.openstack.org/#/c/135637/
21:38:11 <kgriffs> flaper87: no, just that capabilities should be flexible enough to describe all kinds of things
21:38:17 <flaper87> #link https://review.openstack.org/#/c/135637/
21:38:31 <flaper87> kgriffs: yeah, although they are implementation specific
21:38:45 <flaper87> as in, the capabilities of the redis driver are hard-coded
21:38:59 <flaper87> I haven't worked on a way to make that dynamic yet
21:39:01 <kgriffs> ok, so that was my next question
21:39:11 <kgriffs> the last work item on the spec is: "Add a way to pass capabilities down to the driver"
21:39:11 <flaper87> but as the first step, I thought that's fair
21:40:01 <kgriffs> are you saying that some drivers can be configurable as far as capabilities?
21:40:08 <flaper87> kgriffs: I think that's not worded correctly. What I mean there is that we should pass flavor's capabilities down to the driver level so that the right implementation can be loaded
21:40:25 <flaper87> I'll clarify
21:40:33 <flaper87> For example
21:41:16 <flaper87> The capabilities of a flavor will be the interesection of the capabilities of all the nodes in the pool
21:41:41 <flaper87> Which means, we need to load the storage based on that
21:41:49 <flaper87> Load can mean multiple things here
21:42:03 <flaper87> Either importing the right implementation or just enabling/disabling things
21:42:08 <flaper87> this really depends on the driver
21:43:03 <kgriffs> let me play devil's advocate and ask why allow a flavor to be made up of heterogeneous nodes in the first place?
21:43:04 <flaper87> does that make sense?
21:43:27 <flaper87> kgriffs: that's a good question
21:43:48 <flaper87> kgriffs: the first thing that comes to my mind is that it'd be easier to allow that than forbidding it.
21:43:56 <flaper87> kgriffs: it gives more flexibility to OPs
21:44:05 <flaper87> and we'd have to pass the flavor down to the storage anyway
21:44:58 <flaper87> also
21:45:12 <flaper87> Say I have a storage that doesn't have support for FIFO and one that does
21:45:17 <flaper87> but I don't care about FIFO
21:45:30 <flaper87> forbidding me to put them together wouldn't be nice
21:45:49 <flaper87> But I'm just making this up without any empirical research
21:45:56 <kgriffs> hmmm
21:46:34 <kgriffs> ok, so suppose I have those two drivers
21:46:44 <kgriffs> and I want to use both in the same flavor
21:47:15 <kgriffs> idk why I would do that in the first place, because they would have different characteristics - one might be slower, for example
21:47:25 <flaper87> right
21:47:28 <flaper87> so, lets do this
21:47:49 <kgriffs> now my users have different emergent behavior depending on which node they end up for a given flavor
21:47:51 <flaper87> I would hate us to overengineer things so, lets just forbid it for now and enable it in the future
21:47:58 <flaper87> if people think it makes sense
21:48:08 <flaper87> it'll be easier to enable it in the future than removing it
21:48:23 <flaper87> does that sound good?
21:48:29 <flaper87> I'll update the spec if it does
21:48:33 <kgriffs> yes, just a few more thoughts real quick
21:48:38 <flaper87> kgriffs: sure
21:49:09 <kgriffs> if we enforce that a flavor is made up of nodes that basically use the same drivers with the same configuration/capabilities settings
21:50:09 <kgriffs> then you don't have to try and figure out the least-common denominator of capabilities
21:50:35 <flaper87> right, that wouldn't be needed anymore
21:50:36 <kgriffs> i just think it will actually be easier for ops to reason about the system by forcing homogenous pools
21:50:50 <flaper87> kgriffs: +2, I'm now convinced of that
21:50:51 <kgriffs> like you say, we can allow it later if people ask for it
21:50:59 <flaper87> +2
21:51:04 <kgriffs> flaper87: so what is the workflow?
21:51:15 <kgriffs> Susan the operator creates a flavor
21:51:26 <flaper87> Susan creates a pool
21:51:32 <flaper87> Then Susan creates a flavor
21:51:45 <flaper87> Then the user Pippo creates a queue that uses that flavor
21:51:54 <flaper87> Pippo posts messages
21:52:15 <flaper87> Internally, when the queue creation happens, a new queue is registered in the catalog
21:52:57 * flaper87 reminds everyone we've 8 mins left
21:53:27 <kgriffs> ok, real quick...
21:53:47 <flwang1> kgriffs: btw, could you please revisit the notification spec at your most convenience?
21:53:54 <kgriffs> the thing then to figure out is how to ensure that when adding new nodes to a pool, they all have the same capabilities
21:54:08 <flwang1> kgriffs: it's a good question
21:54:10 <kgriffs> if that can be ensured
21:54:27 <flaper87> kgriffs: that can be ensured when the node is added by introspecting the capabilities
21:54:42 <kgriffs> then it shouldn't be hard to express those capabilities in the flavor
21:54:52 <flaper87> the driver is loaded based on the configs and node connection uri
21:54:55 <kgriffs> so the flavor just reports up the capabilities introspected from the lower layer
21:55:00 <flaper87> it shouldn't be hard to enforce this thing
21:55:09 <flaper87> kgriffs: right, that's the idea
21:55:15 <kgriffs> kk
21:55:31 <flaper87> kgriffs: is it ok if I update the spec with your latest comments and approve it?
21:55:40 <flaper87> or do you have other things you'd like to discuss?
21:55:56 <kgriffs> flwang1: I've asked for some feedback from some other Rackspace folks, hopefully people will comment. I will take another look as well if I can steal some time.
21:56:12 <kgriffs> flaper87: that's all I had to discuss
21:56:17 <flwang1> kgriffs: cool, cheers
21:56:26 <flaper87> flwang1: FWIW, I think I'll go ahead and approve the notifications spec, we can update it if needed
21:56:39 <flaper87> I think we all agree on the basis
21:56:43 <flwang1> i'm ok if kgriffs is ok :)
21:56:46 <flaper87> that's enough for flwang1 to start working on it
21:56:55 <flwang1> flaper87: it's true :)
21:57:09 <flaper87> For the more specific things, we can revisit them
21:57:15 <flaper87> or even change some things during the review
21:57:24 <flaper87> ok, 3 mins left
21:57:28 <flaper87> #topic Open Discussion
21:57:35 <flaper87> anything to share?
21:58:07 <vkmc> yes... if someone see some technical debt in the code, please report the bug
21:58:20 <flaper87> vkmc: +2
21:58:28 <vkmc> lately we have been fixing stuff without reporting
21:58:34 <vkmc> and it makes harder to keep track of changes
21:58:34 <flaper87> Also, I'm almost done with fixing our functional gate for the client
21:58:48 <flaper87> but we should test the client better
21:58:49 <vkmc> and don't allow new people to get stuff to do
21:58:52 <flaper87> there are too few bugs
21:58:57 <vkmc> yeah
21:58:58 <flaper87> vkmc: +2
21:59:09 <flaper87> ok, that's it folks
21:59:23 <vkmc> :)
21:59:25 <flaper87> flwang1: kgriffs vkmc thank you all for attending. tty next week!
21:59:27 <flwang1> flaper87: I can create more bugs in notifications code so that the new comer can get something to work
21:59:35 <flaper87> who am I kidding? tty in 2 secs
21:59:40 <flaper87> flwang1: +2
21:59:44 <vkmc> haha
21:59:47 <vkmc> +2 flwang1
21:59:49 <flwang1> back to zaqar channel
21:59:51 <flaper87> :P
21:59:57 <flaper87> #endmeeting