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