20:00:00 <markwash> #startmeeting glance
20:00:00 <openstack> Meeting started Thu Jan 23 20:00:00 2014 UTC and is due to finish in 60 minutes.  The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:04 <openstack> The meeting name has been set to 'glance'
20:00:12 <markwash> hi glance folks
20:00:13 <arnaud> hi
20:00:42 <markwash> arnaud: o/ :-)
20:01:37 <markwash> rosmaita iccha ameade nikhil__ esheffield flwang flaper87 zhiyan hemanth_
20:01:44 <markwash> highlight time!
20:01:50 <markwash> #topic agenda
20:01:53 <sharwell_> hi everyone :)
20:01:53 <markwash> we're a bit light today
20:02:02 <zhiyan> hi!
20:02:04 <markwash> I myself am just in "get ready for the mini summit" mode
20:02:26 <markwash> so I thought we could just talk about that a bit, if anyone has questions
20:02:29 <rosmaita> i don't know, will hi mark
20:02:38 <rosmaita> i mean "hello"
20:03:00 <markwash> so anyone have any other topics they want to discuss today other than the mini summit?
20:03:39 <sharwell_> i'm up for talking about schemas if you want to, but definitely don't have to if it's not the right time
20:04:21 <markwash> sharwell_: looks like we'll have time
20:04:37 <markwash> last call for suggestions. . .
20:05:14 <markwash> all right
20:05:25 <markwash> #topic mini summit this monday
20:05:41 <markwash> I'm working on the broadcasting angle at the moment
20:05:55 <markwash> I'm trying to pick a solution that can be picked up internationally
20:06:44 <markwash> the plan is for remote participants to be able to watch, but I think we'll just have to have some local participants in IRC who can relay questions and thoughts
20:07:03 <markwash> watch and listen, I mean, of course
20:07:55 <markwash> I'd also love it if anyone who has etherpads for their sessions could provide links
20:08:03 <markwash> not quite sure how to fit that into the wiki page
20:08:23 <markwash> #link https://wiki.openstack.org/wiki/Glance/IcehouseCycleMeetup
20:08:53 <markwash> that's it for updates for me, anyone have questions?
20:10:06 <markwash> #topic open discussion
20:10:13 <ameade> we are lurking btw lol
20:10:23 <markwash> sorry not much content today folks, but we can always just have our time back :-)
20:10:44 <rosmaita> i think sam has some comments about schemas :)
20:10:46 <markwash> sharwell_: wanna talk about schemas here? or if
20:11:00 <sharwell_> or if?
20:11:03 <markwash> sorry
20:11:07 <sharwell_> here is fine for me
20:11:13 <markwash> okay sounds good
20:11:46 <markwash> sharwell_: care to introduce the topic?
20:11:52 <sharwell_> So as rosmaita knows, I've taken particular interest in the introduction of json schemas to this api, along with some of the others
20:13:16 <markwash> sharwell_: I take it you've been trying to use them while writing some client-side tooling? or am I mistaken. .
20:13:51 <sharwell_> what i'd like to accomplish is working towards creating a combination of a schema development strategy and an associated breaking changes policy that meets the requirements of both developers using openstack APIs and the requirement of openstack projects to incorporate extensions, new functionality, and/or customizable portions of the software installation process of individual users
20:14:08 <sharwell_> that ended with "individual users" did the message come through?
20:14:18 <markwash> yes I think so
20:14:27 <sharwell_> thanks
20:15:22 <sharwell_> i believe everyone agrees about the benefits json schema brings to the table regarding communicating the behavior of our apis
20:15:28 <markwash> well
20:15:31 <markwash> maybe :-)
20:15:47 <markwash> I think if we were using them a bit better, we'd get the benefit we were aiming at
20:16:23 <sharwell_> meaning it's ok for me to focus on addressing problems that have been observed without explaining why we're trying to keep it around
20:16:36 <markwash> heh sure
20:17:29 <markwash> I'm curious if you hae some examples of the types of problems
20:17:37 <sharwell_> I believe our target should be including "a valid reference schema" for items found in requests and responses in our API reference.
20:17:47 <rosmaita> i wonder whether the schema fix should be targeted for v3 ?
20:18:14 <rosmaita> because i think we're going to have to have different request/response schemas
20:18:21 <rosmaita> and that's a big change
20:18:22 <sharwell_> The primary challenges are 1) ensuring that the schema is update and 2) ensuring that the schema does not box the project in to the point that it can't be extended to meet customer/company requirements
20:20:08 <markwash> rosmaita: we haven't talked a lot about what v3 might look like, I'm curious if we even want schemas for it in the way we have them today
20:20:20 <markwash> I'm a bit skeptical these days about schemas hosted on the api server
20:20:40 <markwash> publishing static schemas per api minor revision seems quite good still
20:20:50 <sharwell_> schemas hosted on the api server are able to communicate certain infromation that we will never be able to include in the api reference
20:21:05 <rosmaita> i think we need a kind of "vision statement" for what we want the schemas to do
20:21:24 <rosmaita> i've always thought of them as guidelines, not contracts
20:21:29 <rosmaita> but that's just me
20:21:45 <markwash> sharwell_: true.. what kind of killer usecase can you think of for that feature, though?
20:21:49 <sharwell_> for example, the name of an image has a maximum length that is likely configurable as part of the software installation. the api reference wouldn't include a maxLength for this field, but the API could return a schema that does include this property with the current value in effect for that installation
20:22:06 <markwash> okay sure
20:22:58 <sharwell_> in addition, json schema does not prevent you from using properties that lie outside the schema (i.e. objects can include properties that are not validated)
20:23:12 <markwash> another use case that is nice is communicating which properties are allowed on a POST or PATCH, but it is sometimes hard as I don't know a good way to communicate "negative" patterns
20:23:27 <markwash> i.e., a property can be anything except "billing_foo"
20:23:37 <markwash> but I might just be a bit rusty on my jsonschema
20:23:45 <sharwell_> the api reference could omit custom properties, while the api call itself might return information about custom properties
20:24:54 <sharwell_> this fact is the primary reason why i believe you can include authoritative schemas in the api reference without fear of them getting "out of date"
20:26:12 <sharwell_> you would just need to include a message that the server may support properties for objects which are not described by the schema, and the service provider will define the meaning of any such custom properties
20:27:20 <markwash> what exactly does a client do with that kind of schema information though?
20:27:49 <sharwell_> markwash: are you referring to a schema in the api reference, or a schema returned by an api call
20:28:06 <markwash> it can do local validation, but its not clear to me that its a huge win over remote validation. .
20:28:08 <markwash> api call
20:29:54 <markwash> sorry I don't mean to be overly skeptical. . I'm just struggling atm for the vision that rosmaita was talking about
20:30:07 <sharwell_> i'm more concerned today with communicating the meaning of schemas in the api reference. i.e. what long-term guarantees does a client developer have in relation to the schema they read about in the api reference.
20:31:19 <rosmaita> so would it be better to have no shcemas at all?
20:31:34 <rosmaita> rahter than inaccurate ones?
20:32:46 <sharwell_> i believe that by documenting only a required subset of the total set of resource properties, we can ensure that "inaccurate" never happens, while at the same time providing more concrete guarantees than has ever been seen before in OS documentation
20:32:58 <markwash> sharwell_: we aim for 100% backwards compatibility but I wouldn't be surprised if we missed a bit
20:32:58 <markwash> and we don't necessarily do so exclusively in terms of the schema
20:33:00 <sharwell_> or any web api documentation for that matter
20:33:43 <markwash> i.e. if the behavior differs from the schema we might be stuck keeping both for backwards compatibility :-(
20:36:05 <markwash> sharwell_: but in any case, what kind of changes do you have in mind?
20:37:11 <sharwell_> markwash: i'd like to help prepare schemas for the api reference that we can treat as authoritative, and used as a guide for any glance updates made through the icehouse release
20:37:47 <markwash> ooh, with some validation we can try out to prevent regressions?
20:38:46 <sharwell_> i'm not 100% confident, but i believe it is possible to automate a "compatibility analysis" of two schemas to highlight if and where new properties could cause bugs to appear in code that follows the old schema
20:39:22 <sharwell_> this type of analysis falls square within my research interests :)
20:39:51 <markwash> it may also work to run the api schema against the api to verify they match up
20:41:15 <markwash> but in any case, valid schemas for long term supported behavior sounds great
20:41:34 <markwash> I think we can probably sign up for that without any concerns
20:42:10 <markwash> sharwell_: there are sort of two steps in this process, 1) this discussion, 2) writing up a blueprint (which can be brief)
20:42:42 <markwash> do you want to look into #2 and then we can meet up again in 2 weeks to review?
20:42:46 <markwash> or is there already a blueprint?
20:43:02 <markwash> (also if the blueprint is ready faster you can just ping for review in #openstack-glance)
20:43:35 <sharwell_> sure. i'll look into writing a blueprint describing a breaking changes policy for json schemas used by various APIs
20:44:17 <sharwell_> if we define the breaking changes policy, then it becomes easy to ask if a particular schema is likely to cause problems in that context
20:44:35 <markwash> eys
20:44:37 <markwash> yes
20:44:46 <rosmaita> +1
20:45:11 <markwash> I think defining "breaking changes" in a crunchy way we can evaluate more rigorously would be a huge benefit
20:45:23 <markwash> right now, avoiding them is mostly based on gut-feeling
20:45:32 <markwash> which is obviously not a good long term policy
20:46:09 <markwash> if we controlled clients, we could do this quite simply -- we could test all of them
20:46:21 <sharwell_> markwash: that often works, I just think we have some cool tools at our disposal that allows us to do even better
20:46:38 <markwash> sharwell_: +1
20:47:11 <rosmaita> sharwell_: this sounds good, thanks for taking this on
20:47:20 <markwash> yes indeed, thank you
20:47:43 <sharwell_> no problem, i think about these things in my free time anyway
20:47:50 <sharwell_> "free time"
20:49:42 <markwash> :-)
20:49:51 <markwash> all right, seems we're exhausted for today
20:50:48 <markwash> unless anyone has another item, I'll close it out and look forward to seeing many of you next week
20:51:09 <rosmaita> see you next week!
20:52:00 <markwash> #endmeeting