14:01:36 <rosmaita> #startmeeting glance
14:01:37 <openstack> Meeting started Thu Nov  2 14:01:36 2017 UTC and is due to finish in 60 minutes.  The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:41 <openstack> The meeting name has been set to 'glance'
14:01:53 <abhishekk_> o/
14:01:54 <rosmaita> #topic roll call
14:01:57 <McClymontS> o/
14:02:03 <benokolie> o/
14:03:44 <rosmaita> ok, now that croelandt is here, we can get started :)
14:04:03 <rosmaita> actually, let's wait 30 more sec for jokke_
14:04:17 <jokke_> o/
14:04:23 <rosmaita> excellent!
14:04:27 <jokke_> :)
14:04:30 <rosmaita> #topic updates
14:04:32 <croelandt> hehe, sorry for the delay
14:04:50 <rosmaita> ok, first thing is no meeting next week
14:05:05 <rosmaita> second thing is that we'll be low on core reviewers next week
14:05:22 <rosmaita> jokke_ , flaper87, and i will be travelling
14:05:27 <rosmaita> abhishekk_ will be on vacation
14:05:43 <abhishekk_> In case of emergency, i will be available
14:05:46 <rosmaita> (a well-deserved vacation)
14:06:07 <rosmaita> hopefully, no emergencies will happen!
14:06:16 <jokke_> ping us if there is anything urgent
14:06:33 <abhishekk_> Sure, thank you :)
14:06:37 <rosmaita> that's a good point, in case of emergency, we're all available
14:06:38 <jokke_> I at least won't be keeping eye on the review queue during next week
14:06:48 <rosmaita> what jokke_ said
14:06:52 <rosmaita> that was my real point
14:07:08 <McClymontS> I'm not OOO, I'll keep an eye on it and ping rosmaita lol
14:07:26 <rosmaita> that works
14:07:48 <abhishekk_> McClymontS: you can ping me as well ;)
14:07:56 <McClymontS> I'll ping everyone
14:08:15 <rosmaita> that's pretty much it ... we've got like 5 glance items on the summit agenda, so we hope to raise project awareness and come back with some new contributors
14:08:28 <jokke_> fingers crossed
14:08:31 <abhishekk_> Great
14:08:56 <rosmaita> i'm in the process of putting together an onboarding etherpad
14:09:10 <rosmaita> if you have time, take a look, feel free to add comments
14:09:26 <McClymontS> absolutely will, I am also keeping a nice running log on everything I have come across
14:09:28 <rosmaita> https://etherpad.openstack.org/p/SYD-forum-glance-onboarding
14:09:33 <McClymontS> including some bugs
14:10:31 <rosmaita> cool, make sure you file the bugs
14:10:57 <rosmaita> after the summit, i plan to get our bug triaging meeting started
14:11:14 <rosmaita> ok, that's it for updates
14:11:34 <rosmaita> #topic Update about the capability update feature in glance_store
14:11:39 <rosmaita> croelandt , that's yours
14:11:43 <croelandt> thanks
14:11:59 <croelandt> so, last week, we were wondering what stores used this feature
14:12:16 <croelandt> and I ended up saying I'd look into it
14:12:19 <croelandt> well, that was quick
14:12:42 <croelandt> all stores may use it, but no store actually does it
14:12:50 <jokke_> haha!
14:12:55 <croelandt> there is not a single implementation of "update_capabilities"
14:13:05 <McClymontS> easy enough
14:13:15 <croelandt> so, now we have to decide
14:13:22 <jokke_> holy crap ... so the config option has been literally just clutter there
14:13:38 <croelandt> whether we remove the whole thing, or keep it as is and start implementing the update_capabiliteis function when they are needed
14:14:04 <croelandt> jokke_: and before you "haha" again, our users have actually been asking for this once again since last week :D
14:15:08 <rosmaita> ok, i was just reviewing the discussion from last week
14:15:32 <rosmaita> http://eavesdrop.openstack.org/meetings/glance/2017/glance.2017-10-26-14.00.log.html
14:16:34 <croelandt> so I'd be in favor of keeping the whole thing and merging the patch I proposed, but I might be short-sighted here :)
14:17:03 <rosmaita> #link https://review.openstack.org/#/c/455454/
14:17:27 <jokke_> I know croelandt will hate me bit more, but I'm still inclined to get rid of that ... I think polling stores "Are you there yet? Are you there yet? are you still there?" is just bad idea
14:18:41 <croelandt> jokke_: hey, no hard feelings
14:18:53 <croelandt> jokke_: you'll be the one closing the downstream bugs, though :D
14:18:55 <jokke_> I might be wrong 'though .. I have no data to back up either way
14:19:05 <jokke_> it's just feels wrong
14:19:11 <croelandt> the good thing about this feature though, is that it's disabled by default
14:19:16 <jokke_> croelandt: NP ... happy to do that :P
14:19:49 <jokke_> if we end up to that decision
14:20:07 <jokke_> I'd like to hear what rest thinks
14:20:12 <croelandt> what does everybody think?
14:20:36 <rosmaita> let me make sure I understand how this works
14:20:50 <rosmaita> you'd set the update_min_interval
14:21:58 <rosmaita> and glance will poll the store if a store operation occurs outside that interval to check the current capabilities
14:22:04 <rosmaita> so it's not constant polling
14:22:36 <rosmaita> but you also might hit a few denials even after the store has been updated
14:22:44 <rosmaita> depending on the interval you picked
14:22:46 <croelandt> yeah
14:22:51 <croelandt> see the reviews on my patch
14:22:57 <croelandt> people said that it did not seem to fix the issue
14:23:05 <croelandt> and indeed, you might still get a few denials
14:23:10 <croelandt> but it ends up working as expected
14:23:55 <rosmaita> right, that's why the help text is so long for this option
14:24:44 <rosmaita> ok, other than the filesystem store, does anyone see this being useful for other stores?
14:24:47 <jokke_> IIRC it expects the change both ways so it still keeps polling the backend if there is changes happening
14:26:03 <abhishekk> Not sure at the moment, but this will be mostly used for fs store only
14:27:14 <McClymontS> Idk if I see a whole lot of value for other stores, but FS makes sense to me
14:27:59 <rosmaita> so how bad is the alternative jokke_ proposed last week, namely, make sure you don't start glance until the FS has configured itself?
14:28:50 <croelandt> apparently my users are not too happy with that
14:29:03 <croelandt> like rebooting/restarting a node causes issues
14:29:23 <croelandt> well, this might be solved my some better sysadmin skills
14:29:25 <rosmaita> ok, so does this happen a lot?
14:29:29 <croelandt> I would not know, being a terrible sysadmin myself
14:29:54 <croelandt> well, as I was saying earlier, I have 2 users who complain about this, one of them considering this an urgent matter
14:30:09 <nikhil> ./
14:30:30 <jokke_> I guess the main problem is with deployments that just haven't taken it into account and/or deployment tools that does not have proper state engine but just does operations at parallel
14:30:30 <rosmaita> nikhil , we're discussing croelandt 's patch for update capabilities, you had a comment on the review
14:30:41 <nikhil> ah
14:30:51 <rosmaita> #link https://review.openstack.org/#/c/455454/
14:30:59 <nikhil> ty
14:31:00 <McClymontS> its disabled by default correct?
14:31:05 <croelandt> iirc, yes
14:31:09 <McClymontS> just to make sure I am understanding this
14:31:18 <croelandt> jokke_: I feel like you should be able to tell systemd to do things as expected
14:31:32 <croelandt> but one of our users says a systemd-based approach failed (not sure why, though)
14:32:05 <rosmaita> maybe systemd just makes sure the FS is up, doesn't check that it's in writable state yet
14:32:26 <jokke_> so this is gluster specific but the principle is the same https://serverfault.com/questions/682553/systemd-start-a-unit-after-another-unit-really-starts
14:33:31 <jokke_> so one could for example put rule "ConditionPathExists=/mnt/nfs/images" which would prevent glance starting until that /mnt/nfs is mounted
14:34:51 <croelandt> hum
14:35:04 <croelandt> apparently they used (or were told to use?) "RequiresMountsFor=/var/lib/glance/images "
14:36:11 <croelandt> there is also "ConditionPathIsReadWrite"
14:36:23 <rosmaita> there look like several possibilities
14:36:47 <rosmaita> my feeling is that if this is strictly a startup time thing, go with systemd
14:36:47 <jokke_> yeah
14:37:24 <rosmaita> if we don't have a use case for dynamic updating of store capabilities, we shouldn't use it
14:37:25 <jokke_> that's why polling the store continuously feels wrong
14:37:28 <croelandt> I'll go back to the user
14:37:35 <croelandt> have them try ConditionPathIsReadWrite
14:37:36 <jokke_> but as said I have no data to back it up
14:37:42 <croelandt> and if that solves the issue, I'll drop the patch
14:37:45 <croelandt> how does that sound?
14:38:04 <croelandt> jokke_: it's not *constant* polling, though :)
14:38:18 <rosmaita> croelandt if that solves the issue, we can fix via documentation
14:38:31 <jokke_> croelandt: sounds great to me ... if that solves their issue I'd be super happy just to remove all that clutter
14:38:37 <croelandt> haha
14:38:38 <jokke_> what rosmaita just said
14:38:46 <croelandt> jokke is never as happy as when he can remove code :D
14:38:56 <jokke_> croelandt: absolutely
14:39:00 <croelandt> ok, let's agree on that and move on, shall we?
14:39:09 <rosmaita> sounds good, thanks!
14:39:19 <jokke_> thanks for digging into it croelandt
14:39:29 <rosmaita> #action croelandt research whether the systemd solution is acceptable
14:39:38 <rosmaita> ok, next item
14:39:49 <croelandt> jokke_: np
14:39:58 <rosmaita> #topic opinion on deleting images that exceed the storage quota
14:40:18 <rosmaita> benokolie has a bug filed and a patch up for this
14:40:30 <rosmaita> #link https://bugs.launchpad.net/glance/+bug/1726518
14:40:31 <openstack> Launchpad bug 1726518 in Glance "Image not deleted after upload when exceeding image_size_cap" [Undecided,In progress] - Assigned to Benard Okolie (benokolie)
14:40:58 <rosmaita> i'm skeptical about this one, but want the wider community to take a look
14:41:10 <rosmaita> benokolie anything to add?
14:41:50 <rosmaita> (let's give people a few minutes to read through the bug)
14:41:54 <benokolie> I think all the info should be in the bug
14:42:07 <nikhil> this should change in import rt?
14:42:18 <jokke_> I do agree and disagree
14:43:03 <jokke_> so that should be client change when the --file is provided on the image-create call and we know the file size
14:43:43 <nikhil> that’s much better I think
14:44:09 <rosmaita> yeah, i don't think it would be an acceptable api change
14:44:24 <jokke_> nope
14:44:43 <nikhil> rosmaita: seems odd to remove something under the hood,might break scripts
14:44:51 <jokke_> but the client should not issue the image create api call if it know that the upload will fail
14:45:19 <rosmaita> yeah, but the client doesn't know the max_cap
14:45:28 <jokke_> well it's just backwards incompatible API change to fix inconvenience
14:45:40 <jokke_> rosmaita: isn't that in the schema?
14:45:53 <rosmaita> i don't think so
14:46:03 <nikhil> yeah,something related to quota
14:46:32 <jokke_> well I think that's something in the API side we should fix then :P
14:46:40 <nikhil> looks like best to wait for quota
14:46:45 <rosmaita> well, it would be part of the discovery api we've been talking about
14:47:15 <rosmaita> on the other hand, we do support file upload when we don't know the size in advance
14:47:35 <jokke_> yup
14:47:41 <rosmaita> so even if we knew the max_cap, we'd still have this case
14:47:54 <jokke_> so it will be just early fail when client knows it's gonna fail like I said earlier
14:48:21 <rosmaita> yeah, my point is that benokolie could still work on this without waiting for the discovery api
14:48:29 <rosmaita> one question though
14:48:49 <rosmaita> with image import, if the PUT to stage fails, it's possible to retry
14:48:59 <rosmaita> as many times as you want until you issue the import call
14:49:19 <rosmaita> so for import, we don't want to delete the image record if upload fails
14:49:26 <rosmaita> so this would be asymmetrical
14:49:32 <rosmaita> any problem with that?
14:49:36 <jokke_> well it's the same with the image upload
14:50:01 <jokke_> if it fails the image returns to queued so you can go and resize your image and reupload without creating the image again
14:50:23 <rosmaita> right, but my point is the one-command thing in the client
14:50:36 <rosmaita> we're proposing that that could clean up after itself
14:50:44 <rosmaita> my question is, do we really want it to?
14:50:56 <jokke_> it's just with the client we prefer fail early so the client shouldn't make the api calls if it knows something down the workflow it's executing is going to fail
14:51:00 <jokke_> no
14:51:09 <McClymontS> I don't think we do
14:51:18 <jokke_> we do not want the client to delete the image automatically either
14:51:38 <rosmaita> ok, that
14:51:42 <rosmaita> s what i was getting at
14:51:45 <jokke_> just not create it in the first place if it knows it's gonna fail
14:52:01 <rosmaita> ok, so that solution has to wait for the discovery api
14:52:14 <rosmaita> so then the conclusion of this discussion is that this is *not* a bug?
14:52:25 <jokke_> I'd say free to propose a patch towards it as well :D
14:52:25 <rosmaita> in either the client or the api?
14:52:45 <jokke_> rosmaita: correct, not a bug, inconvenience
14:52:56 <rosmaita> or introduce a --cleanup option to the image-create when --file is present?
14:53:34 <jokke_> or one can just make the image-delete call to do it
14:53:36 <jokke_> ;)
14:53:43 <rosmaita> ok, the conclusion is: not a bug in the API, i will explain on the bug
14:53:53 <abhishekk> Stage and upload are same only difference is stage will upload data first in (temp directory) staging area, right?
14:54:38 <McClymontS> yes abhishekk I believe you are correct
14:54:48 <jokke_> abhishekk: literally uses the same code, just bit of wrapping around and stage currently utilizes file store only
14:54:52 <rosmaita> there may be an image status difference?
14:55:05 <McClymontS> they actually call the same functions I believe as jokke_ said
14:55:06 <abhishekk> Then if image_cap is set, is it considered while satging as well?
14:55:14 <jokke_> McClymontS: on client yes
14:55:29 <jokke_> API side stage is copy-paste with some changess
14:56:25 <jokke_> ok, lets move on ... we're running out of time
14:56:36 <rosmaita> ok, the conclusion here is that we need work on the discovery api in order for the client to be smarter and avoid stuff like this
14:56:46 <abhishekk> Yup
14:57:01 <rosmaita> benokolie we can talk after the meeting if you have any interest in working on the discovery api
14:57:13 <rosmaita> #topic open discussion
14:57:14 <benokolie> rosmaita: That would be great :D
14:57:15 <rosmaita> 3 minutes
14:57:22 <rosmaita> anyone?
14:57:47 <abhishekk> All the best for summit!
14:57:55 <nikhil> have a good summit, cya all after
14:58:16 <rosmaita> thanks! will hopefully come back with a basket of new contributors
14:58:30 <McClymontS> sounds good, good luck!
14:58:35 <abhishekk> \o/
14:58:40 <jokke_> o/
14:59:06 <croelandt> \o
14:59:30 <croelandt> https://review.openstack.org/#/c/512020/ <- If I could get a +2 on this before you all leave
14:59:31 <rosmaita> ok, guess that's all ... thanks everyone!
14:59:34 <croelandt> that'd be amazing, though
14:59:39 <jokke_> thanks
14:59:40 <abhishekk> Thank you all
14:59:49 <rosmaita> croelandt that's the image-target thing?
14:59:53 <croelandt> rosmaita: yeah
15:00:01 <croelandt> I still need one good review
15:00:06 <rosmaita> will try to make time
15:00:11 <rosmaita> #endmeeting