20:00:16 #startmeeting glance 20:00:17 Meeting started Thu Feb 6 20:00:16 2014 UTC and is due to finish in 60 minutes. The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:20 The meeting name has been set to 'glance' 20:00:24 roll call! 20:00:24 hi 20:00:28 o/ 20:00:35 o/ 20:01:08 o/ 20:01:21 pehw 20:01:29 o/ 20:01:32 s/eh/he/ 20:01:39 \o 20:01:52 looks like we have some artifact folks today? 20:01:55 huzzah 20:02:02 agenda is here 20:02:16 We are here, yeah. At least I am 20:02:19 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 20:02:44 I made a pass through all the i3 stuff we care most about and added notes 20:02:51 so we'll see how far we can get through that 20:03:02 but first I think we had some carryover discussion about glance.store 20:03:05 #topic glance.store 20:04:29 TBH I'm not sure what discussion exactly is needed at this point 20:04:39 and flaper87 is . . not(?) here 20:04:46 I saw a change 20:04:51 where is is moving the scrubber 20:05:03 indeed, i think that has merged at this point 20:05:03 not sure if it has been merged yet 20:05:08 ok 20:05:32 the point that I would like to discuss is the timeline 20:05:36 for the change 20:05:48 my questions about glance.stores are mostly process-oriented. . how do we set up the repo, and what coordination is needed with other folks / infra etc 20:06:02 arnaud__: are you seeing it as more of an early juno thing? 20:06:20 yes 20:06:36 I could see that 20:06:41 but flaper87 had another point of view 20:06:42 :) 20:06:45 ah 20:06:55 we can discuss later since he is not here 20:07:07 markwash: I don't think it can complete in Icehouse 20:07:24 yes, I think perhaps we should do that, arnaud__ can you try to pin flaper87 down to a time to discuss in #openstack-glance ? 20:07:33 sometime soon I hope 20:07:33 ok sure 20:08:08 all right, let's hear his point of view a bit later then, and move on for now 20:08:20 #topic artifacts api 20:08:49 This week I had a f2f meeting with some mirantis folks about how we will move forward with team integration / coordination with the artifacts api 20:09:06 I've also been speaking with jbernard about the instance template, which is related 20:09:33 We had a few takeaway items from the f2f meeting that I wanted to share here 20:09:58 1) we're going to try to just integrate the artifacts work into the normal glance team rather than having separate teams 20:10:12 markwash: cool 20:10:31 which will probably mean bringing on more devs to the meeting and core members etc 20:10:50 and for a good while there will probably be a bit of an expertise gap as the two silos are joined 20:10:52 markwash: nice 20:11:14 but I think we can evolve past that, especially as we figure out how to integrate images into the artifacts work 20:11:27 from what ive read so far, the artifact design should accomodate instance-templates nicely 20:11:40 2) we'll discuss the progress of the artifacts stuff from folks who are working on it in the weekly meeting 20:11:59 Yes, we just don't need to hurry with this: better have slow progress then to break something 20:12:07 as a status checkin and as an opportunity to ask questions 20:12:24 I put some links to the design work and initial blueprint in the agenda 20:12:32 #link https://blueprints.launchpad.net/glance/+spec/metadata-artifact-repository 20:12:41 #link https://etherpad.openstack.org/p/MetadataRepository-ArtifactRepositoryAPI 20:12:49 #link https://etherpad.openstack.org/p/MetadataRepository-API 20:13:34 I think the theory was that tims, a heat guy, would be proposing some code around the api soonish that we could at least look at / keep WIP for a while 20:13:55 but I've not seen anything yet, is anyone in a position to contact tims to check on his status? 20:14:06 * flaper87 is back 20:14:11 sorry I'm late guys 20:14:19 better late than never 20:14:34 okay maybe I'll try to follow up with tims to see what's going on 20:14:54 #action markwash track down tims and get status 20:14:59 I may ask gokrokve to contant tims 20:15:19 ativelkov: good idea 20:15:45 jbernard: any status for us on the instance templates stuff? what's your initial angle of attack? 20:15:51 ok, as soon as he appears around, I'll tell him 20:16:22 markwash: the artifact design should be perfect 20:16:25 okay cool 20:16:37 markwash: the type would be 'instance' or something like this 20:16:56 markwash: and the associated metadata would contain the block device mapping 20:16:57 markwash: some parts are still not very clear to me. Espcially, the upload/download and the metadata part. 20:17:48 jbernard: great to hear 20:17:58 let's say, you want to download an artifact, what happens? what do you get? 20:18:00 jbernard: so are you sort of blocked/waiting on more progress with artifacts stuff? 20:18:30 markwash: i was going to raise that here actually 20:18:35 Hi guys, My name is Arvind and I work as OpenStack PM @ VMware. joining the glance IRC for first time. Look forward to learn more about artifacts and other blueprints. 20:18:46 soniarvind: hi good to have you 20:19:14 arnaud__: (not ignoring you, I will come back to your point in one sec) 20:19:28 :) cool thks markwash :) 20:19:38 ativelkov: you published the artifact blueprint/etherpads? 20:19:57 jbernard: not yet, working on that now 20:20:22 jbernard: so the issue right now is, without artifact api structure, there's not really a place for you to code /design stuff, right? 20:20:38 or are you raising some other issue? 20:20:51 yeah, we need a consensus on direction 20:20:59 at least, that's my current take 20:21:05 okay makes sense 20:21:24 the artifact direction is a good one IMO 20:21:25 jbernard: do you think it would make sense to come up with the list of attributes you would expect the instance template to have? 20:21:44 yes 20:22:09 ativelkov: maybe we can sync up when you're at a stopping point in your design 20:22:11 I suggest that because it seems it *might* help drive /verify some of the artifact discussion 20:22:41 for example, it would be neat if we figure out the set of acceptable answers to arnaud's download/upload question for instances 20:22:56 jbernard: sure. I'll write to the ML as soon as we are ready 20:23:05 yeah i agree, arnaud__ raises some good questions 20:23:58 ok, based on what I see so far, there is enough to agree on a basic design 20:23:59 okay, it seems like jbernard you have a little bit of a way to move in terms of defining what an instance template would need to include, so let's take a quick look at arnaud's question in more detail, and then see in what form we need to follow up after the meeting 20:24:04 arnaud__: that is a good question ... i think we should follow how it's done with images, /v2/artifact/uuid would give you metadata record, /v2/artifact/uuid/file would give you the data (i.e., the actual artifact) 20:24:10 when ativelkov pushes to the list, then we can hammer out the details 20:24:37 rosmaita: that's a valid approach but I'd love to let the folks driving the artifact api make their suggestion as part of a general proposal 20:24:51 markwash: +1 20:25:15 mostly wanting to avoid committee design, preferring instead committee review 20:25:20 ativelkov: I will let you know my concerns with more details, this way you keep that in mind 20:25:38 while designing :) 20:25:48 ok, sure 20:25:58 arnaud__: so specifically, it seems like you are concerned about what the path is for a consuming service to get an artifact for use 20:26:08 ativelkov: i will send you what an instance template would need to include 20:26:11 yes 20:26:20 so I think the we can take that as a request for specific info in any design info 20:26:26 ugh 20:26:31 any design info -> any design doc 20:27:17 ativelkov: are you doing the initial design? or is it still a question we need to answer after tracking down tims ? 20:27:48 I would prefer to sync up with tims, yes 20:28:12 okay great 20:28:20 so, to summarize 20:28:58 #action ativelkov markwash track down tims somehow and get status, answer the quesiton who is designing this thing 20:29:18 #action jbernard look into instance template requirements and make any thoughts available to artifact api workers 20:29:21 okay 20:29:31 sounds good 20:29:38 anything else on this topic before we jump into blueprint hell ? :-) 20:29:56 not from my side :) 20:29:56 * markwash opens nether portal 20:30:09 #topic I-3 blueprints 20:30:21 First one: image-recover (flwang) 20:30:33 aren't you glad your baby woke you up for this? :-) 20:30:47 #link https://blueprints.launchpad.net/glance/+spec/image-recover 20:30:51 yep, since I don't want to miss this one 20:30:55 there is a changeset 20:31:03 #link https://review.openstack.org/61680 20:31:05 but its abandoned 20:31:05 I will submit a patch soon to restore 20:31:15 I have a few questions 20:31:17 it will depends on zhiyan's location status patch 20:31:19 sure 20:31:29 1) how does a user find out an image/ image location is pending delete ? 20:31:36 because I thought we didn't want to expose that to users at all 20:31:52 flwang: may i know what's kind of dependencies there? 20:32:28 2) should this be admin-only? how do we make it admin-only? will it be a burden if it is admin-only but still shows up in the api docs as a valid path for users? 20:32:29 markwash: I'd like to let the admin can list the images which are in 'pending-delete' status 20:32:57 zhiyan: recover the location from 'pending-delete' to 'active' as well 20:33:06 markwash: 2) yes 20:33:39 flwang: can we do it in a way where it does not affect the user-facing api then? 20:33:53 flwang: IMO even we have no location status, we can also do pending-delete => active, no? 20:33:56 2) if the user is not admin, he will run into NotFound error IIRC 20:33:58 I'm probably just being a bit stodgy, but I'm very hesitant to change the api for this without more operations folks breaking down my door for this feature 20:34:34 zhiyan: yes, but it will be ugly and more work 20:35:20 flwang: I seem to recall an ML discussion around this, am I correct? 20:35:26 flwang: are you also working on the glance-client part? 20:35:32 *this feature 20:35:34 markwash: I'm going to add a new api like images/xxx/recover 20:36:18 markwash: nope? but I'd like to send it if it's necessary :) 20:36:34 the api design for this feature doesn't feel right to me 20:36:53 I can't really make a clear argument as to why, however 20:36:56 flwang: i'm a little confused tbh, seems you are trying to do location-recover but image-recover, am i right? i think they are different 20:37:15 zhiyan: +1 20:37:15 zhiyan: nope 20:37:16 I guess it seems like image-recover should be separate from the user api completely 20:37:42 flwang: since if you doing latter one, maybe* we need a api to list "pending-delete" location instead of image .. 20:37:53 flwang: yeah, an ML discussion, especially if you could include openstack-operators would be nice 20:37:55 zhiyan: when the image is in 'pending-delete', what's the status of location? 20:38:05 deleted, currently 20:38:24 I'm tempted to suggest we move this one to J just becuase I"m not yet comfortable with exposing /v2/images/xxx/recover in the main images api 20:38:44 markwash: I'm ok 20:38:45 +0.5 :) 20:38:55 flwang: you're okay with moving it to J? 20:39:00 +0.5 == +1 20:39:10 markwash: I'm ok 20:39:13 heh 20:40:02 adding notes in etherpad 20:40:04 rosmaita: 0.5 : J is make more sense. but i personally think it will be nice if we can think about my above question.. 20:40:11 "Move to J to address concerns about where this is exposed and how it affects pending-deleted locations" 20:40:26 zhiyan: yes, I agree with the idea behind that question 20:40:43 it would be neat if we had an admin only api that said "here are the pending-delete locations" and put /recover on that 20:40:54 but let's defer that conversation, a lot more bps to look at 20:41:07 Next up! glance.stores flaper87 20:41:08 markwash: yes 20:41:18 o/ 20:41:18 markwash: sure 20:41:22 pending-delete location maybe another topic 20:41:44 flaper87: there was a motion to push off the glance.stores integration to J, I'm not actually sure what steps we need to take and when they could happen 20:41:57 flaper87: do you wanna discuss outside this meeting or do you have some quick notes for us? 20:42:19 (if we don't get through all the blueprints I can track down folks offline) 20:42:31 markwash: I can do both, whatever is best for the meeting. Perhaps, I could start sharing the steps I'm trying to follow 20:42:37 and we can discuss this based on that 20:42:44 flaper87: that would be fantastic 20:42:48 ok 20:42:58 very quickly so I don't get other folks time 20:43:00 #action flaper87 to share steps / timeline for glance.stores for future followup 20:43:33 markwash: should I do it now? or later in the channel ? 20:43:37 I can write an ehterpad 20:43:40 that would be even better 20:43:49 let's go for later 20:43:57 +1 20:44:04 flaper87: maybe you can try to coordinate a time to discuss with us as well? 20:44:07 flaper87: maybe we can reuse https://etherpad.openstack.org/p/right_place_for_glance.store_modules 20:44:10 I should be generally available ish :-) 20:44:38 okay I'm going to skip around to try to hit the easier ones 20:44:58 the following in my view just need more review attention 20:45:14 cross-service-request-id tracking 20:45:17 #link https://review.openstack.org/#/c/68524/ 20:45:31 expose-owner-in-v2 20:45:32 #link https://review.openstack.org/#/c/69887/ 20:45:53 image-locaiotn-selection-strategy 20:46:05 #link https://review.openstack.org/#/c/58482/ 20:46:19 and related to that is getting glance tests on testrepository which is working okay for me now 20:46:28 #link https://review.openstack.org/#/c/59699/ 20:46:42 markwash: I saw there is a +2 from zhiyan, so it would be nice if there is anyone can approve it soon 20:47:18 https://review.openstack.org/#/c/69887/ 20:47:21 okay 20:47:29 I'll look again, maybe that's all we need 20:47:35 flwang: for https://review.openstack.org/#/c/69887/ , yes, i think it wil be better if we add a "docImpect" flag 20:47:39 markwash: cool 20:47:53 next: i18n-messages 20:48:03 flwang: any plans for this one in the next few weeks? or defer it to J ? 20:48:17 #link https://blueprints.launchpad.net/glance/+spec/i18n-messages 20:48:29 markwash: pls don't defer it :D 20:48:37 okay cool 20:48:44 but we'll look again next week if there is anything to review ;-) 20:48:52 markwash: we can complete it if the reviewers can follow up :) 20:49:11 markwash: I think it's the only patch 20:49:15 next: community-level-v2-sharing (rosmaita ) 20:49:25 #link https://blueprints.launchpad.net/glance/+spec/community-level-v2-image-sharing 20:49:34 rosmaita: let's go ahead and make iccha the assignee, sound okay? 20:49:43 +1 20:49:59 and I think we'll want at least an initial patch in the next 12 days 20:50:31 she's travelling right now, but if she were here, she would say "no problem" 20:50:49 nice 20:50:54 she probably wont be able to get started on this until mid next week though 20:50:56 I'll trust you 20:51:18 ashwini: :-) 20:51:24 let's give it a shot 20:51:30 next: workers / tasks 20:51:40 I see there's a lot of discusison about this on in the agenda etherpad 20:51:43 added some comments in the etherpad 20:51:47 yep 20:52:07 it sounds like we expect patches soonish? 20:52:13 ya 20:52:28 markwash: when do they need to be merged in? 20:52:38 do we still need async-processing bp? or can we kick that one out and just have it under Import Workflow ? 20:52:46 or Upload workflow, I think it is called 20:52:48 we need a baseline patch by 16th I suppose? 20:52:59 nikhil: by the 18th 20:53:04 okay, thanks 20:53:48 okay let's follow up on these bps on monday 20:54:00 next, image-location-status (zhiyan) 20:54:10 ops, my laptop died 20:54:11 :( 20:54:19 I'll work on the etherpad 20:54:19 I think this is mostly ready to review, but maybe there is a bit of concern about the first patch 20:54:29 #link https://review.openstack.org/#/c/67079/ 20:54:34 flaper87: okay great thanks 20:54:36 yes, migration 20:55:28 what about others? markwash, do you think their shape is good? 20:55:50 zhiyan: I looked, and while I like the idea of a little more clarity about what each is supposed to accomplish they looked mostly good 20:56:29 yeah I think I was generally pleased, it may be the only issue is the migration 20:57:04 zhiyan: I wouldn't mind just taking a crack at the migration, trying to get it to avoid being nullable, would I be stepping on your toes though? 20:58:11 markwash: actually i think nullable is ok, but maybe i missunderstanding your concerns.. 20:58:24 flaper87: let us know if you need help or just reviews on bug https://review.openstack.org/#/c/59150/ 20:58:38 okay 20:58:41 "but might complicate future operations" could you share what you have in mind markwash ? 20:58:51 markwash: I need help in the other one 20:58:54 the virtual_size 20:59:01 I don't get why it keeps raising that error 20:59:03 flaper87: ah okay yes I missed that one 20:59:05 I can't replicate the issue 20:59:13 flwang: tried as well and he wasn't able 20:59:20 -infra guys can't give me access to that box 20:59:22 #link https://review.openstack.org/#/c/65499/ 20:59:27 I tried creating a venv with ubuntu precise 20:59:36 ^^ needs help figuring out testing issues 20:59:36 but nein, it won't replicate the issue 20:59:47 and the funny thing is that it's a really trivial migration 20:59:58 it adds an BigInt field and removes it 21:00:04 no idea why it fails in the gate 21:00:17 zhiyan: I'll try to follow up with you on the migration, ping me if I forget 21:00:26 okay I htink we need to make way for the next meeting 21:00:34 markwash: thanks 21:00:43 thanks everybody for helping with the icehouse-3 triage push! 21:00:44 markwash: ok, thanks. 21:00:51 thanks markwash 21:00:54 #endmeeting