14:03:09 #startmeeting image import sync 14:03:10 Meeting started Tue Oct 11 14:03:09 2016 UTC and is due to finish in 60 minutes. The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:03:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:03:14 The meeting name has been set to 'image_import_sync' 14:03:27 #link https://etherpad.openstack.org/p/glance-ocata-image-import-sync 14:04:23 ok, so we were going to refresh ourselves about taskflow 14:04:32 (which i personally did not have time to do) 14:05:09 So the base_imprt flow is good starting point 14:05:21 ok 14:05:41 due to it's architecture we cannot use it as is, but it's pretty good skeleton for what we want to do 14:06:02 sound optimistic 14:06:06 for the people following along: 14:06:10 #link http://git.openstack.org/cgit/openstack/glance/tree/glance/async/flows/base_import.py 14:07:01 i'm looking at all of flavio's notes about glance_store 14:07:26 that's making me think a design session on glance_store refactoring is a good idea for barcelona 14:07:29 I was just gonna say that most of the lines are Flavio ranting, but we just ignore that part for now ;) 14:07:39 ;) 14:07:40 * croelandt loves the "def revert(self): pass" 14:07:58 yea, flavio does not write boring code 14:08:25 rosmaita: that's very nice and polite of you :P 14:08:37 i try 14:09:49 so my plan for this week is to steal the bits from the base_import we can utilize and make api_image_import flow there 14:10:20 I see 14:10:27 what endpoints would that cover exactly? 14:10:31 and get the configuration option to use for the scratchpad ... hopefully I'll be able to import image from it to the back end store 14:10:44 croelandt: none 14:11:14 that would be just the taskflow to be used under the hood when the image import is done 14:11:34 with the new workflow 14:12:09 yeah 14:12:24 So the only issue with the inside-out approach is that I have no idea what we're trying to code 14:12:39 so we'll need: user -> scratchpad, (validation while in scratchpad), scratchpad -> backend 14:12:45 croelandt: so the execution of that taskflow would be triggered by the last call of the image import process 14:13:15 Jokke_ is talkind about scratchpad -> backend 14:13:21 ok 14:14:14 croelandt: it might be worth thinking about how the validation should happen 14:14:41 and that taskflow would be then pluggable to pull the image data either from the FS (code ready in the base_import) or swift (needs to be done) or external uri (already implemented in the base_import) and push it to the glance_store (already implemented in the base_import) 14:14:59 rosmaita: isn't that part of the spec? 14:15:20 croelandt: yes, but i think the spec says what more than how 14:17:06 so the swift stuff doesn't need to happen in the MVP 14:17:28 rosmaita: but the design needs to be able to facilitate it 14:17:32 rosmaita: can't see the word "scratchpad" in either the spec nor the current code :p 14:17:37 Jokke_: very true 14:17:42 croelandt: sorry, "staging area" 14:17:47 just like the external uri (that just happens to exist already) 14:17:49 (formerly, "the bikeshed") 14:17:52 oh right 14:18:07 not a native speaker, so I sometimes have trouble jumping between the terms :) 14:18:20 sorry, yeah, I'll keep using bikeshed again so we are on the same page ;) 14:18:20 croelandt: sorry about that 14:18:43 croelandt: in the first few drafts, we called it "the bikeshed" because we couldn't agree on what to call it 14:18:50 croelandt: same here, so I constantly use wrong ones. Sorry 14:19:22 rosmaita: actually we called it bikeshed from the very beginning as we _knew_ we wouldn't be able to agree what to call it :P 14:19:43 well, i think i got overruled on having PUT v2/bikeshed in the api 14:20:00 (that's why we call it the "staging area" -- PUT v2/stage) 14:20:02 unfortunately yes. Perhaps we should revive that 14:20:30 it woudl be good for openstack to have a bikeshedding api 14:20:36 would keep things more organized 14:23:28 so yes, when we get that taskflow working, we can then implement the staging and the import endpoints and we effectively have MVP ... then the swift part and the discovery and tons of testing/hardening 14:23:32 == profit 14:23:59 so, if Jokke_ is working on the bikeshed -> backend bit, is it too early for croelandt to start on the user -> bikeshed part? 14:24:49 I think that'd be fine if you croelandt want to take that on 14:25:10 croelandt: what parts interest you most? 14:25:12 not sure exactly where to start, but why not 14:25:44 croelandt: we can sync on that offline 14:25:49 rosmaita: I honestly do not really see where we are going, especially because of the inside/out methodology (which is definitely right one in terms of reviews, though) 14:26:15 I could give the user -> bikeshed a try 14:26:18 Jokke_: can you use help on the bikeshed -> backend part? 14:26:29 if Jokke_ does the bikeshed -> store part, then we have the full stack \o/ 14:26:51 yeah, we would basically have image upload re-implemented! 14:26:53 ok, I revisit my work plan that much that I try to make flowchart of the macro level 14:27:12 maybe that helps out to understand what we need there and what bits we are working 14:28:18 i think Jokke_ 's idea right now is that we start with the user's bits already in the bikeshed, and not worry about how they got there, and write the flow to get them into the backend 14:28:32 correct 14:28:40 so for collaboration, 14:28:56 yep 14:29:03 croelandt, you could either work on the same with Erno (if that would make sense) 14:29:19 or work on another part that already assumes the bits are in the bikeshed 14:29:28 (that woudl be the validation stuff) 14:29:37 so as long as I know the path to the image file on the local node I can just make the workflow, drop the image to that path, use the old _deprecated_ tasks api *sigh* to trigger the flow and see profit 14:29:39 not sure if it's too early for that, though 14:29:57 validation might be fun 14:30:04 (i meant about validation stuff, not Jokke_ 's workflow) 14:30:09 rosmaita: is there anything in particular you'd like to work on? 14:30:14 * abashmak pipes up 14:30:20 hello alex 14:30:30 I have bandwidth to help 14:30:46 there's actually good question about the validation 14:30:50 croelandt: i want to work on the discovery part, i need to revise the schema 14:31:13 do we want that just being tasks on the import flow or separate taskflow that then triggers the import flow 14:31:41 Jokke_: not sure i understand your question 14:32:10 abashmak: have you had a chance to work with taskflow yet? 14:32:27 sadly no 14:32:33 that's ok 14:32:59 my suggestion would be to look at taskflow and the stuff in the glance/async directory to see how it's being used 14:32:59 rosmaita: oh I have a patch for that 14:33:09 croelandt: yes, i know 14:33:38 croelandt: i don't want to take over your patch, but i need to revise the spec to make sure we've captured all the stuff that came up in the defcore discussions 14:33:46 rosmaita: feel free to ping me about that 14:34:24 croelandt: i do have a question about whether our current json-schema code will be able to handle the proposed schema 14:34:26 sorry, had to dial in to the next meeting 14:34:33 Jokke_: ok 14:34:48 so as the validation is precondition to the import 14:36:09 we have two options 1) we have validation taskflow that gets triggered by the api call and when it finishes it triggers the import taskflow or 2) the validation is bunch of tasks as part of the import taskflow and will be one integrated taskflow triggered by the api call 14:37:20 the key thing is that we'll want operators to be able to insert custom validation code 14:37:37 i'm not sure if either of those is more conducive to that? 14:37:52 yes and that's why I'd prefer having separate taskflow for it 14:37:53 maybe (1) is because the validation part is more isolated? 14:38:09 ok, so we are thinking the same thing 14:38:16 it would keep the import code away from the people who want to implement their own validations 14:38:54 yeah, that would be good 14:39:27 so basically we could document "Write taskflow, set it to config being the used validation flow, make sure it calls api_image_import flow when it's finished 14:39:41 i like that 14:40:01 it keeps the database interaction stuff away from the operators 14:40:24 we handle all the stuff that modifies the image record 14:40:38 * croelandt has a headache now 14:40:42 we are way over time 14:40:52 no worries 14:40:52 another possibility is for the custom code to plug into a wrapper, that way it doesn't have to call the api_image_import flow, the wrapper would do that 14:41:06 croelandt: I'll do the flowchart and walk you through it 14:41:33 abashmak: that's a good idea, the less we leave to operators, the more friendly the import will be 14:42:34 abashmak: fell free to look into how to do that wrapper with the glance async/ taskflow code :P 14:42:36 ok 14:42:41 might be nice to sum this up in the etherpad 14:45:10 ok, got some notes in the etherpad 14:46:01 ok what's next? 14:46:13 i guess we have enough for a week? 14:46:36 yeah, maybe more 14:47:25 ok, let's plan to meet again next week 14:47:46 and we can find each other here if we need to 14:48:03 thanks, and sorry about this going way over 20 min 14:48:11 #endmeeting image import sync