14:01:14 <nikhil> #startmeeting glance drivers
14:01:15 <openstack> Meeting started Tue Sep 22 14:01:14 2015 UTC and is due to finish in 60 minutes.  The chair is nikhil. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:19 <openstack> The meeting name has been set to 'glance_drivers'
14:01:22 <rosmaita> hello
14:01:42 <nikhil> #topic agenda
14:01:50 <nikhil> #link https://etherpad.openstack.org/p/glance-drivers-meeting-agenda
14:01:56 <nikhil> hi rosmaita , good morning
14:02:59 <nikhil> looks like jus two of us
14:03:04 <rosmaita> while we're waiting, i have a quick question ... there's a PS up to change glance tests so that the asserts look like assertWhatever(expected, observerd)
14:03:25 <rosmaita> i was looking at some nova tests, and they all have assertWhatever(observed, expected)
14:03:38 <rosmaita> i'm trying to figure out what's really correct
14:03:49 <flaper87> o/
14:03:55 <rosmaita> i'm assuming we're all using the same testing framework?
14:04:06 <nikhil> yeah
14:04:24 <nikhil> rosmaita the quickest way to know that is using IDE say pyCharm
14:04:28 <rosmaita> that was just the nova tests i was looking at, i wasn't very thorough
14:05:01 <rosmaita> i see, it will enforce for whatever the framework in use is
14:05:15 <nikhil> it won't
14:05:17 <flaper87> or to read the docs :P
14:05:19 <flaper87> http://testtools.readthedocs.org/en/latest/api.html#testtools.TestCase.assertEqual
14:05:20 <nikhil> it will give you hint
14:05:26 <nikhil> there are 3 params, expected, observed, message if I recollect correctly
14:05:57 <rosmaita> flaper87: ty
14:06:18 <rosmaita> it's just seeing so many the other way in nova made me wonder
14:06:22 <nikhil> yeah, IDEs give on the fly docs. try a emacs plugin :)
14:06:41 <flaper87> rosmaita: np :)
14:07:01 <nikhil> I am wondering whoever proposed the agenda topic is here or not?
14:07:06 <rosmaita> i did
14:07:20 <nikhil> Thanks for the email and comment flaper87
14:07:22 <rosmaita> and i am
14:07:25 <nikhil> I see
14:07:26 <flaper87> nikhil: np
14:07:35 <flaper87> I hope it all sounds reasonable
14:07:50 <rosmaita> it does
14:07:54 <flaper87> Since I missed my chance to comment yday (personal mattes), I spent more time thinking about it
14:07:58 <nikhil> yeah, I meant to say thanks for clarification on the thoughts behind the impl and proposal
14:08:12 <nikhil> It makes sense
14:08:54 <nikhil> #topic resolution on the ova lite spec
14:09:00 <rosmaita> my agenda item was just to make sure we're all on the same page, and i guess to ask nikhil to formally give the news
14:09:13 <rosmaita> to the OVA spec people
14:09:26 <rosmaita> though, they have probably seen the writing on the wall
14:09:29 <nikhil> whatever communicated over last 3 mins and hereon
14:09:32 <rosmaita> or on the patch set
14:09:38 <nikhil> ref topic ^
14:10:19 <nikhil> ha, writing on the wall sounds trendy-tious
14:10:34 <rosmaita> it's a biblical reference
14:10:42 <flaper87> rosmaita: :P
14:10:52 <rosmaita> but don't ask me where, i got all my bible knowledge from reading p.g. wodehouse
14:11:16 <flaper87> As stated on the review, I think we should hold off this spec until M
14:11:37 <flaper87> It's unfortunate because I like the feature and it was really close
14:11:49 <flaper87> but now it does feel we're rushing it
14:12:00 <rosmaita> i agree
14:12:04 <flaper87> (just making sure some of this is logged in the meeting records)
14:12:21 <flaper87> #link https://review.openstack.org/#/c/214810/
14:12:25 <flaper87> rosmaita: ++
14:12:26 <nikhil> Thanks, it makes sense.
14:12:44 <nikhil> Let's give them a early mitaka hope
14:13:03 <flaper87> yup, sounds reasonable
14:13:04 <rosmaita> i hope the team working on this will begin immediately after the summit, after the tasks stuff is settled, to get this done
14:13:06 <nikhil> We should hopefully discuss the preapproval process and lite specs next week
14:13:13 <flaper87> rosmaita: ++
14:13:15 <nikhil> then things will be more clear
14:13:34 <nikhil> agreed
14:13:38 <flaper87> They have a chance to expand the implementation and we have a better chance to provide more detailed reviews to have a more robust implementation
14:14:01 <nikhil> should we move to next topic?
14:14:06 <rosmaita> yes, and we all need to be on the same page about failure flows
14:14:25 <nikhil> that's true
14:14:32 <nikhil> failure flows*
14:14:45 <rosmaita> or flow failures?
14:14:54 <flaper87> or flow failures flows
14:15:04 <nikhil> lol
14:15:06 * flaper87 expects an inception joke to come out of this
14:15:32 <nikhil> that can be a name of a open source organization
14:15:56 <rosmaita> would have a cool logo
14:16:13 <nikhil> busted A/C :P
14:16:14 <rosmaita> whatever you call that whirpool thing going down the drain
14:17:02 <rosmaita> nikhil: let's move to next topic
14:17:09 <nikhil> #topic Image upload in public clouds (Doug's DefCore email thread)
14:17:27 <nikhil> I assume you have prepped something rosmaita
14:17:35 <rosmaita> i read through the thread again, specifically about upload
14:18:05 <rosmaita> i want to ask the other drivers here if their impression of the discussion accords with mine, namely
14:18:16 <rosmaita> the end-user facing upload must look the same in all OpenStack clouds
14:18:24 <rosmaita> but, it doesn't have to be the curent upload ... Clint proposed an upload request that returns a URI to upload to, Monty and Doug seem to think that's OK
14:19:02 * dhellmann arrives late
14:19:10 <flaper87> rosmaita: I've been putting lots of thoughts on this lately and I've pinged Stuart and dhellmann to get some feedback
14:19:12 <rosmaita> doug ... excellent timing!
14:19:13 <dhellmann> rosmaita: yes, that's basically what I would like to see
14:19:14 <flaper87> oh, there's dhellmann
14:19:15 <flaper87> :D
14:19:23 <flaper87> So yeah, I believe that's the feedback
14:19:28 <flaper87> it doesn't have to be HTTP
14:19:30 <flaper87> BUT
14:19:58 <flaper87> and this is were I'm very opinionated on: The solution, whatever it is, must not require the user to have any knowledge of where the image is being uploaded.
14:20:02 <flaper87> Lemme rephrase that
14:20:08 <nikhil> The intiail conversation I had with Monty led us to a discoverable aspect to the API
14:20:13 <dhellmann> it would be really useful to frame this discussion in terms of the use cases that need to be supported, to help make it concrete
14:20:17 <nikhil> and there are variations in the understanding
14:20:28 <rosmaita> https://etherpad.openstack.org/p/glance-new-new-up-down-workflow-scratchpad
14:20:32 <nikhil> dhellmann yep, you hit the point
14:20:41 <flaper87> IMHO, the user should not care about the image being uploaded to a third-party server, swift, whatever. From an user perspective, there has to me a simple image-create
14:20:50 <dhellmann> there may be several ways to create images (upload, from existing volumes, etc.) and we might need different APIs for those but as long as each of those different APIs always does its one job consistently that's fine
14:20:51 <flaper87> rosmaita: lol, I also have an etherpad that I was planning to share next week
14:20:53 <flaper87> :P
14:21:01 <rosmaita> lol
14:21:36 <flaper87> https://etherpad.openstack.org/p/glance-upload-mechanism-reloaded
14:21:39 <nikhil> So, the idea should be a thematic API
14:21:43 <nikhil> and not a single API
14:21:57 <nikhil> for example the Image create (includes upload) are two APIs
14:22:00 <nikhil> but a single theme
14:22:00 <dhellmann> nikhil: right, discoverability is important, too. I think mordred's suggestion was that an API endpoint might return instructions for where to upload the image, and that helps with one use case but may not cover all of them
14:22:03 <flaper87> One thing thing is that etherpad already contains some implementation details
14:22:12 <dhellmann> so I would like to document all of the use cases before we design any new APIs
14:22:22 <flaper87> rosmaita: Can we have a pre-summit working session?
14:22:26 <flaper87> nikhil: ^
14:22:30 <nikhil> I would like to rephrase that dhellmann if you don't mind
14:22:34 <rosmaita> flaper87: i think we will have to
14:22:37 <flaper87> I think it'd be super useful to have a meeting to brainstorm
14:22:54 <nikhil> we should consider SuperUser use cases and try to account for maintainability overhear for other users
14:22:55 <flaper87> and come up with a solution to this issues that won't be an issue for others
14:23:03 <flaper87> and likely, what's in my etherpad is not it
14:23:06 <nikhil> quote and unquote
14:23:07 <flaper87> but it does give an idea
14:23:19 <nikhil> flaper87 +1
14:23:36 <flaper87> DefCore, cloud-users, admins
14:23:51 <flaper87> That's normally the other I apply when figuring out if something may or may not be good
14:23:54 <dhellmann> flaper87: swift users, ceph users, small deployments with neither
14:23:55 <flaper87> (left to right)
14:23:57 <nikhil> I think admins is a overloaded word in some cases
14:24:19 <nikhil> but I know what you mean by it
14:24:32 <rosmaita> one thing to keep in mind is that the tasks api was designed for import/export/cloning
14:24:34 <flaper87> nikhil: ops is probably more accurate
14:24:42 <flaper87> cloud-admins ?
14:24:47 <flaper87> mmh, well, you get my point
14:24:47 <rosmaita> i don't think we should consider upload in isolation
14:24:48 <nikhil> possibly admins == deployers, operations (maintainers) and admisistrators (auditos etc)
14:24:49 <flaper87> :P
14:25:20 <nikhil> rosmaita yep, that's a great point
14:25:30 <flaper87> I'd probably replace admins with inter-cloud use cases since that covers other services talking to Glance too
14:25:32 <dhellmann> rosmaita: exactly, we need to consider all of the use cases
14:25:34 <nikhil> so, two things I would like to say right up front
14:25:47 <rosmaita> looking quickly through flaper87 's etherpad, looks a lot like the tasks api
14:26:02 <rosmaita> i will shut up and let nikhil speak
14:26:12 <nikhil> 1. making massive changes to the image related code is a big risk (sec, maintainibility, etc wise)
14:26:28 <flaper87> rosmaita: well, the difference is that it does not require the user to trigger a task but Glance does it once the image bits are uploaded. My wording may not be fair to the original idea
14:26:37 <flaper87> but I'm happy to elaborate/explain
14:26:38 <nikhil> 2. task-workflow original use case for the exposure to public cloud
14:27:22 <nikhil> as images had slowly evolved into them as we made things public, intitial design never considered such stringent requirements from DefCore, API_WG, PRD_WG etc
14:27:30 <dhellmann> I want to be sure it's clear that the problem with the task workflow is not that it is task-based, but that the API requires the user to know about the task without being able to discover it. Having an API endpoint that starts a background task is fine.
14:27:31 <flaper87> I still think we should hide tasks from public usage since they have not been implemented in an interoperable way.
14:27:56 <rosmaita> flaper87: or we implement them in an interoperable way
14:28:10 <nikhil> tasks in bacjground challenge the immutability and transparency clause for images
14:28:28 <flaper87> nikhil: re #1: Agreed, the proposed solution on my etherpad (again it's just an idea thrown out there) takes care of not breaking the existing API/upload for users
14:28:28 <nikhil> it can possibly violate the image verification and assurance for the users
14:28:28 <rosmaita> the nice thing about the import task is that you don't create an image until there's a reasonable expectation that it is actually an image
14:28:30 <dhellmann> but any deep discussion of implementation details is really premature until we have a complete documented list of the requirements, somewhere other than the mailing list archives
14:28:37 <flaper87> dhellmann: ++
14:28:52 <nikhil> agreed
14:28:59 * flaper87 wonders where's mclaren when we need him
14:29:02 <flaper87> :P
14:29:11 <dhellmann> rosmaita: that sounds like a useful feature to incorporate into the requirements
14:29:16 <nikhil> It would nice to document the constraints, use cases, maintainability overhead of the changes
14:29:22 <dhellmann> nikhil: ++
14:29:31 <dhellmann> this seems like a great use of the specs process
14:29:39 <nikhil> ++
14:29:55 <rosmaita> dhellmann: have you seen this: https://wiki.openstack.org/wiki/Glance-tasks-api-product
14:30:18 <dhellmann> rosmaita: no, but it's on my reading list now
14:30:23 <nikhil> we are out of time so as a courtesy towards this channel we can continue the discussion on -glance if we awnt
14:30:37 <nikhil> thanks all for joining!
14:30:41 <flaper87> o/
14:30:46 <nikhil> #endmeeting