14:00:21 #startmeeting glance 14:00:21 Meeting started Thu Sep 24 14:00:21 2015 UTC and is due to finish in 60 minutes. The chair is nikhil. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:24 o/ 14:00:25 The meeting name has been set to 'glance' 14:00:27 o/ 14:00:29 o/ 14:00:30 #topic agenda 14:00:30 o/ 14:00:31 o/ 14:00:32 o/ 14:00:34 o/ 14:00:35 o/ 14:00:37 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:01:24 o/ 14:01:27 o/ 14:01:30 o/ 14:01:33 o/ 14:01:54 o/ 14:01:57 Welcome everyone 14:02:23 We have a short agenda today but this meeting is important at the advent of Mitaka planning 14:02:37 So, let's discuss some of those items towards the end of the meeting 14:02:47 and thanks for flaper87 for already putting Nova items on the list 14:02:54 Let's get startec 14:03:02 #topic updates 14:03:13 #info artifacts updates 14:03:13 o/ 14:03:28 so, we've got all the blockers merged as fast-track patches 14:03:39 thanks to all who helped reviewing them 14:03:40 that's cool 14:04:01 #link https://etherpad.openstack.org/p/fastTrackPatches 14:04:09 Murano project, as our first (hopefully not the last) adopter has confirmed artifacts are working properly for them 14:04:49 :) 14:04:51 The feature is enabled as experimental (for obvious reasons) in Murano-Liberty, all are loking forward for our API to be stable in M 14:04:59 ++ 14:05:20 Mitaka is going to be API centric! 14:05:32 ativelkov: \o ltns ... good to hear that it actually works ofr them :) 14:05:36 we're still waiting for you article Alex ;) 14:05:41 your 14:05:41 Right now I am documenting artifact-related changes for Murano. When finished, will start working on the big "About-v3" article for openstack Wiki 14:06:15 ativelkov: ++ on documentation 14:06:22 So, I think we need to discuss some of the use cases that API v2 does not solve and put a Artifacts perspective into the domain 14:06:35 ativelkov: it'd be great to go slow about the V3 article 14:06:49 as in, I'd like us to be very careful on not creating more confusion around glance 14:06:59 There are some compelling use cases for the same however, the tradeoffs exist and having those out there would help 14:07:33 flaper87: the idea behind the article is to get some community awareness before the talk at the summit 14:07:43 what talk ? 14:07:46 :P 14:08:03 one thing that everyone seems to be disjoint on is the reason for existence of certain features, so idea behind Artifacts would be great to have documented and get inputs from interested developers, operators, etc. 14:08:07 Let me put my concern in other words: We're trying to solve a huge confusion and mess with v2 right now 14:08:29 That's mostly true 14:08:30 I'd like us to be careful on how we sell (or if we should at all do that in this phase) the artifacts work 14:09:02 I'm not saying to ignore it and to not write things down. I'm just saying lets be careful with the wording. I'm happy to provide feedback on the article 14:09:03 we have an approved talk on the main summit conference on the evolution of Glance APIs 14:09:03 We are trying to solve the problem os interoperability around a ecosystem development around OpenStack "Images" 14:09:32 "we" stands for nikhil and me :) 14:09:54 yes, I think the rest of the community is going to be somewhat upset if the emphasis for this summit is about a new API when the existing one is not seen as finished 14:09:58 And we are targeting our v2 Images API for that standard given it works out for all the critical use cases 14:10:04 nikhil: sure, and the confusion on whether you need tasks to create images or not. Interoperability is just the technical side of it 14:10:25 flaper87: sure, the wording should be very careful. The idea is to explain things, not to make them more confusing :) 14:10:34 ativelkov ++ 14:10:48 ativelkov ++ 14:10:54 I'm just asking for us to be more careful on that side, especially because we're talking about an experimenting API 14:11:03 I'm not saying it shouldn't be written down. 14:11:06 that's all 14:11:08 yes, but it's been in the works for 3 cycles 14:11:12 ativelkov: I would resist the urge to make schedule predictions, for example 14:11:33 dhellmann: noted 14:11:52 rosmaita: yes, many folks outside of the project think it is a distraction from finishing the image API work. I don't know if that's true, I'm reporting the perception. 14:11:56 Schedule predictions seem tentative anyways. It about use cases and addressing them right for a long term support, dhellmann 14:12:02 rosmaita: again, "in the works" != stable or productoin ready 14:12:29 and that being the reason for this talk 14:12:40 nikhil: sure, but if someone leaves that talk with the impression that there is yet another API coming "soon" that will further damage the image of the project as being unable to complete its commitments 14:12:56 If we do not explain things, we may be asked the questions of different kinds, i.e. why the artifacts are not part of v2 if it isgoing to be included in DerCore. That's why we need all that explanations in some centralized place 14:13:09 so, congratulations on getting the talk, and I hope it goes well, but consider the broader impact as you write it 14:13:34 ativelkov: yep, that's a good point to cover 14:13:34 dhellmann: ++ that's what I was trying to pass as a message. Thanks! 14:13:40 yeah, and the reason for the talk is to reduce that confusion 14:13:59 get the use cases correct and everyone on the same page 14:14:05 Also, the talk is not just aoput the v3: it is exactly about the evolution of Glance API: from V1 to v@ and then eventually to v3 14:14:19 v2* :) 14:14:23 not distract people into thinking incorrectly 14:14:51 ativelkov yeah, thanks for that explicit clarification. seemed important and missed 14:15:06 ativelkov: I'd love to provide feedback on the article, if you don't mind. 14:15:14 flaper87: sure! 14:15:30 ativelkov: thanks! 14:16:33 #info drivers meetings updates 14:17:15 The ova lite feature was not able to get merge in Liberty and the dev team has been notified to target it for M 14:18:01 We had a discussion around the concept of "Image", v2 APIs and the confusion 14:18:27 If you have feedback, this etherpad is where the collab is happening 14:18:27 https://etherpad.openstack.org/p/glance-upload-mechanism-reloaded 14:18:41 hopefully they don't give up and wake again at the end of the M cycle ... I think it's really close, we just ran out of time 14:19:05 I'd also like to mention that we're planning to have a quick video call on Tuesday at 15 UTC. Everyone interested is invited! 14:19:16 please, ping me and I'll provide details 14:19:20 malini wants it in early M and we should give them early feedback as a courtesy 14:19:30 flaper87: I'd like to be on that call 14:19:36 I had pushed for it (think) in L2 14:19:38 dhellmann: you got it! 14:20:35 and the feedback had started coming in early Sept so just as a courtesy -- I would like one of the first feedback on this spec (besides other things of course) 14:20:54 flaper87: was really nice of you to pick time outside of your options that suites really badly :P 14:21:19 yeah, thanks for considering the round globe 14:21:42 Anything that helps making Glance better and finding a solution for this issue :) 14:21:53 ++ 14:22:17 #topic Was there a reason checksum and size were left out of v2 server? (bunting) 14:22:41 bunting can you please elaborate on the issue? 14:22:41 Yeah, i noticed this whilst working on osc and was wondering why this changed? 14:23:01 For example checksum was in my opinion a useful feature 14:23:07 For data integrity 14:23:17 wait, checksum on the image exists 14:23:20 it's a base prop 14:23:32 but not exposed in the compute api 14:23:32 yes the checksum gets calculated 14:23:34 (immutable one for that matter) 14:23:42 i think bunting is talking about nova api 14:23:47 oh 14:23:52 i think? 14:24:05 bunting ? 14:24:12 I mean when you create a image you can't supply a checksum to have the image deleted if its diffrent 14:24:24 bunting: are you using the nova proxy to glance, or talking to glance directly? 14:24:27 It seems this functallity is gone 14:24:41 glance directly 14:24:45 user level validation 14:24:55 afaik nova does not support v2 14:25:10 jokke_: see the next topic for this meeting 14:25:12 ;P 14:25:16 jokes apart 14:25:18 bunting: could you please explain your use case? 14:25:18 nikhil: Oh so its moved so the user manually checks it now? 14:25:29 bunting: so you're saying you used to be able to upload an image with a given name and if there was already an image with that name but a different checksum then the old image would be removed and replaced? 14:26:05 So if you do glance image-create --checsum hash - if it does not meat hash the image would automatically be deleted 14:26:09 dhellmann: no, if thew checksum provided with image create didn't match the checksum calculated in the server the image used to be killed 14:26:13 I think bunting is saying that it was possible to upload the image + checksum in v1 and it'd check whether the uploaded checksum was the same as the uploaded image's 14:26:18 jokke_: ah 14:26:32 flaper87: Yeah 14:26:47 ok, thanks for clarifying -- I'm still learning about the glance features :-) 14:27:03 on v2 it changed that we don't take checksum as input but we just calculate the checksum in the server, if the returned checksum does not match what the user has it's user's discreet to decide what happens next 14:27:04 bunting what is the response while uploading w/ checksum? 14:27:19 jokke_ correct 14:27:21 that sounds like a python-glanceclient feature 14:27:41 I'm a bit worried on the return response 14:27:51 as it's not disallowed afaict 14:27:53 I think that's useful too and, tbh. 14:28:04 nikhil: iirc it's forbidden 14:28:15 flaper87: Yeah to me it sounds like a useful feature 14:28:24 to have it automatically killed 14:28:27 Leaving that to glanceclient means that you have to create the image, upload the whole thing, check if the checksum is the same that you had, and then delete the image if it doesn't match 14:28:32 valueated from same list as you would try to specify owner manually 14:28:45 bunting: that sounds a little bit like what is currently available with signature verification 14:28:50 https://github.com/openstack/glance/blob/master/glance/api/v2/images.py#L375 14:28:51 it seems a bit of a waste considering that we already calculate the checksum on the server. 14:28:53 jokke_ ^ 14:29:00 you can provide a signature of your checksum, and it will be killed if the signature doesn't validate 14:29:18 Ah so its now moved to signature? 14:29:29 bpoulos: right! 14:29:30 i think you could use the signature for what you're wanting 14:29:40 it's not actually moved 14:30:03 it just accidentally happens to be there too 14:30:04 rather a more advanced way of image validation exists 14:30:05 :P 14:30:24 nikhil: Okay 14:30:45 For jury reading the logs, please forget anything said on this topic to avoid confusion around the API :P 14:30:54 clarifying question: the current behavior is to pass in signature ahead of upload, correct? 14:31:01 correct 14:31:03 yep 14:31:08 if you pass it after, it doesn't validate 14:31:08 therefore, we can use this for immutability and retries 14:31:19 jcook correct 14:31:22 yup 14:31:32 if you upload, it fails, you upload again and sig doesn't match original sig, fail 14:31:39 I think we are trying to narrow down on the immutability clause on just "active" 14:31:43 but it requires to have signature configured and everythin 14:31:45 perfect, I'll update the upload retry spec 14:31:48 jcook: nope ... you cannot reupload on killed image ;P 14:32:00 however, we first need to contain the race conditions to avoid major bugs 14:32:03 jokke_: https://review.openstack.org/#/c/206250/ 14:32:10 jokke_ ^ 14:32:11 jokke_: not yet :) 14:32:36 jcook I think we sort of need a set_and_test on that retry thing 14:33:11 as in upload and verify it is right thing? 14:33:20 better journaling (in other words) 14:33:46 keep the upload, deletes (cleanup), verification non-racy 14:33:49 I was thinking send signature first attempt, retry as much as you want (to inifinity and beyond), it won't succeed until original sig matches and you cannot change sig 14:34:18 so your upload could succeed, but it would fail because the original sig you sent in very first attempt did not match 14:34:28 the sig is the immutable bit, and it won't go active until sig matches 14:34:33 at that point a retry is a NOP not a fail 14:34:44 sig already matches, don't bother doing anything 14:35:29 sounds good, we can discuss impl details on this later on the spec. 14:36:03 I guess the validation point that jcook and bunting want (for different reasons) is covered here? 14:36:20 +1 14:36:24 nikhil: covered for me 14:36:33 thanks! 14:36:54 moving on. (For now) 14:37:01 #topic Nova migration from Glance v1 -> v2 (flaper87) 14:37:12 o/ 14:37:14 oh yeah 14:37:27 I don't have much to say other than give some updates on the current status and plan: 14:37:37 this sounds like familiar topic ... have I heard about this before? 14:37:46 I've been talking with some folks trying to identify who can work on this and help moving this effort forward 14:38:15 mfedosin: has volunteered to help with code from the Glance team, whereas sudipto from nova, has raised his hand to help with code as well 14:38:21 This is great! 14:38:24 Thanks to both 14:38:24 yup 14:38:28 On the other hand 14:38:35 great! 14:38:41 I'll be helping with the spec and I'll be working with jaypipes on it 14:38:50 so, my goal for next month is to test Flavio's patch, split it in several small patches and help in reviewing the spec 14:39:03 flaper87: I'd like to get pause here 14:39:32 I think it's extremely important to get the API mess with defcore ironed out before we move forward with Nova 14:39:53 the nova work is blocking defcore, too 14:40:03 I think the image create and nova work can happen in parallel 14:40:05 jcook ^ 14:40:14 Last thing I want to see is that we get Nova migrated to current state and with defcore decide to bring up some new standard upload process 14:40:22 * jcook reading back 14:40:41 dhellmann: work itself yes, but I think the main principles needs to be agreed first 14:41:09 ah the upgrade to v2 or glance seam in nova spec stuff 14:41:11 jokke_: what parts of glance's v2 api that nova is consuming do you expect to change? 14:42:34 So, one very important thing 14:42:42 I'm worried that, given the amount of time it tends to take to get work like this done in nova, if it is not started soon it will not be finished this cycle 14:42:50 dhellmann: iiuc the biggest questionmark currently is how the images will be brought into glance in future. Is it the images API upload as it stands now, do we need to change that or bring something new at the side to provide the needed or will it go via some task interface 14:42:53 we should get a new spec in Nova approved possibly prior to summit 14:42:56 sorry, got distracted. Here now. 14:42:59 so 14:43:01 https://review.openstack.org/#/c/194303/ 14:43:01 Back to the spec 14:43:26 As I mentioned before, I'm working on the spec now 14:43:27 that's my spec on the matter, and I think I spent all my wind on it there ^ I'll try to update the spec today 14:43:29 jokke_: so start the nova work with the parts of the API not related to image upload 14:43:33 and I'll have something ready for review soon 14:43:48 I'll work with jaypipes and obviously, it'll need feedback from everyone 14:44:08 dhellmann I am not worried about that as I have been discussing with Nova how to adjust that in one cycle. there are many efforts around images in nova and it would be good to get this one bit done asap 14:44:53 flaper87 thank you. One thing Nova folks wanted is to get first and early feedback from GLance community 14:45:27 we should avoid what happened in Liberty 14:45:30 Yes! I think we should do that asap, which is why I've been working on the spec today 14:45:48 I hope to have something ready soon for review by y'all 14:46:08 Also, one thing I have as input is that people interested in images stuff in Nova, please attend their meeting and help with this inter-project communication work 14:46:31 the meetings can be at odd hours due to TZ adjustments 14:46:46 that'd be useful too. I can't commit to that as the nova meetings seem to happen in weird TZs for me but we can figure that out 14:47:01 I'll be syncing back from/to nova 14:47:08 so, expect updates from me on this side 14:47:13 help from around the world will be appreciated, but then again it would be best to have one or two dedicated images liaisons for M. 14:47:24 flaper87 sounds good! 14:48:00 with a little over 12 mins, do we have anything more on this topic? 14:48:02 I think we have enough people to get this going. More are totally welcome but with this small sub-group, we should be ok to move this forward 14:48:06 * flaper87 stfu 14:48:17 ++ 14:48:37 #topic winding up Liberty RCs 14:48:39 nikhil: I bet that's re "Stfu" 14:48:41 :P 14:48:50 #info RC1 coming, https://review.openstack.org/#/c/223633/ example config files ( jokke_ ) 14:48:57 flaper87 lol, no :P 14:49:29 Is that the only thing blocking RC1 ? 14:49:37 I'll get to it right after the meeting 14:49:42 bit hand to sabari who took time yesterday to review the change and spotted some inconsistencies ... should be all good now 14:49:50 * flaper87 hopes it is 14:49:53 jokke_: ++ 14:50:01 sabari ++ 14:50:35 jokke_: does glance use the config sample generator from oslo.config? 14:50:47 I was hoping this one gets a pass of testing https://review.openstack.org/#/c/221307/ 14:50:52 dhellmann: it's not automated 14:50:53 dhellmann: yes 14:50:58 but not automated 14:51:18 dhellmann: those are pulled from it and some adjustments done so we got all the sections in we need 14:51:43 jokke_: ok, maybe we can discuss what adjustments were needed offline so we can make this easier for you in the future 14:52:21 dhellmann: sounds good ... this is actually the major move to the autogenerated configs ... next round should be lots easier 14:52:28 k 14:52:46 I think we need more awareness around adding configs in general 14:53:04 (plus review) 14:53:42 nikhil: do we have anything else we're waiting for RC1? 14:53:48 #info if RC1 goes out this week, I have asked for a possible RC2 next week 14:54:25 jokke_ no blockers, but good to get this in RC1 for some thorough testing https://review.openstack.org/#/c/221307/ 14:54:48 RC1 most likely will be cut right after the config refresh 14:55:12 Are we going to make proposed/liberty branch with the release of RC1? 14:55:13 ok, so please folks lets get the reviews going ... it's beast 14:55:54 dhellmann is our rel-mgmt expert :) please educate us on the timeline for proposed/liberty branch 14:55:57 ativelkov: it's gonna be stable/liberty treated like proposed/ until final release iiuc 14:56:11 dhellmann: can correct me if I'm wrong 14:56:59 yes, that's right, we'll create the stable/liberty branch with special acls that lock it down tightly until the release is finished, and then change the acls so it acts like a normal stable branch 14:57:03 we can continue this in open discussion, just to give some time for last minute awareness topics 14:57:05 oops 14:57:24 #topic open discussion 14:57:57 I wanted to put this out there for more awareness -- https://review.openstack.org/#/c/206431/ 14:58:07 I am happy to work on osc, bty following our disscussion about it last week 14:58:16 I don't recall if we have an etherpad to collect topics for Mitaka already 14:58:32 just to help educate Nova team if that's the best way of going about it 14:58:40 If we don't, it'd be great to create one. If we do, please, remember to add things there! 14:58:42 :D 14:58:49 I seem to recall there being one 14:59:00 nikhil: I really liked what they are planning there and it indeed makes way more sense to do in Nova than in Glance 14:59:36 jokke_ agreed 15:00:42 I am trying to find that etherpad, will link if offline if exists 15:00:48 But we are out of time now 15:00:54 THanks all for joining! 15:00:57 #endmeeting