14:00:14 #startmeeting glance 14:00:14 Meeting started Thu Aug 14 14:00:14 2014 UTC and is due to finish in 60 minutes. The chair is arnaud__. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:17 The meeting name has been set to 'glance' 14:00:20 oo/ 14:00:29 o/ 14:00:33 \o 14:00:54 o/ 14:01:06 here is the agenda 14:01:13 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:01:58 before starting with the agenda, I would like to bring up what we have scheduled for Juno-3 in launchpad 14:02:42 I learned this week that a spec approved doesn't get automatically its LP blueprint equivalent (there is a script to do it), but it's manual process, and it doesn't set the priority 14:03:03 #link https://launchpad.net/glance/+milestone/juno-3 14:03:13 Can we also add Murano adoption to discussion? 14:03:28 please gokrokve add it do the agenda 14:03:34 hello~ 14:03:35 I think we will have a lot of time 14:03:37 to discuss about it 14:04:10 this is my first time to join glance meeting, I'd like to know if I can discuss a patch in this meeting? 14:04:48 yes, please xianghuihui either add it to the agenda, if it's a specific problem, if you need review, please find til the end for the open discussion 14:05:04 s/find/wait 14:05:11 arnaud__, thank you : ) 14:05:18 so, for juno-3, we have 3 blueprints 14:05:23 * xianghuihui is looking at agenda 14:05:54 first thing is we do not have a bp for artifacts 14:05:57 arnaud__: i thought some tasks stuff was supposed to land also in juno-3? 14:06:12 good point rosmaita 14:06:28 nikhil___, I know there is a bp somewhere for tasks 14:06:41 yes 14:06:55 I think we might want to target it for j-3 14:07:17 #link https://blueprints.launchpad.net/glance/+spec/async-glance-workers 14:07:27 k 14:07:44 ok cool thanks 14:07:48 done 14:08:41 nikhil___, do you feel confident we can make it in j-3? I know you had some problems 14:09:20 we'd be having it for sure 14:09:33 ok sweet 14:09:33 as long as gates work fine :) 14:10:28 ok, so for j-3, we also have metadefs 14:10:40 so for this one, we need reviews :) 14:11:35 +1 :) 14:12:21 arnaud__: do you think we can make glance.store adoption in j3 as well? 14:12:25 the others (gpfs and restrict download) are smaller and need review too 14:12:36 maybe a little tight 14:13:01 zhiyan, I have been trying to discuss with flaper87|afk , but every time I try to ping him, he is afk 14:13:19 I know he is updating the patch for the integration 14:13:36 arnaud__: he will back from vacation at next Tuesday btw 14:13:51 oh ok 14:14:19 arnaud__: anyway, let's talk this with him next week, let's see if we can make it in j 14:14:21 yeah, so, I think this one might not make it in j-3 (we will double check when he is back) 14:14:25 but I'm a little worried frankly 14:14:31 agreed zhiyan 14:14:47 what are the implications of missing j-3? 14:14:56 arnaud__: probably we have a long port-back list. 14:15:12 rosmaita, backports 14:16:08 better to wait for flaper87|afk, but I am a bit concerned for the gpfs backend 14:16:16 sorry, i mean if glance.stores does not land in j-3, will it still be able to get into Juno release? 14:16:26 rosmaita: no adoption means we need to maintain two trunk, but for glance itself is ok. 14:16:54 zhiyan, the question is: do we still accept checkins in the store folder? 14:17:11 arnaud__: of course, imo 14:17:34 arnaud__: we just need a correct port-back list for glance.store 14:18:09 agreed 14:19:07 ok so let's wait for flaper87|afk to be back, unless someone is willing to make progress before he gets back? 14:19:08 :) 14:19:21 any candidates? 14:19:23 :) 14:19:39 arnaud__: flaper87 actually currently needs some review help 14:19:54 for what? 14:20:09 the entry point at https://review.openstack.org/#/c/103067/ 14:20:16 zhiyan, I have in mind https://review.openstack.org/#/c/100636/ 14:20:22 adoption nikhil ^ 14:20:44 arnaud__: yes, but it's not the root 14:20:48 hmm 14:21:08 am not sure if j-3 or any "3" is the best point of time to make such a big switch 14:21:25 nikhil___: but i see, we need a port-back list for glance.store, to make it ready to get finally adoption in glance 14:21:26 taking code out of a project just before freeze adds nervousness 14:21:51 yep agreed 14:22:19 that's all for me on glance.store topic 14:22:27 arnaud__: ^ 14:22:36 zhiyan, I am going to start building the list 14:22:38 zhiyan: we can have it ready during the freeze and keep a good process for any additions 14:22:50 we had an action item last week to do that, but unfortunately, didn't have the time 14:22:58 I will start it today 14:23:02 cool 14:23:05 arnaud__: may i know which one? 14:23:14 backport list 14:23:17 kk 14:23:25 ok, let's continue with our agenda 14:23:27 actually i asked flaper, but not response 14:23:42 #topic utf8 migrations issue https://review.openstack.org/#/c/109154/ 14:23:58 zhiyan, I think you added this one right? 14:24:05 it's me 14:24:09 oh ok :) 14:24:18 zhiyan: do you have any specific reason for -2? 14:24:29 actually we discussed and fixed it with a workaround approach in i cycle 14:24:31 seems like we are getting positive responses from other folks 14:24:58 yeah, so that workaround is working fine however the dev/ops are complaining that it's not the best route 14:25:13 am wondering if the discussion in the ML is still a hold up 14:25:25 do you remember why it was blocked? 14:25:37 because 14:25:52 the problems to me for it are two: 1. for data corruption issue; 2. potential un-controlable migration runtime for db_sync 14:25:57 you can modify the charset collation of the tables, but the data are still using the previous charset/collation 14:26:38 arnaud__: dml sentence could work, but it could make data wrong 14:27:09 a discussion log for why we use current workaround way for glance-manage http://eavesdrop.openstack.org/meetings/project/2014/project.2014-03-18-21.03.log.txt 14:27:24 a example how can we make data corruption 14:27:32 http://lists.openstack.org/pipermail/openstack-dev/2014-March/030404.html 14:27:53 (i can't find another one now, it's a little later) 14:28:06 #link http://lists.openstack.org/pipermail/openstack-dev/2014-March/030404.html 14:28:57 zhiyan, I am not sure if another email in the ML would help 14:29:01 what do you think? 14:29:52 so, in short, (let me try my English), before utf8migration, we don't really know what's the data coding in the table, latin charset can contains utf8 data, which based on upperlayer app - galnce. 14:30:22 so, how does the manual changing of the DB help 14:30:24 ? 14:30:28 arnaud__: i can put some info to that change. 14:30:48 we may run into corruption there as well and be stuck with fixing the entries manually again, right? 14:31:13 imo, operator to make sure what's the real charset of the data in table. can do the right charset conversion. 14:31:52 don't know yet, however feels like we can automate this 14:32:01 iiuc, he probably need to check if there is anything high bit before execute migration 14:32:36 yeah, and that may take forever to do so 14:32:45 ok, so let me try to reach markwash for this, since this has been discussed at the cross-group sync up 14:32:54 sounds good, thanks 14:33:17 nikhil___ actually i did a same MP in i cycle for this issue, but after discussion, for the security of data, we decided to ask operator take this responsibility. 14:33:25 arnaud__: do you know when he would be back? 14:33:28 #action check with markwash the decision taken for utf-8 14:33:56 20 something 14:34:20 zhiyan: yeah, saw your patch and wanted to get clear understanding of whether we have discussed all possible options before taking that route :) 14:34:21 arnaud__: btw, i will remove that option of db_sync in J cycle https://github.com/openstack/glance/blob/master/etc/glance-api.conf#L566 14:34:36 thanks arnaud__ 14:35:06 zhiyan, sounds good to me 14:35:44 nikhil___: technically, we can do anything in migration script, e.g. hight bit checking, but I think we don't feel confidence on the heavy operation on client's real data. 14:36:18 and need to think about the time of execution as well, probably it will take long. 14:36:48 yeah, however am thinking this may not be such a open ended problem after all 14:37:14 there must be some restrictions/practices which allowed some modifyable data 14:37:26 let's see 14:37:28 like to do a good solution as well. but back to the topic, 14:37:39 current approach which patch proposed is wrong. 14:38:09 k 14:38:29 agreed zhiyan 14:38:41 ok, so let's move on 14:38:59 #topic restrict download patch review https://review.openstack.org/#/c/98737/ 14:39:22 which is one of our targeted blueprint for j-3 14:39:55 I looked at the patch. Abhishek addressed mark's concerns 14:40:10 I feel the patch is almost in a good shape 14:40:11 i think it needs some review from mark. yes 14:41:07 I am confident that this one will make it: I have a couple of comments on the patch, but I didn't publish them yet 14:41:15 interesting, so I'm a little away from the ongoing work 14:41:41 I think it's a pretty cool feature to have 14:41:46 does this do anything other that the restrictions added by nova for booting/resize purposes? 14:42:02 not so much as resize 14:42:14 nikhil, i think it's focus on glance only 14:42:41 yes, the idea here is just to be able to restrict the download based on a specific protected metadata 14:42:51 booting/resize one might be covered by 'deactivation' stuff? 14:42:52 not sure 14:43:13 yeah, this may mean some overlaping policies for nova and glance 14:43:36 will ask for some perpective on this 14:43:43 confused, iiuc, image-deactivate is a different approach from this one 14:43:47 nova perspective 14:44:01 not deactivate, just the restriction on download 14:44:30 this could apply to public facing glance though, which makes sense . However, we've export for those purposes 14:44:37 we can jsut do restriction on glance side, no? 14:44:53 nikhil___, not sure to get your point about nova? nova is not the only consumer of glance 14:45:13 however, policies on nova apply to end user right? 14:45:14 +1 zhiyan 14:45:51 so, downloading this image for any other purposes besides nova use makes sense to have such restriction 14:46:04 ok, just to make sure we are on the same line, could you clarify which nova policies you are talking about? :) 14:46:53 need to check, you can add me to action item on this 14:46:59 ok 14:47:20 #action check the nova policies and find overlap with https://review.openstack.org/#/c/98737/ 14:47:27 ok, next 14:47:49 #topic launcher https://review.openstack.org/#/c/110867/ 14:49:42 I still this one might wait K-1 14:49:51 s/still/think 14:49:56 +1 14:50:01 10 mins left 14:50:34 ok, so unless someone really needs that in J, let's postpone to K 14:50:44 +1 arnaud__ 14:51:12 nikhil___, would you mind looking at https://review.openstack.org/#/c/112293? 14:51:45 arnaud__: waiting for you comment on the existing comments on it :) 14:51:47 (I would like to leave a bit of time for the murano folks) :) 14:52:00 :-) 14:52:03 that was all there was to that link :) 14:52:12 oh missed it 14:52:15 ok will look at it 14:52:17 np 14:52:23 thanks 14:52:31 ok so let's move to murano 14:52:36 #topic murano 14:52:56 gokrokve, sorry not much time, but please give an overview 14:53:06 As you probably know we decided to split Murano project to several pieces 14:53:21 Once of them is Murano-API which is Application Catalog API 14:53:56 We would like to explore an opportunity to join Catalog program and put Murano-API to this program 14:54:07 This is not an incubation request 14:54:40 This is just a declaration of intensions 14:55:00 gokrokve: what's Catalog program? any link there? thanks. 14:55:05 So we would like to have a feedback from Glance team about thais idea. 14:55:25 zhiyan, the catalog program is the future of the image program 14:55:34 ah, got it 14:55:34 zhiyan: This is Glance which was converted from Images program to Catalog program 14:55:40 new mission 14:55:44 remember 14:55:45 Yes 14:55:53 the mission has not been changed yet (afaik), but markwash has a patch out for review 14:55:54 gokrokve: do you have link to more info about this murano split? 14:56:04 +1 TravT 14:56:10 arnaud__: thanks 14:56:19 so, any other major changes besides the artifacts one? 14:56:37 TravT: no. this is just an idea how we proceed with the community 14:56:38 nikhil___, that would not imply changes to "glance" at the moment 14:57:00 We have Catalog API, Orchestration engine and UI 14:57:08 just take the API piece of murano and have it under the catalog program umbrella 14:57:09 I thought that the mission was indeed changed 14:57:12 We see that UI part goes to Dashboard program 14:57:22 Orchesration part goes to Orchestration 14:57:33 and Catalog API goes to Catalog program 14:57:34 since it's just a layer on top of artifacts 14:57:59 arnaud__: Yes. theat is exactly what we want 14:58:00 ativelkov: code first get in, else things can be out of sync for cycles together :) 14:58:09 why not just use that api as artifacts needed? if they are similar 14:58:24 just throw out my quick thinking 14:58:29 zhiyan, they are not similar, it's another set of APIs 14:58:34 afaik 14:58:39 ok 14:58:48 so, anothe "plugin" ? 14:58:54 zhiyan: It will happen eventually. I suspect ost of this API will go to artifact plugin 14:59:23 ok, so we have 1min left 14:59:25 gokrokve: ok, will see it going 14:59:26 The reason why we want this is to work closer with the community 14:59:38 gokrokve, it would be nice if you could bring a document explaining the split 14:59:43 We need an approval from Glance team 14:59:57 arnaud__: Ok. I will prepare it 15:00:08 we will continue the discussion next week (and start with this item) 15:00:15 ok 15:00:18 gokrokve: do you have a doc to explain that catalog api? 15:00:23 reminder: please review the metadefs stuff. 15:00:25 Thanks!! 15:00:32 #endmeeting