14:00:22 <nikhil> #startmeeting glance
14:00:24 <openstack> Meeting started Thu Sep 17 14:00:22 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:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:27 <flaper87> o/
14:00:27 <openstack> The meeting name has been set to 'glance'
14:00:30 <nikhil> #topic agenda
14:00:37 <rosmaita> o/
14:00:37 <nikhil> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:00:40 <jcook> o/
14:00:42 <kairat> o/
14:00:43 <pmesserli> o/
14:00:55 <mfedosin> o/
14:01:09 <nikhil> Small agenda today
14:01:30 <ativelkov> o/
14:01:38 <nikhil> I hope to discuss RC related stauff with you all in the remnant time
14:01:49 <nikhil> #topic Updates
14:01:49 <jokke_> o/
14:01:58 <nikhil> #info artifacts updates
14:02:05 <mfedosin> hi folks
14:02:26 <mfedosin> we still need several to be merged
14:02:31 <mfedosin> *commits
14:02:43 <mfedosin> https://etherpad.openstack.org/p/fastTrackPatches
14:02:51 <sigmavirus24> o/
14:03:01 <dshakhray> o/
14:03:04 <mfedosin> which are marked "essential for murano"
14:03:12 <jokke_> mfedosin: those are bugfixes?
14:03:24 <mfedosin> yes, all of them
14:03:32 <nikhil> mfedosin: ok, we still have 2-3 days. Do you have a bug corresponding to each commit?
14:03:32 <flaper87> mfedosin: ++
14:03:39 * jokke_ makes mental note to add to the list
14:04:02 <mfedosin> I think LP bugs are already in commit messages
14:04:09 <mfedosin> but I'll recheck
14:04:32 <nikhil> mfedosin: in order for me to block RC{1} on those commits, I would require a bug # corres to each commit that is needed
14:04:33 <mfedosin> also we spent last three days in discussion about future development
14:04:39 <nikhil> this is for rel-mgmt
14:05:03 <mfedosin> nikhil, ah, okay, will do
14:05:16 <nikhil> thanks
14:05:35 <mfedosin> so, I started to right documents about our decisions
14:05:49 <mfedosin> and Alex is going to right an article to Openstack wiki
14:06:00 <flaper87> mfedosin: coolio
14:06:42 <mfedosin> flaper87, I heard this word from Jay Pipies yesterday =P
14:06:53 <flaper87> mfedosin: lol
14:06:55 <flaper87> :P
14:06:58 <mfedosin> *Pipes
14:07:23 <mfedosin> I think it's all about artifacts for this moment
14:07:52 <nikhil> cool
14:08:20 <nikhil> #info drivers updates
14:09:07 <nikhil> so, we mostly discussed the two FFes
14:09:22 <nikhil> there were some outstanding concerns on both
14:09:36 <nikhil> http://eavesdrop.openstack.org/meetings/glance_drivers/2015/glance_drivers.2015-09-15-14.00.html
14:10:14 <nikhil> rosmaita: helped figure out the non-requirement on checking with docs team on config options
14:11:13 <rosmaita> they generate config manual from our sample configs in the repo, so it's up to us to get changes in on time
14:11:41 <rosmaita> they just supply a 1 paragraph intro to each config file
14:11:52 <rosmaita> and that won't change much from release to release
14:12:24 <flaper87> rosmaita: I take that we're good to go with this spec
14:12:26 <flaper87> right ?
14:12:37 <flaper87> just trying to make sure I'm interpreting things correctly
14:12:50 <rosmaita> you mean the scrubber spec?
14:13:19 <flaper87> rosmaita: yes
14:13:20 <nikhil_k_> irc bouncer dropped, sorry...
14:13:23 <flaper87> sorry for not being specific
14:13:36 <rosmaita> flaper87: np, don't mean to be pedantic
14:13:46 <flaper87> rosmaita: you weren't at all :)
14:13:47 <rosmaita> but yes, we are cool with scrubber config changes
14:14:06 <rosmaita> basically, docs will cut "stable release" manuals sometime after Oct 15
14:14:09 <flaper87> awesome, as I mentioned in the drivers meeting, I'm happy with moving that one forward
14:15:12 <nikhil_k_> I see some test related issue mentioned on the code proposal
14:15:36 <jokke_> that sounds vaguely familiar, is that the one I still have -2 on implementation due FF?
14:15:46 <jcook> jokke_: yes sir
14:15:46 <nikhil_k_> https://review.openstack.org/#/c/196240/
14:16:01 <nikhil_k_> most probably intermittent issue
14:16:02 <jokke_> is the spec merged?
14:16:12 <nikhil_k_> nope
14:16:18 <nikhil_k_> I will get that done today
14:16:48 <jokke_> cool ... give me a ping when that gets +A and I'm happy to drop my -2 on the implementation ;)
14:16:58 <nikhil_k_> let's make sure we don't create panic in the gate
14:18:02 <nikhil_k_> I missed the ova discussion
14:18:04 <nikhil_k_> were there any red flags?
14:18:11 <nikhil_k_> https://review.openstack.org/#/c/214810/
14:18:46 <nikhil_k_> ok, if nothing. Let's move on.
14:18:50 <jokke_> I still think it's modifying saved image data, but I'm not 100% sure
14:18:59 <flaper87> we haven't had the ova discussion
14:19:02 <flaper87> but:
14:19:10 <flaper87> 1) The spec still has some nits to fix from rosmaita
14:19:16 <flaper87> 2) The implementation is not there yet
14:19:23 <flaper87> jokke_: it is not
14:19:29 <flaper87> I'm happy to exaplin this offline
14:19:41 <flaper87> (unless I didn't read the implementation properly)
14:19:53 <jokke_> cool
14:20:11 <flaper87> I commented on the implementation earlier today
14:20:28 <flaper87> trying to keep my comments limited to relevant things and not nits that could be fixed later on
14:20:35 <flaper87> that's it from me
14:20:46 <flaper87> I'll keep following up on that one
14:21:05 <nikhil_k_> Thanks, I believe it's not modifying the saved image data looking at the flows but good to double check.
14:21:40 <jokke_> yes I have tried to avoid to tangle into typos etc as well
14:21:58 <nikhil_k_> Feels like it can make it by Monday. I think we should have to discussion with the developers/commiters that if it's not ready one of us will just fix the things and get it done.
14:22:02 <rosmaita> i will go back and look at my nits and see if they really matter in the big picture
14:22:45 <jokke_> I also don't want to see it merged half baked so if it's not making it, please lets not just merge it for the sake of it
14:22:54 <rosmaita> jokke_: +1
14:22:55 <nikhil_k_> yes
14:23:00 <flaper87> nikhil_k_: it'd be great if you or sabari could sync w/ them. They are in the west coast and it's quite difficult for me
14:23:01 <jokke_> there are still quite a few actual concerns in the comments
14:23:35 <nikhil_k_> I feel hesistent about merging import related stuff at this time of cycle if they aren't completely done.
14:23:42 <mclaren> +1
14:23:42 <flaper87> jokke_: ++
14:23:57 <flaper87> jokke_: the ones that I've written down I consider important
14:24:02 <nikhil_k_> flaper87: sure, I will act as mediator.
14:24:14 <jokke_> flaper87: I totally agree with that
14:24:46 <mclaren> I don't think the ova should merge
14:24:49 <mclaren> Uses existing Glance import taskflow
14:25:00 <mclaren> there is a serious question mark over whether that's a real thing or not
14:25:12 <rosmaita> well, that depends who you talk to
14:25:17 <flaper87> mclaren: well, it uses tasks
14:25:32 <nikhil_k_> so,if the API is public we HAVE to support it
14:25:33 <mclaren> yes, but tasks seem to be operator specific things
14:25:45 <rosmaita> mclaren: that depends
14:25:47 <mclaren> I think it's enough of a grey area not to rush this out
14:25:51 <nikhil_k_> it depends whether we communicate it as primary API or something hidden
14:26:07 <mclaren> we don't want another non-standard way of uploading images
14:26:22 <flaper87> I think this a topic for the summit (tasks, public, API, ops, etc)
14:26:29 <rosmaita> flaper87: +1
14:26:39 <nikhil_k_> if the API is public it will hardly pass DefCore to be admin only, btw
14:26:45 <rosmaita> but i want to point out that tasks have been in the public API for 2-3 cycles now
14:27:12 <nikhil_k_> The question is which is the standard API
14:27:17 <nikhil_k_> and that is a different question from all of this
14:27:36 <rosmaita> sounds like defcore thinks v1 is the standard api
14:27:37 * flaper87 really wants to put this discussion on hold until he can hug the rest of the team in tokyo
14:27:39 <mclaren> rosmaita: which tasks? which well-defined tasks?
14:27:39 <nikhil_k_> more of a overarching question but still a different discussion
14:28:06 <nikhil_k_> flaper87: I think what we want to come out of this conversation today is
14:28:11 <nikhil_k_> 1. can we merge this by Monday?
14:28:30 <nikhil_k_> 2. how badlly this will affect the standard workflows if merged?
14:28:47 <flaper87> I think this specific spec is unrelated to the tasks api discussion
14:29:08 <mclaren> I think it has the potential to cause more confusion
14:29:42 <flaper87> However, at this point, I'm becoming more and more doubtful of this work bing ready in time
14:29:44 <mclaren> we need to take heed of Doug's mail and sort out a standard upload/import thing
14:29:45 <nikhil_k_> ok, let's sycn offline
14:29:52 <rosmaita> mclaren: that's true, but it's kind of late to bring that up to the team working on OVA right now
14:29:52 <flaper87> and, as mentioned before, I've no intention to rush it
14:29:54 <mclaren> this spec should not go in before we do that
14:30:20 <mclaren> rosmaita: honestly? tough
14:30:46 <mclaren> we are under the microscope from the community at the moment
14:30:53 <rosmaita> i guess it's just part of the magic of working on glance
14:31:20 <jokke_> that is fair point, this has possibility to divert the deployed clouds more than the current situation and I think it's fair question to ask is this jeoparding our priorities ref. defcore ... at least I don't have answer for that
14:31:21 <mclaren> I think rushing this in isn't worth it
14:32:09 <flaper87> mclaren: I agree that rushing this is not worth it, I support that
14:32:40 <flaper87> the question we also need to answer, though, is whether after we have the tasks/api discussion we'll still have these things as tasks or not
14:33:00 <rosmaita> i think there will still be tasks, just a matter of how they are exposed
14:33:04 <jokke_> Also I don't know if making this available for this cycle out of tree will make it any better
14:33:07 <flaper87> Say, hypotetically, we decide that the import flow should go. I believe we'll still have tasks
14:33:14 <flaper87> rosmaita: right
14:33:45 <mclaren> tasks are fine!
14:33:49 <nikhil_k_> So, afaict this isn't affecting any more than what's already there.
14:33:58 <flaper87> Note that what is being questioned are not tasks specifically but using them as a way to import images and then having 2 upload APIs, etc
14:34:13 <flaper87> nikhil_k_: my point exaclty.
14:34:18 <flaper87> but I see where mclaren is coming from
14:34:18 <mclaren> yes, we need to stop thinking in terms of an application and in terms of an API
14:34:36 <jokke_> flaper87: ++, thus I think that's fair question to ask even this late in the process
14:34:41 <nikhil_k_> and the API isn't changing
14:34:45 <flaper87> jokke_: fully agree
14:35:18 <mclaren> nikhil_k_: I'm not sure I agree
14:35:18 <flaper87> and honestly, if I have to choose between creating more confusion and waiting 1 cycle, I'd probably go with the later
14:35:20 <nikhil_k_> so, one thing is for sure tasks can't be the standard API if not everyone can expose it in a standard way
14:36:02 <flaper87> nikhil_k_: I think the 'standard' term is being misused everytime we talked about APIs
14:36:08 <mclaren> I think that the image_import task was signalled to be a 'sample'. There is nothing about this spec to suggest it is not the official way to import ovas
14:36:12 <flaper87> because there's more to it than just what's exposed
14:36:25 <nikhil_k_> deprecating task workflow isn't going to be just one cycle thing, we need to support it for a few cycles the way it is possible using versioning of some sort
14:36:26 <mclaren> and must be supported at all sites
14:36:27 <flaper87> we should also add to the discussion whom we're exposing the api to
14:36:43 <mclaren> I'm not sure we need to deprecate 'tasks'
14:36:56 <flaper87> I think tasks should stay
14:37:03 <flaper87> the discussion we need to have is about the API
14:37:10 <flaper87> more specifically, the *images* API
14:37:13 <mclaren> we just shouldn't put official upload stuff under /tasks
14:37:16 <flaper87> Everything related to image management
14:37:22 <nikhil_k_> we are talking about deprecating tasks-workflow the way it is, if that's where community decides to go
14:37:49 <flaper87> no, we're talking about deprecating the import-flow and re-use tasks in a different way
14:38:06 <nikhil_k_> I think the message was clear to the proposers that this won't be a standard way for them to upload ovas
14:38:19 <nikhil_k_> rosmaita: had specifically asked for it to be admin only
14:38:30 <nikhil_k_> is the impl not doing that yet
14:38:30 <nikhil_k_> ?
14:38:37 <flaper87> I don't think mclaren argument is about what the proposers think but about what ops and users will think about this
14:38:54 <flaper87> nikhil_k_: I believe it checks the amdin context
14:38:56 <flaper87> yes
14:39:02 <flaper87> actually, yes. I remember reading that
14:39:29 <rosmaita> yes, me too
14:39:34 <nikhil_k_> if it's a admin only way to upload ovas, I think this won't break the standard API clause more than what is being discussed -- was my point
14:39:51 <flaper87> again, I think the impl as it is now seems fine and assuming it'll be updated, we should be ok
14:40:02 <nikhil_k_> agree
14:40:03 <flaper87> but taking time to think about mclaren's question won't harm
14:40:13 <flaper87> and we should do it before we finally merge that code/spec
14:40:22 <nikhil_k_> so, we can't wait more than one day for Liberty
14:40:26 <mclaren> again, if we view things as an application it will work. If we want to have a sane api I think it makes no sense not to wait until we have the new upload workflow and integrate with that
14:40:39 <nikhil_k_> and it's feels like a decisive moment to me
14:40:43 <mclaren> um s/not to/to/
14:40:56 <rosmaita> i was having trouble parsing that sentence!
14:41:03 <flaper87> :P
14:41:10 <mclaren> heh
14:41:33 <jokke_> I think it makes perfect sense ref what mclaren said before
14:41:48 <jokke_> makes sense to wait until
14:42:03 <jokke_> couple of extra nots, to put pressure on the point ;)
14:42:14 <jokke_> but maybe that's just because I'm Finnish
14:42:49 <flaper87> jokke_: lol
14:43:40 <mclaren> hm, wasn't I not right first time?
14:43:49 <jokke_> wasn't joking we use structures like that
14:44:01 <nikhil_k_> yeah, I thought so too
14:44:13 <nikhil_k_> or may ne s/no sense/sense/
14:44:32 <mclaren> or nonsense?
14:44:37 <nikhil_k_> heh
14:44:54 <nikhil_k_> on this lighter note, let us give time to other agenda items.
14:45:07 <nikhil_k_> #topic     Should we move to openstackclient?
14:45:18 <mclaren> out of curiousity who added this one?
14:45:21 <nikhil_k_> #topic  Should we move to openstackclient?
14:45:27 * flaper87 didn't
14:45:30 <nikhil_k_> #topic Should we move to openstackclient?
14:45:33 <bunting> Me
14:45:37 <nikhil_k_> eh
14:45:40 <nikhil_k_> where's the bot
14:45:47 <rosmaita> that topic really doesn't want to change
14:45:54 <bunting> I thought it would be an intresting question, since some of the other services do it
14:45:56 <flaper87> openstack yo, 'sup ?
14:46:00 <jokke_> nikhil_k_: it stuck to the double not loop
14:46:04 <nikhil_k_> :)
14:46:30 <mclaren> So I have a question...
14:46:42 <mclaren> what is the story with clients being deprecated?
14:46:48 <nikhil_k_> bunting: I think this is something a few of us are thinking too
14:46:56 <flaper87> mclaren: clis or libraries ?
14:47:06 <mclaren> Is it that the clients are mainly to me used to provide the libraries but the CLI should be OSC?
14:47:19 <flaper87> mclaren: correct
14:47:23 <mclaren> (OpenStackClient)
14:47:28 <jokke_> I had discussion around OSCli with someone just yesterday or so, let me find my analogy about it
14:47:31 <nikhil_k_> it's a possibility
14:47:45 <mclaren> So what consideration did we give to that when we landed 1.0.0 on the world?
14:48:04 <nikhil_k_> it's a possibility and not a reality yet
14:48:08 <mclaren> (which we're ripping out of our product as we  speak by the way)
14:48:42 <nikhil_k_> what do you mean by product?
14:48:50 <mclaren> sorry, HP thing
14:48:55 <nikhil_k_> ah
14:49:03 <flaper87> I'd personally like glanceclient to be a library
14:49:11 <mclaren> should we be telling users whose scripts we have broken to switch to OSC?
14:49:12 <flaper87> and have a consistent way to do CLIs
14:49:16 <jokke_> it's like deprecating cp, touch, mv, ln, cat, etc.etc.etc. and creating filetools which would be used like `filetools ext4 copy-file-from-to /path/from/somewhere /path/to/somewhere`
14:49:26 <flaper87> Many benefits, from an OpenStack perspective, to it
14:49:30 <nikhil_k_> +1
14:49:38 <flaper87> One of those is not having to do crazy thinks to parse keystone parameters
14:49:51 <flaper87> s/thinks/things/
14:50:01 <jokke_> it's so far from any principal "make one tool for one job" as anything can be
14:50:08 <flaper87> That regardless jokke_'s anology being a bit accurate
14:50:26 <flaper87> However, I don't think it lifts the responsibility from us
14:50:38 <nikhil_k_> Having a single clean API should be a concern at the OpenStack level and operator specificities can be handled at bulk there.
14:50:42 <nikhil_k_> that's true
14:50:43 <nikhil_k_> too*
14:50:49 <flaper87> BUT, it does gives us an opportunity to get the CLI right since I doubt it has a complete implementation
14:51:16 <nikhil_k_> and by OpenStack level I mean, broder community and not a single program
14:51:18 <mclaren> they oppose anything that breaks backwards compatibility (I asked)
14:51:20 <jokke_> """since M$ moved to powershell certain loud folks have started to insist that all-command-line-parameters-are-read-out-for-them and that command are ok to be 497 characters long before user input ... I'm surprised that those folks are not running all their cli command with bash -c thinking that all the commands are just subcommands"""
14:51:30 <flaper87> One of the things I'd love to do, if we ever decide to use osc (which I kinda think we shoud), is to not map the cli 11 w/ the glance api
14:51:52 <mclaren> the OSC folks will make those kinds of decisions
14:51:52 <flaper87> but rather do something that can hypotetically be forward compatible
14:52:15 <flaper87> mclaren: right but thinking that moving to OSC will just remove that work from us is not right
14:52:20 <flaper87> we'll still have to collaborate
14:52:31 <mclaren> yes, Niall is working with them now
14:52:41 <nikhil_k_> I doubt if we will be able to get rid of the CLI completely
14:52:49 <nikhil_k_> at least that's the feedback I have
14:52:59 <flaper87> I hope we won't just move all the patches re v1 from glanceclient to osc :P
14:53:03 <flaper87> mclaren: bunting ^
14:53:06 <bunting> nikhil_k_: We could add deprectaion warnings though
14:53:26 <flaper87> nikhil_k_: if we want to, we can
14:53:31 <flaper87> keystone is doing that, for example
14:53:34 <flaper87> and other projects too
14:53:36 <nikhil_k_> who uses it most is going to be definitive of the standardisation like mentioned above
14:53:37 <nikhil_k_> matching with the API is going to be tricky
14:53:38 <rosmaita> we could add deprecation warnings by default for all commands, then we'd be covered
14:53:40 <mclaren> so if a user comes onto IRC 'image-create' is broken. Do we say switch to OSC or do we say update your glance scripts?
14:53:49 <nikhil_k_> tools like warlock were for such a thing and can be a real pain
14:53:56 <flaper87> I mean, we'll keep the old CLI but we wouldn't update it
14:54:07 <nikhil_k_> I doubt if we can get OS-C getting to implement that
14:54:15 <jokke_> I'd rather like to see OpenStackClient consuming the OpenStackSDK and then we could just abandon the python-glanceclient repo ;)
14:54:38 <nikhil_k_> that is something doesn't seem viable jokke_
14:54:40 <flaper87> mclaren: if it's a bug, I think it'd be fine to fix it for a while
14:54:57 <flaper87> mclaren: just like we did w/ v1
14:55:09 <flaper87> we've committed to maintain the code that has been released
14:55:16 <mclaren> as have OSC
14:55:18 <flaper87> and we have to do so
14:55:28 <flaper87> however, it doesn't mean we have to keep updating it
14:55:49 <flaper87> we can just recommend users to get the latest hotness from osc
14:55:50 <nikhil_k_> btw, folks we've one more item on the agenda
14:55:51 <mclaren> I'm not saying anything about not maintaining the client, I'm just trying to figure out if, as the clients are deprecated we should recommend OSC
14:56:13 <mclaren> for scripting in particular
14:56:22 <flaper87> mclaren: first we have to decide if we want t omigrate to OSC and how we're going to help OSC folks
14:56:22 <mclaren> (it's what devstack uses)
14:56:37 <flaper87> once we've that effort covered, I think we'd be good to say that
14:56:51 <nikhil_k_> mclaren: I doubt if that's becoming a practice yet but seems like the right direction
14:56:58 <flaper87> FWIW, zaqar just uses OSC, no CLI merged in zaqar
14:57:28 <mclaren> Ok, does anyone want to mention any of the priorities that Doug had in his mail?
14:57:54 <nikhil_k_> what do you mean?
14:58:07 <nikhil_k_> by *mention*
14:58:39 <mclaren> Dunno I guess I thought it would be on the agenda
14:58:41 <jokke_> I would ... them all ... if you haven't done so yet, go and read the chain
14:58:47 <nikhil_k_> bunting: seems like you item may have to wait. it was a late addition fwiw.
14:58:47 <flaper87> mclaren: ++
14:58:52 <nikhil_k_> your*
14:59:01 <bunting> nikhil_k_: Yeah, thats fine
14:59:06 <flaper87> jokke_: ++
14:59:34 <nikhil_k_> mention where?
14:59:39 <rosmaita> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074360.html
14:59:55 <flaper87> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/074360.html
14:59:56 <rosmaita> (it's mentioned!)
14:59:58 <flaper87> :P
15:00:06 <mclaren> nice!
15:00:06 <jokke_> ok, we got out of time :(
15:00:26 <nikhil_k_> lol
15:00:34 <nikhil_k_> mentioned! yay!!
15:00:46 <nikhil_k_> thanks all for joining
15:00:49 <mclaren> thanks
15:00:51 <nikhil_k_> #endmeeting