14:02:43 #startmeeting glance 14:02:44 Meeting started Thu Oct 24 14:02:43 2013 UTC and is due to finish in 60 minutes. The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:48 The meeting name has been set to 'glance' 14:03:26 sorry for the delay, doing some last minute agenda editiing 14:03:41 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:04:13 Anybody here who doesn't see their item in the agenda, feel free to add it now 14:04:53 let's get started 14:05:00 #topic project status meeting updates 14:05:33 well, this was short this week, all I think we did was talk about summit scheduling 14:06:27 which is an item further on in the list, so yeah 14:06:33 #topic broken tests in master 14:07:47 I think most people here are familiar by now, the iso8601 datetime parsing changed a bit between 0.1.4 and 0.1.8 (the next okay release) 14:08:35 nikhil|afk and zhiyan1 were getting after it, but we didn't end up getting much help from openstack/requirements 14:09:05 I sent out this 14:09:06 #link http://lists.openstack.org/pipermail/openstack-dev/2013-October/017302.html 14:09:19 seems like consensus there was that we should just update to 0.1.8 across the board 14:09:37 markwash: global requirement has been merged 14:09:42 >=0.1.8 14:10:00 oh, hurray 14:10:02 late breaking news 14:10:23 lol 14:11:00 https://review.openstack.org/#/c/53567 14:11:17 we had so many different patches submitted, I didn't realize :-) 14:11:22 I just abandoned mine 14:11:32 okay great, so the glance patch needed is. . . 14:12:21 zhiyan1 has submit a patch to remove the broken test case 14:12:48 flwang: sorry i have not remove them, but enhance them 14:13:09 #link https://review.openstack.org/#/c/52894/8 14:13:15 zhiyan1: I mean the '2011-09-05' case 14:13:56 okay, let's see if we can get that fixed up and in today 14:14:09 flwang: my first case does that YYYY-MM-DD 14:14:17 is there anything else to talk about for that issue here today? 14:14:52 zhiyan1: ok, got 14:15:18 okay, moving on 14:15:27 #topic design summit sessions 14:15:41 #link http://summit.openstack.org/ 14:15:57 I did a run through last night approving, rejecting, and adding comments about merging topics 14:16:42 but I think maybe the comments are not readable by an anonymous user? 14:18:04 If you have feedback about my selections, please share it, either here or privately later if you prefer 14:18:50 questions about the summit? 14:19:06 markwash: btw, if i have clear bp in mind but not proposed to session, i ok? 14:19:50 zhiyan1: can you clarify that? you have a bp, but no session for it? 14:20:14 i mean we don't need discuss all bp plan in the session .. just make sure, and i don discuss that with you directly later.. 14:20:35 right, we don't necessarily have to discuss every icehouse bp in the summit 14:20:37 s/don/will , sorry 14:21:16 some sessions were (gently) refused because I didn't think we were likely to have any fight about the idea 14:21:17 markwash: how many slots do we have? 14:21:21 iccha: 5 14:21:40 so there were several great proposals for stuff that needs to follow on the async and import work 14:22:10 and most of the time I just said "I think everyone is mostly on the same page, let's just follow up on in meetings and on the mailing list." 14:22:37 (thinking, can i have ~10 mins for "indexing" async work? ) 14:23:15 zhiyan1: at the summit? or here today? 14:23:22 summit 14:23:29 ..within import work 14:24:05 zhiyan1: I'm not sure, I don't see a great fit with the existing approved talks 14:24:13 zhiyan1: but I think we'd all like to hear about it 14:24:28 keep in mind, a lot of glance core actually won't be at the summit 14:24:36 yes, we can talk off line after session if you and nikhil|afk like 14:24:38 so it might be more useful overall to try to bring it up in a different forum 14:24:42 l 14:24:45 we have 5 in preapproved state, so looks like we re in good shape. 14:25:02 okay, I think we can move on to the next topic 14:25:22 #topic taskflow 14:25:48 harlowja had the time to sit down and school me about taskflow this past week 14:26:12 I think, given its traction with other projects and its similarity with what we're trying to accomplish, it makes a lot of sense to use 14:26:16 I was a bit hesitant before 14:26:30 I think the question for us is, to what extent can we integrate in Icehouse 14:26:39 what were the main take aways from the conversation? 14:27:02 the main takeaway was that there are rather 3 levels of integration that might make sense 14:27:20 1) just breaking up and defining the work to be done as tasks and flows, similar to what cinder has right now 14:27:28 2) actually using an engine to construct the flows 14:27:48 3) something complicated that i don't remember… maybe having the flows be more portable to deal with machine failures? 14:27:59 it seemed like the question for us for Icehouse was, #1 or #2? 14:28:24 I think at #2, we might expect that the engines to more or less replace our executor code 14:28:26 markwash: cool. saw your message with harlowja, so seems you(s) plan not implement worker in glance internal, at stage 2, just waiting taskflow implement 'RPC worker/engine' part in I, and we focus on stage 1, right? 14:28:55 markwash: what are the deployment expectations with taskflow? 14:29:05 would it live on glance node? 14:29:23 zhiyan1: I think its still an important question, whether we implement a worker or just use an RPC engine 14:29:30 iirc 3) is "job posting" mechanism 14:29:32 zhiyan1: and probably depends as much on the timing as anything 14:29:58 rosmaita: I think the deployment expectations are the same 14:30:31 rosmaita: i.e. the deployer has the option to have the work done either on the api node (like our eventlet model before) or remotely on a pool of worker nodes 14:30:45 ok 14:30:48 rosmaita: does that agree with your understanding of it / concerns? 14:31:15 markwash: ok (i have a topic for that, we can discuss glance-worker on session) 14:31:18 my concern is mainly not requiring something too heavy-duty as part of glance deployment 14:31:35 +1 14:32:07 I don't want this taskflow thing to be a disruptor in our current work, so let me know if that's seeming to be the case 14:32:13 i am worried about building too long a dependency chain on incubating projects 14:32:23 if we decide to use it , it should be pluggable 14:32:37 re: heavy duty, I think we're going to be okay there as long as we're just using it to define the task scripts 14:32:43 not a required dependency 14:33:24 iccha: that makes sense to me for the engines, but not as much for the simpler case of script definition 14:33:51 if you're just doing step #1 above, its very lightweight in a deployment and dependency sense 14:33:57 ok gotcha.. i need to do more homework on taskflow 14:34:25 #link https://github.com/openstack/cinder/blob/master/cinder/volume/flows/create_volume/__init__.py 14:34:27 ^^ might help 14:34:36 okay, other thoughts on taskflow 14:34:47 again, I don't want this to be seen as moving the target for our current work 14:34:49 thanks markwash 14:35:09 so if it is, let's pull back and make sure taskflow isn't disrupting our plans 14:35:47 i think it's important to get import task done, then revisit taskflow 14:36:17 once we see an actual workflow in actino 14:37:00 rosmaita: hmm, okay. . but I think we should keep it in mind becuase it might actually make the import script coding part easier and faster to do from where we are now 14:37:28 at least when we start to look at doing the more complex parts (i.e. plugins for conversion / validation / etc) 14:38:02 but yeah, if we need to move ahead without taskflow and revisit it later in the cycle I'm fine with taht 14:38:07 markwash: actually rosmaita's message ask me remember my question 1 and 2 within http://lists.openstack.org/pipermail/openstack-dev/2013-October/016917.html 14:39:10 markwash: ... they are pending still after our last discussing.. humm 14:39:46 zhiyan1: yes, I'm not sure I'm ready to follow up on that. . I still feel generally that we should not allow plugins to define new task types 14:40:20 because it seems too diffusive, I want different deployments to feel the same 14:40:21 let's talk this off line... seems it need more time. 14:40:34 okay, moving on 14:40:54 #topic async workers 14:40:57 markwash: make a action between us? 14:41:09 I keep looking for stuff to review, but its always based on an outdated patch 14:41:13 am I just bad at finding the right review? 14:42:02 zhiyan1: I'm not sure exactly what I would put in the action item 14:42:11 markwash: I think you can start from https://review.openstack.org/#/c/43842/ and https://review.openstack.org/#/c/46224/ :) 14:43:02 flwang thanks! 14:43:42 any other quick things to note about async workers progress? I think we've mostly been blocked at the gate this week :-( 14:44:31 okay 14:45:06 #topic doc review 14:45:16 rosmaita is this your item? 14:45:24 I get a 404 on the link :-( 14:45:48 I think maybe the last number was clipped somehow 14:45:53 https://review.openstack.org/#/c/51704 14:46:08 sorry about that, chief! 14:46:09 good ol gate-noop 14:46:11 no worries 14:46:18 folks: have a look at that review, I will too 14:46:31 rosmaita: anything else to cover other than a shout out for review? 14:47:01 not from me 14:47:32 #topic tasks authorization layer 14:47:47 hmm, I think nikhil|afk suggested this? but is still afk 14:48:44 I think that is soemthing we can consider for glance as a whole, not necessarily just tasks 14:49:25 ah, okay 14:49:26 but I am not sure how that review comes into picture. 14:49:27 iirc iccha yesterday give some great response to explain why we need this layer ... 14:49:40 I thought so too 14:49:58 maybe nikhil|afk had something else in mind wrt review, I am not sure 14:50:06 let's table it for now 14:50:42 #topic open discussion 14:51:10 I finallly proposed a session about v1 14:51:24 please let me know if you think its a dud and I should let some other talk take the space 14:52:13 if some cross project talks come up we can consider, otherwise I think its ok because most ppl still use v1 14:53:02 markwash: after fast glance, IMO v1 is useful, since some function only be supported by v1 but v2.. 14:53:58 I agree till we have import and export we may wanna keep it around 14:53:58 i mean this topic is valuable probably, we can talk details on the session 14:54:04 zhiyan1: well a main thing I would like to stop doing is implementing new functionality both the right way (in a code library like the domain) and the wrong way (in the v1 controller) 14:54:09 +1 14:54:16 just makes v1 clunkier 14:54:26 if clunkier is a word :p 14:54:29 +1 14:54:33 freeze v1, +1 14:54:48 zhiyan1: yeah, freeze is a good option to consider, good point 14:55:01 +1 to avoid dup work anymore 14:55:37 btw, when the glance client will use v2 as the default? 14:56:21 hmm good question 14:56:36 oh I forgot to talk about glanceclient (which I of course neglected to release again :-() 14:56:44 iccha: btw "clunkier" ? 14:57:17 I think before we let other components using v2, we should eat the dog food by ourself :) 14:57:18 zhiyan1: http://www.thefreedictionary.com/clunkier 14:58:11 okay, time for me to get some breakfast 14:58:15 thanks folks 14:58:17 #endmeeting