17:00:26 #startmeeting murano 17:00:27 Meeting started Tue Jun 21 17:00:26 2016 UTC and is due to finish in 60 minutes. The chair is kzaitsev_mb. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:31 The meeting name has been set to 'murano' 17:00:38 o/ 17:00:43 o/ 17:00:54 o/ 17:01:11 o/ 17:01:30 o/ 17:01:39 o/ 17:01:39 \o/ 17:02:06 o/ 17:02:07 #link https://wiki.openstack.org/wiki/Meetings/MuranoAgenda 17:02:12 :) 17:02:18 #topic Action Items Review 17:02:29 I think we had a couple, didn't we? 17:02:49 1) kzaitsev_mb vakovalchuk see that backports from prev review iteration are merged after stable/mitaka is unlocked 17:03:09 they're on the review last time i checked 17:03:37 I guess they are merged already 17:03:42 oh, cool 17:03:47 so done then 17:03:50 2) Nikolay_St test convergence on our CI and get ready to enable it 17:04:12 not ready yet 17:04:28 Nikolay_St: is it time to turn the switch? 17:05:15 I don't test it on second host as I want to do, but we can switch and just be prepared for troubles 17:05:26 if any 17:05:50 hah ) 17:06:21 it's not n2 yet, so I'm ok with waiting a bit longer 17:06:55 kzaitsev_mb: I'll try to do my best for enabling it on test host this week 17:07:32 just realized that blocked dashboard is not really blocker for that 17:07:40 #action Nikolay_St check convergence on 2d CI host and enable it 17:07:44 np ) 17:08:09 like I said we're not in a hurry here, just good to remember that we have this task on the horizon 17:08:22 ok, on to our 1st topic 17:08:48 #topic Migration to Glance V2 API 17:08:57 ok 17:09:01 Nikolay_St: can you share a link to the bp you've created 17:09:02 ? 17:09:25 #link: https://blueprints.launchpad.net/murano/+spec/migrate-to-glance-v2 17:10:21 I added this topic and created this bp because now it's clear that glance community won't add 'copy-from' operation to V2 API 17:10:31 so my real problem with it is that this is a *huge* degrading of the UX 17:11:03 However we would be forsed to abandon v1 at some point =( 17:11:40 mfedosin: are you here? 17:11:48 So for the CLI I would suggest to not download the images y default and have a switch for that 17:12:08 Nikolay_St: o/ 17:12:23 like --download-images={yes,no} 17:12:29 mfedosin: we discuss migration to Glance v2 for murano 17:12:33 sergmelikyan: StanLagun: ^^^ 17:12:45 Nikolay_St: looks valid for me 17:12:51 kzaitsev_mb: ^^ 17:13:33 and keep v1 behaviour untouched (i.e. still use copy-from) 17:14:15 I'm not sure, but saving data to temporary folder is not necessary 17:14:22 because well, downloading a 5 GB image and then uploading it to glance would take a lot of time 17:14:35 you just can open stream from given location and pass it to glance 17:14:42 it should work 17:15:02 mfedosin: what do you mean under 'open stream'? 17:15:25 It will still download it locally. You cannot transfer stream hadle over the wire 17:15:26 mfedosin: I'm not sure it's a good idea, since it would mean any error on any side would break the transfer 17:16:01 StanLagun: true, although we can do it chunk by chunk 17:16:12 but that is still a very error-prone way IMO 17:16:15 we wanted to implement it in glanceclient, but the idea was rejected 17:16:26 sad =( 17:16:36 I mean when you use copy-from in glance v1 it doesn't store any data locally 17:16:37 yes. I don't think it is a big deal. Local machine acts as a proxy in this scheme 17:17:36 StanLagun: the biggest deal is that the process of importing a package suddenly takes 5 mins or more, depending on the image size/bandwidth 17:18:08 That's okay. I hate the fact that we report that everything is imported when in fact it is not 17:18:30 StanLagun: we don't =) we say, that we've scheduled them for reporting 17:18:34 So as long as we don't consume gigs of hdd space locally I'm okay with that 17:18:36 We report that we started downloading image, and you can't deploy app until it's uploaded 17:18:43 StanLagun: and I disagree with you that it's ok 17:18:47 it's a UX killer 17:18:52 +1 17:19:20 this will require to change a lot's of staff in Murano to make this acceptable 17:19:28 Also this doesn't solve the dashboard at all, but 17:19:41 I think I saw tsufiev's commit on that 17:19:48 mfedosin: do you have a link at hand? 17:20:04 kzaitsev_mb: unfortunately no 17:20:07 if you cannot deploy apps that you need to wait anyway. I mean it is the matter of implementation. Of you block user from navigating to other pages then it's not good. If this is a background task with a progress bar in murano UI then nothing wrong here 17:20:35 at least you can use glance v1 way and use glance_store to get data and pass it local storage 17:21:07 #link https://review.openstack.org/#/c/320039/12 17:21:53 mfedosin: that doesn't sound like a viable solution to me 17:22:14 anyway... 17:22:17 #link https://github.com/openstack/glance/blob/b9de463ee8c37c27e834a219367732b2177411a9/glance/api/v1/images.py#L654-L658 17:22:38 and then just 17:22:40 #link https://github.com/openstack/glance/blob/b9de463ee8c37c27e834a219367732b2177411a9/glance/api/v1/images.py#L689-L690 17:22:44 there is a reason it starts with _ you know 17:23:25 kzaitsev_mb: and I think you shouldn't expose it to public as well :) 17:24:20 I'll review tsufiev's solution and provide a feedback 17:24:59 We can also fork a new process for downloading/proxying the image in the CLI 17:25:10 how bad does that sound? 17:26:51 just asked tsufiev — he just removed copy-from in horizon 17:26:56 =( 17:28:21 yeah, that doesn't really leave us much option 17:29:17 kzaitsev_mb: yeah, i discussed it with him 17:30:46 I wonder how uploading huge images works in horizon though 17:31:03 mfedosin: hey, does glare solve that in any form? =) 17:31:47 like can I instruct glare to upload a BLOG from a http location? 17:33:44 I believe tsufiev has implemented uploading of huge images without blocking the UI somehow 17:33:50 gotta ask him on that ) 17:34:33 #action kzaitsev_mb ask tsufiev/horizon team about the possibility to upload huge images without blocking the UI 17:34:36 as for the CLI 17:34:48 this whole thing really can make implementation in Murano much more complex that it was before 17:35:20 I tend to agree with StanLagun's idea that proxying an image is better then downloading 17:35:20 I am wondering what was the reason behind so handy feature of removing this from glance v2 17:35:30 althoug it will make code more complex 17:35:38 any objections to that? 17:36:11 sergmelikyan: personally I wonder what was the reason to deprecate an API that provided better functionality ) 17:37:48 I also suggest to add a --download images switch 17:37:55 oh, that's actually a lot 17:38:11 I guess we can write a spec for this 17:38:31 kzaitsev_mb: that's a good idea 17:38:34 is there a way to use glance_store directly? 17:38:45 to upload staff? 17:38:57 to upload staff and than point glance to it? 17:39:28 I thought it is what glance client does 17:39:39 sergmelikyan: sure, but that would mean we have to re-write part of the v1 client and I'm not sure that it would help us 17:40:09 it would still be muranoclient, that handles the long-term communication, right? 17:40:37 meaning the CLI/dashboard would be blocked, unless we fork/thread-out 17:42:15 ok, I suggest Nikolay_St and I would draft a spec and we would list all the possible solutions there 17:42:19 we could have import written in MuranoPL similar to long running deployments with reporting etc. 17:42:53 because I doubt we would get to any meaningfull conclusion right now (= 17:43:20 kzaitsev_mb: I agrre on that 17:44:14 #action Nikolay_St kzaitsev_mb draft a spec with all the options we have considering swtiching from glance v1 to glance v2 17:44:30 Nikolay_St, thanks for bringing this up 17:45:43 ok, it's 2 weeks already since we last checked backports 17:46:21 we haven't added anything regarding that to Murano Agenda, but I'll use #topic ) 17:46:26 #topic backports 17:46:40 vakovalchuk: can you share a link to the etherpad? =) 17:46:53 just a sec 17:47:06 #link https://etherpad.openstack.org/p/murano-stable-backports 17:47:53 I haven't really had time to check the list yet ) 17:49:30 So let's follow the usual procedure here — we have a couple of days to write comments, if you think we've missed something or that some patch is not worthy of being backported (i.e. too low or actualy is a feature) — please write that as comments to the etherpad =) 17:50:13 vakovalchuk and I would get to backporting those by the end of the week =) 17:50:48 I think there are a couple of low bugs there, that can be skipped, but like I said I haven't really checked those yet ) 17:51:02 vakovalchuk, thanks a lot for keeping this procedure going =) 17:51:09 #topic Open Discussion 17:52:29 long meeting today :D 17:52:37 I think the only piece of news I have is — https://review.openstack.org/#/c/332093/ 17:54:23 thanks to haypo for his work on that ) now we gotta push those through the gerrit, as the gate check doesn't start for some reason ) 17:54:39 woohoo 17:54:39 Nikolay_St: well, you've raised a really tough question this time =) 18:00:51 ok, we're out of time. thanks everyone for joining today 18:00:54 #endmeeting