14:01:16 #startmeeting glance_artifacts_sub_team 14:01:17 Meeting started Mon Sep 21 14:01:16 2015 UTC and is due to finish in 60 minutes. The chair is nikhil. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:21 The meeting name has been set to 'glance_artifacts_sub_team' 14:01:23 hey 14:01:27 o/ 14:01:33 o/ 14:01:34 hi 14:01:42 #topic agenda 14:01:45 Alex it on another meeting so he's not available 14:01:47 there's no set agenda for today 14:01:52 ah ok, np 14:02:05 do we have any discussion items or should we have open discussion? 14:02:17 let me remind you about our bugs :) 14:02:29 ah yes 14:02:37 I think I should be able to block RC1 on that 14:02:42 if not we can request a RC2 14:02:44 Murano really needs these fixes and Alex is worrying 14:02:49 ok 14:02:51 o/ 14:02:55 I will review them today 14:02:56 thanks :) 14:03:07 cool! 14:03:20 couple of words about future work 14:03:36 #action nikhil to send reminder for RC1 bugs to cores 14:03:55 Alex started to write an article about his vision of artifacts in v3 14:04:15 awesome, ready for a preview yet? 14:04:21 we have been discussing it all week 14:04:37 I don't know about a preview :) 14:04:52 he just asked me to tell it to you 14:05:03 but there are many open questions 14:05:16 I see, something I need to discuss with him then 14:05:33 ok, any important ones you can share for now? 14:05:52 no, nothing special 14:06:19 I made a picture of our database model 14:06:31 nikhil, if would perfect if you take a look on Artifacts API spec 14:07:04 yes, I forgot to mention it - Kairat update the spec 14:07:10 *updated 14:07:11 https://review.openstack.org/#/c/177397/ 14:07:23 surely! I will follow up on the udpates! 14:07:41 I think we should move it in Mitaka folder when it's open 14:07:50 I'l read it Kairat :) 14:08:03 it was done already, I moved it 14:08:08 mfedosin you can propose a open mitaka review and then add this move as dependency 14:08:21 oh right, we opened it eariler 14:08:39 I am still on liberty land 14:08:46 some specs need updating for rel and notes 14:08:54 so a bit distracted from mitaka atm 14:09:01 jeez... I'm behind the times. 14:09:20 anyways, I think we did that to start preapproved specs discussion 14:09:29 so It definitely worth to review it then 14:09:37 and it would be nice to get Artifacts API into it if at all possible 14:10:50 It's better to discuss it with Alex, but I have one concern about proposed implementation 14:11:03 about API exactly 14:11:23 looks like a good update 14:11:33 the problem is there will be many apis 14:11:39 I think I may have some comments on the performance impact section to start with 14:11:56 mfedosin what do you mean? 14:12:02 +1 14:12:12 cannot get the question 14:12:15 each plugin can implement its own api 14:12:17 many different types of proposals or many API for a single operation? 14:12:24 I see 14:12:36 you mean db api? 14:12:38 yes, that is a big worry 14:12:41 implement and reimplement 14:12:49 no, actually just api 14:12:59 he means server API 14:13:09 of course there will be CRUD and listing 14:13:32 but the whole logic may be contained in a plugin 14:15:43 just an example with images as artifacts 14:16:10 we have two plugins: images_v1 and images_v2 14:16:33 and you want to show some image meta 14:17:31 if you use v1 you will have response in headers but in v2 as json 14:18:21 so I think it should be discussed more precisely 14:19:18 mfedosin, we have artifact_type versions to cover that case, do we? 14:19:31 yes, exactly 14:19:46 so that's the problem here then 14:20:09 it's not a problem technically 14:20:26 it's the thing we must describe very detailed 14:20:51 that big part of the logic is contained in plugin 14:21:10 yes 14:21:23 and the whole response and behaviour may depend of what plugin you use 14:21:24 it is possible to write it as a plugin 14:21:35 I am just thinking what is more maintainable 14:21:52 yeah, that too 14:22:41 So, we have to focus on this in our spec. 14:23:20 also, one question... 14:23:52 is there some possibility that v3 will be used by default? :) 14:24:11 for? 14:24:22 mfedosin, don't think it will be soon 14:24:27 Nova I think 14:24:38 so, images v2 is being planned as a the DefCore images API 14:25:07 that means all clouds that need the brand OpenStack must pass Images tests against v2 standards 14:25:12 and it's a good question - if we can make v3 images almost compatible with v2... 14:25:19 now we can think of v2 on top of v3 14:25:30 yeah, if we can do that 14:25:48 then basically we have v2/v3 as default for images (v2 on top of v3) 14:25:59 because I have some thoughts how to do that 14:26:07 and for all other data assets v3 14:26:20 sure, that's a good discussion to ahve 14:26:39 I think we should start that next week onwards after RCs are done 14:27:49 btw, do we have some artifacts dedicated meetings on the summit? 14:28:05 not yet 14:28:23 I suppose we should have one :) 14:28:24 we have 3 fishbowl, 5 workroom and 1 full day meetup 14:28:27 or even two 14:28:49 awesome! it's enough for everything 14:28:57 so, we can have 1 half of meetup for artifacts and start with 1 workroom proposal 14:29:33 we need discuss two things actually 14:29:37 let's see of more things come up or not 14:29:42 sure? 14:29:46 1. Architecture of v3 14:30:08 you mean design of v3 API right? 14:30:09 2. Шnteraction of images in v2 and v3 14:30:13 yes 14:30:16 yes 14:30:20 absolutely 14:30:26 awesome 14:30:31 we are out of time for today 14:30:37 okay, we are out of time 14:30:40 thanks! 14:30:41 let's focus on RC bugs for now 14:30:47 thanks all for joining! 14:30:51 #endmeeting