18:01:38 <vipul> #startmeeting cue
18:01:38 <openstack> Meeting started Tue Sep  1 18:01:38 2015 UTC and is due to finish in 60 minutes.  The chair is vipul. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:41 <openstack> The meeting name has been set to 'cue'
18:01:46 <esmute_> o/
18:02:27 <vipul> davideagnello: abitha sputnik13 dkalleg: yo
18:02:37 <dkalleg> o/
18:03:14 <vipul> #link https://wiki.openstack.org/wiki/Meetings/Cue
18:03:19 <vipul> light on the agenda..
18:04:09 <vipul> #topic Action Items
18:04:13 <vipul> #link http://eavesdrop.openstack.org/meetings/cue/2015/cue.2015-08-25-18.01.html
18:04:21 <vipul> given that sputnik13 isn't here.. i'll skip his
18:04:29 <vipul> dkalleg to provide details in https://blueprints.launchpad.net/cue/+spec/status regarding more accurate rabbitmq status check
18:04:38 <vipul> and update on this dkalleg ?
18:04:57 <dkalleg> not yet
18:05:20 <dkalleg> Still need to do some investigation on how to extract the info we really want
18:05:35 <vipul> Ok sounds good..
18:05:42 <vipul> i'll put it back on the docket for next week
18:05:47 <vipul> #action dkalleg to provide details in https://blueprints.launchpad.net/cue/+spec/status regarding more accurate rabbitmq status check
18:05:50 <dkalleg> ok
18:05:53 <vipul> #action sputnik13 to fill in details for https://blueprints.launchpad.net/cue/+spec/kafka
18:06:07 <vipul> davideagnello: yt?
18:06:33 <vipul> #action davideagnello to file a BP for https://bugs.launchpad.net/cue/+bug/1438939
18:06:34 <openstack> Launchpad bug 1438939 in Cue "Cue CLI cluster list fields should show cluster size" [Wishlist,New]
18:06:55 <vipul> Any discussion topics to bring up?
18:07:10 <sputnik13> l/
18:07:10 <esmute_> python 34
18:07:11 <sputnik13> o/
18:07:14 <davideagnello> o/
18:07:16 <vipul> #topic Python 34
18:07:16 <sputnik13> we have bugs to discuss
18:07:30 <vipul> esmute_: go
18:07:39 <esmute_> whoever has some cycle, there is this #link https://review.openstack.org/#/c/210598/
18:07:43 <davideagnello> BP for updating python cue client is created
18:07:56 <esmute_> and #link https://review.openstack.org/#/c/211277/
18:08:09 <esmute_> i have corrected some errors but  there a a few mores..
18:08:20 <esmute_> ill try to get them this week...
18:08:33 <esmute_> the job is non-voting now..
18:08:40 <davideagnello> wanted to bring up a new BP I added on multi-broker support #link https://blueprints.launchpad.net/cue/+spec/multi-broker-support
18:08:45 <esmute_> but it will be voting once i resolved all the python3 issues...
18:09:02 <sputnik13> vipul ^ for next topic
18:09:06 <vipul> esmute_: does the python34 job do a good job of idenfying what needs to be fixed?
18:09:23 <vipul> sputnik13: davideagnello yea.. next time please update https://wiki.openstack.org/wiki/Meetings/Cue :)
18:09:32 <esmute_> yes.. .it creates a python 3.4 env to run tox on
18:09:33 <sputnik13> sir yes sir
18:09:45 <esmute_> most of the issues has to do with encoding unicode and strings
18:09:53 <davideagnello> while working on the username/password feature, it was evident that we need to assess this properly
18:10:12 <vipul> davideagnello: yep.. let's wait for that topic
18:10:22 <vipul> ok esmute_ so you just need eyes on the patch?
18:10:26 <davideagnello> vilobhmm1: ok
18:10:32 <davideagnello> vipul: ok
18:10:39 <sputnik13> WRT python 3.4, yeah str vs unicode is going to be an issue in multiple places
18:10:49 <esmute_> vipul: i need to resolve more issues and then ill put it up for review
18:10:56 <sputnik13> in general we shouldn't try to work around this with a decode('utf8')
18:10:59 <esmute_> there are so many of them sputnik13
18:11:18 <vipul> what's the right fix?
18:11:22 <sputnik13> there will be places where it's unavoidable, but I think it should be a last resort
18:12:02 <sputnik13> esmute_: yeah I'm sure there are, I think there's little to nothing we did to make sure the code is ok for both 2.x and 3.x :)
18:12:19 <esmute_> vipul: im just replacing any StringIO objects to unicode or byte array
18:12:43 <sputnik13> vipul: in instances where we're specifying the string it shouldn't be a problem, right, but one of the cases was where we were loading a json file
18:12:56 <esmute_> i think sputnik13 mentioned there is a library in oslo to use that will work for both 2.x and 3.x
18:13:19 <sputnik13> the json library has support for loading from a file directly, which works fine, but we were reading the file we were reading as a binary blob then passing to json as a string
18:13:46 <sputnik13> since the 3.x version expects the string to be a 3.4 string (i.e. unicode) and we were passing in a binary blob (which is a string in 2.x) it was breaking
18:13:59 <esmute_> anyways.. i just need to take a day or so and should be able to get them
18:14:10 <sputnik13> the "right thing" in that instance is to use the json lib function for loading from file
18:14:47 <esmute_> sputnik13: is there an oslo lib to read the json data?
18:14:48 <vipul> got it.. yea we should do that instead of a band-aid for cases like json parsing
18:15:10 <sputnik13> esmute_: no, don't need to use oslo, json already supports reading a file, but we were passing the contents of the file for some reason
18:15:27 <esmute_> sputnik13: got it
18:15:29 <sputnik13> so the fix there was to use the json function for reading from file, and pass the file path to it
18:15:56 <sputnik13> I think in most cases unicode vs string won't be an issue, unless we're dealing with files
18:16:13 <sputnik13> because string literals in 3.x is treated as unicode by default
18:16:45 <esmute_> yeah.. i was bandaid them by explicitly passing a utf8 encoding to them
18:16:54 <vipul> We shoudl also look at how other project approached this migration.. we can't be alone
18:17:02 <sputnik13> right, but files aren't always utf8
18:17:20 <sputnik13> that's the crux of the issue with "casting" to utf8
18:17:57 <esmute_> vipul: yeah.. but not many projects support py34 yet... let alone have a voting job
18:18:09 <sputnik13> we're trailblazers, yay! :)
18:18:37 <vipul> or the jailblazers
18:18:47 <vipul> ok anything else on this?
18:18:47 <esmute_> anyways..  i just need to have sometimes alone to focus on this and get this to work
18:18:51 <sputnik13> anyway, I think the main point is, we have a 3.4 job, which is good
18:19:27 <sputnik13> and since we're not on some timeline to fix things, let's try and fix them the right way
18:19:45 <sputnik13> I also don't think we should have a single patch for all 3.4 fixes
18:19:57 <esmute_> why not sputnik13?
18:20:12 <sputnik13> because there will inevitably be some fix or other that takes a while
18:20:18 <sputnik13> and 3.4 is low on our priority list
18:20:21 <esmute_> if they are all in one patch, we can make sure we address all the fix and make the job voting
18:20:43 <sputnik13> esmute_: right and that patch can be outstanding for a long time...  so, rebase hell
18:20:44 <sputnik13> :)
18:20:59 <vipul> if we can get to that point quickly i agree esmute_ but what will end up happening is new code might keep breaking things as well
18:21:24 <vipul> until you start merging stuff in and teaching the rest of us what to avoid ;)
18:21:35 <sputnik13> right
18:21:38 <esmute_> how would you guys know that these changes is actually fixing the issue?
18:21:50 <sputnik13> esmute_: what do you mean
18:22:00 <esmute_> wouldnt the gate passing tell you whether the patch is correct?
18:22:25 <esmute_> sputnik13: if i submit a patch to fix some partial py34 errors, how can we validate that?
18:22:30 <sputnik13> we are presumably addressing specific errors in the gate with each patch
18:22:45 <sputnik13> as long as it doesn't break 2.7 it should be OK
18:22:56 <sputnik13> the overall goal is to work toward 3.4 passing
18:23:00 <esmute_> ok
18:23:09 <vipul> esmute_: i nominate you to educate the rest of us at some point on what to avoid going forward
18:23:16 <sputnik13> but because there's no priority on this, I'm just saying that patch can be outstanding for a long long time
18:23:33 <esmute_> ill look at what is there, change any bandages for better optimal solutions and rebase
18:23:34 <sputnik13> and it'll have to be rebased over that time
18:24:02 <sputnik13> and if whatever code was fixed for 3.4 gets modified then merged, then there will be merge conflicts
18:24:11 <esmute_> vipul: ok.. ill come out with a do/dont list for python3 during the thursday meeting
18:24:38 <vipul> ok let's move on
18:24:42 <sputnik13> ok
18:24:47 <vipul> #topic multi-broker support
18:24:53 <vipul> davideagnello: go
18:25:10 <davideagnello> wanted to bring up a new BP I added on multi-broker support #link https://blueprints.launchpad.net/cue/+spec/multi-broker-support
18:25:24 <davideagnello> while working on the username/password feature, it was evident that we need to assess this properly
18:25:42 <davideagnello> this will be required when we will add the next broker to Cue
18:26:05 <sputnik13> I nominate davideagnello to shepherd this through }:-)
18:26:09 <vipul> is this specifically internal refactoring? or are we talking about a wholistic concept of brokers
18:26:27 <esmute_> sputnik13: i think he is already nominated by default :p
18:26:47 <sputnik13> esmute_: agreed, I'm suggesting we make it public record ;-)
18:26:49 <davideagnello> I think it will at least require some refactoring, but maybe we want more thought on how to approach this
18:26:51 <esmute_> vipul: a little bit of both but more of the latter
18:27:03 <davideagnello> haha
18:27:31 <davideagnello> maybe we want to support a plug-in type model, maybe not
18:27:46 <sputnik13> right, we can apply little patches here and there but supporting multiple brokers is a big enough thing we should probably give it more thought upfront
18:28:03 <davideagnello> sputnik13: yes
18:28:04 <esmute_> we need to come out with concepts to have brokers pluggables.. they can be done as strategies (like trove datastore)
18:28:07 <sputnik13> I like the plug-in model as it will allow broker vendors to add support for their brokers
18:28:13 <vipul> so we need to support multiple brokers.. we need to allow the user to pick what they want.. and brokers have inherent differences that we need to accoutn for
18:28:26 <sputnik13> and we can get more contributors as an extension
18:28:41 <sputnik13> then, mid-cycle!
18:28:43 <vipul> sputnik13: yes.. and we need external vendors to be able to do this without having to be in-tree
18:29:04 <davideagnello> plug-in model will require for our api to be extensible as well
18:29:07 <esmute_> are we storing any information about the broker in the DB?
18:29:13 <sputnik13> not having to be in-tree would make things easier on both parties (cue-core and plugins)
18:29:23 <davideagnello> esmute_: nope, not right now
18:29:29 <sputnik13> however, I don't think that's a requirement to having a plugin model
18:29:46 <sputnik13> davideagnello: not true
18:30:05 <sputnik13> we do have the broker concept, it's just incomplete
18:30:16 <sputnik13> and there's no validation
18:30:24 <davideagnello> since different brokers might enable new features or options that would have to be translated through our api?
18:30:57 <sputnik13> I think that depends
18:31:00 <davideagnello> sputnik13: yes, we don't validate brokers currently since we inherently assume rabbitmq :)
18:31:04 <esmute_> ok looks like someone (davideagnello) should come out with a general way to do this in a BP....  and in the mean time, whatever feature we do, we just have to keep an open mind about future support for multiple brokers
18:31:25 <sputnik13> yes "someone" needs to document these things
18:31:26 <vipul> IMO we need to be able to model features / cluster characteristics outside of the 'create cluster' api
18:31:27 <esmute_> and then we can have something concrete to talk about
18:31:27 <sputnik13> :)
18:31:42 <sputnik13> right
18:31:44 <vipul> esmute_: +1
18:31:51 <sputnik13> +100000
18:31:51 <davideagnello> ok, makes sense
18:32:12 <vipul> so, yes.. we need to do this.. and sounds like davideagnello is going to work on this
18:32:17 <vipul> anythign else to discuss on this?
18:32:23 <sputnik13> I think there's value in keeping the API simple and keeping specific broker features outside of the API
18:32:24 <esmute_> davideagnello: i like pretty pictures :p
18:32:34 <davideagnello> lol, yeah sure
18:32:51 <sputnik13> but maybe there's some opportunity to model things to be agnostic to these differences at the API level
18:33:15 <sputnik13> and now that we have this fancy shmancy API doc generator, it should actually be easier for us to version the API
18:33:19 <davideagnello> sputnik13: can you clarify?
18:33:34 <davideagnello> " to be agnostic to these differences at the API level"
18:33:46 <vipul> i think he means at the 'create cluster' api level
18:34:10 <sputnik13> "cluster" doesn't necessarily have to be aware of each broker
18:34:12 <esmute_> sputnik13: data bags all the things!
18:34:15 <sputnik13> right
18:34:20 <davideagnello> vipul: ok
18:34:50 <sputnik13> in so far as we're more about creating and managing clusters, we shouldn't add support for all of the different wizzbang features of all brokers to the cluster API
18:35:00 <vipul> other projects that do clustering approach this via cluster templates / cluster blueprints
18:35:13 <sputnik13> esmute_: that's one approach
18:35:31 <vipul> so that they can keep the provisioning api simple and get reuse of templates
18:35:49 <davideagnello> ok, will look into how others are supporting this currently
18:35:56 <vipul> for example.. sahara.. or ambari
18:36:03 <davideagnello> ok
18:36:06 <vipul> trove takes the databag approach
18:36:09 <vipul> so both could work
18:36:19 <davideagnello> what do you mean by databag?
18:36:29 <sputnik13> blob
18:36:36 <esmute_> sputnik13: i meant to reference the meme :p
18:36:43 <vipul> generic dictionary to hold contents that are specific to borkers
18:36:49 <vipul> borkers lol
18:37:02 <sputnik13> freudian slip
18:37:07 <sputnik13> we know what you're really thinking now
18:37:12 <vipul> ;D
18:37:48 <vipul> ok anyway.. i think you got some requirements and some opinions at the same time
18:37:52 <vipul> davideagnello: ^
18:37:57 <davideagnello> ok, got it.  kind of how we are supporting different auth types
18:38:12 <sputnik13> yes
18:38:31 <sputnik13> go write it up and let the bashing begin
18:38:36 <sputnik13> errr feedback loop
18:38:43 <sputnik13> :-D
18:38:53 <vipul> let's use the openstack wiki and link to the BP
18:38:53 <davideagnello> lol
18:39:04 <sputnik13> or we can do specs
18:39:15 <sputnik13> specs would be more in line with openstack
18:39:17 <vipul> errr..
18:39:33 <vipul> not quite ready for that
18:39:40 <vipul> i don't want to hold this up for that
18:39:47 <vipul> this is a good summit discussion topic
18:39:59 <sputnik13> you're not emotionally ready to dive in to specs, I understand
18:40:15 <sputnik13> do we have rooms for the summit?
18:40:18 <vipul> i don't know if it is the solution either ;)
18:40:23 <vipul> ok anything else?
18:40:34 <vipul> #topic summit topics
18:40:43 <vipul> now i will answer your question sputnik13  ;)
18:40:48 <sputnik13> do we automatically get rooms for the summit or does that need to be requested?
18:40:49 <vipul> yes.. we can get dedicated rooms
18:41:01 <esmute_> vipul: because of big tent?
18:41:07 <vipul> ttx has already approached me, i need to get him a count
18:41:11 <sputnik13> is there going to be anyone there in the room?
18:41:13 <sputnik13> ;)
18:41:27 <vipul> so here's there format
18:41:54 <esmute_> well, if we all could go, we can expect at least 7 there :p
18:42:15 <sputnik13> you should talk to meg about that
18:42:16 <vipul> ugh internet issues..
18:42:21 <vipul> trying to load up paste.o.o
18:42:26 <sputnik13> :)
18:42:32 <vipul> * Fishbowl slots (Wed-Thu)
18:42:33 <sputnik13> I support you 10000%
18:42:34 <vipul> Our traditional largish rooms organized in fishbowl style, with
18:42:34 <vipul> advertised session content on the summit schedule for increased external
18:42:34 <vipul> participation. Ideal for when wider feedback is essential.
18:42:34 <vipul> * Workroom slots (Tue-Thu)
18:42:35 <vipul> Small rooms organized in boardroom style, with topic buried in the
18:42:36 <vipul> session description, in an effort to limit attendance and not overcrowd
18:42:37 <vipul> the room. Ideal to get work done and prioritize work in small teams. New
18:42:38 <vipul> in Tokyo: those rooms now come with a large monitor in case you want to
18:42:39 <vipul> display common stuff.
18:42:40 <vipul> * Contributors meetup (Fri)
18:42:41 <vipul> Half-day session(s) on the Friday to get into the Mitaka action while
18:42:42 <vipul> decisions and plans are still hot, or to finish discussions started
18:42:43 <vipul> during the week, whatever works for you.
18:43:03 <vipul> or better https://gist.github.com/vipulsabhaya/cf6566d899821cce1816
18:43:28 <vipul> I think we should do 1 fishbowl slot for 'multi-broker' support
18:43:36 <sputnik13> I think we want more participation so fishbowl for sure
18:43:49 <esmute_> vipul: when do we know who can go to the summit?
18:43:59 <vipul> any other topics that deserve fishbowl?
18:44:19 <vipul> esmute_: i'll answer on internal chat ;)
18:44:58 <sputnik13> I thought we couldn't say the i word on irc
18:45:04 <sputnik13> :)
18:45:24 <sputnik13> other topics for fishbowl...  next broker to support?
18:45:26 <vipul> so any other topics for summit.. i'm thinking 1 fishbowl and 1 workroom
18:45:41 <sputnik13> that could be fishbowl or workroom
18:45:57 <vipul> sputnik13: yes
18:46:06 <vipul> i don't know if it's a fishbowl though
18:46:37 <davideagnello> self healing clusters?
18:46:37 <esmute_> vipul: i would say the workroom should be sufficient..
18:46:37 <sputnik13> is there any coverage on the nova role thing we talked about at the last summit?
18:46:45 <esmute_> it would look less empty :)
18:46:53 <sputnik13> about how services need different roles for service VMs
18:47:23 <sputnik13> so that they can exist in a special state alongside tenants' VMs
18:47:43 <vipul> sputnik13: no that kind of died..
18:48:01 <vipul> that should be a cross-project session
18:48:06 <vipul> we should submit one
18:48:17 <sputnik13> maybe it's not roles per se, but some attribute to mark service VMs as different from user VMs so they can reside on the same tenant
18:48:29 <sputnik13> it's a good idea
18:48:56 <sputnik13> did it die because nobody was driving it, or because there's opposition?
18:49:10 <vipul> davideagnello: that's a lofty topic.. i would like to keep them to things we can accomplish in M
18:49:23 <vipul> davideagnello: i think there is a lot of stuff that woudl build into that
18:49:36 <vipul> sputnik13: lack of a driver
18:49:46 <davideagnello> vipul: ok, to accomplish within a milestone?
18:50:33 <esmute_> we also need to talk about how to link broker management web UI
18:50:45 <esmute_> which would probably require support for FIP
18:51:31 <esmute_> and of course a feature to grow/shrink clusters
18:51:49 <vipul> am i back?
18:51:49 <vipul> jeez wifi issues
18:52:15 <esmute_> FIP = floating ip
18:53:11 <vipul> knock knock
18:53:12 <vipul> this thing on?
18:53:23 <esmute_> i read you vipul
18:53:30 <vipul> ok cool thanks esmute_
18:53:34 <vipul> missed a few messages
18:53:59 <vipul> #action vipul sputnik13 to file cross-project summit discussion on service VMs
18:54:04 <sputnik13> davideagnello: self healing cluster would probably be impacted by multi-broker support
18:54:18 <sputnik13> ideally we want that to be supported by whatever is supporting the broker
18:54:49 <davideagnello> sputnik13: definitely
18:54:52 <vipul> ok so moving on.. sounds like we have a couple of topics for the summit
18:55:00 <vipul> #topic open discussion
18:55:32 <sputnik13> we have bugs, but I don't think we have time for it
18:55:43 <vipul> yea we can cover those next meeting
18:55:48 <vipul> going once..
18:56:06 <sputnik13> I think we're good
18:56:11 <vipul> #endmeeting