14:02:20 #startmeeting glance_artifacts_sub_team 14:02:21 Meeting started Mon Dec 14 14:02:20 2015 UTC and is due to finish in 60 minutes. The chair is nikhil_k. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:26 The meeting name has been set to 'glance_artifacts_sub_team' 14:02:26 o/ 14:02:33 \o 14:02:38 #chair ativelkov nikhil 14:02:39 Warning: Nick not in channel: nikhil 14:02:40 Current chairs: ativelkov nikhil nikhil_k 14:03:02 welcome everyone 14:03:04 o/ 14:03:05 o/ 14:03:05 hi folks 14:03:09 #topic agenda 14:03:11 nikhil: were you playing musical chairs just there? 14:03:26 sigmavirus24: haha, something like that :) 14:03:36 we've some items on agenda today 14:03:40 #link https://etherpad.openstack.org/p/glance-artifacts-sub-team-meeting-agenda 14:04:09 let's get started 14:04:22 #topic Glance v3 -> Glare v0.1 Migration 14:04:30 So, we have a patch for GlanceV3 -> Glave v0.1 migration 14:04:39 #link https://review.openstack.org/#/c/254163/ 14:04:52 The patch is technically ready, but it fails a grenade test 14:05:43 This happens because liberty glance has a v3 reference in its glance-api-paste.ini 14:05:57 o/ 14:06:02 ah 14:06:13 I've removed it in Mitaka, so liberty's paste.ini becomes invalid in Mitaka 14:06:31 and Grenade assumes that release N should be able to work on N-1 configs 14:06:44 um 14:06:49 Theoretically there may be exceptions in this rule 14:07:09 And I believe that removing an experimental API is a good example of such exception 14:07:16 maybe we can leave v3 api, but make it stub 14:07:17 indeed 14:07:37 I mean v3 endpoint still will be there 14:07:41 So, yeah, there are two options 14:07:45 but there will be warning message 14:08:05 either leave a code to handle the apiv3app paste section 14:08:15 where it's said that v3 is not supported and please use glare instead 14:08:27 or make a patch to grenade to remove that section from the paste 14:08:40 ativelkov: or have the v3 endpoint 301 to the v0.1 endpoint? 14:08:53 A little more code but also a bit more friendly to API consumers as well 14:09:02 because many vendors curse us for doing that :) 14:09:09 sigmavirus24: may be an option, yes 14:09:21 mfedosin: my idea? 14:09:52 sigmavirus24: I believe mfedosin means about the same as you do 14:09:55 But yeah, that will be a problem until we can figure out how to remove the section anyway. Next cycle won't be any easier if it wants glance to use Mitaka's 14:10:06 sigmavirus24: yes kind of 14:10:11 ativelkov: yeah, makes sense 14:10:35 sigmavirus24: no, next cycle will be better! 14:10:42 ativelkov: will it? 14:10:48 * sigmavirus24 is maybe missing something 14:10:49 wel'll remove the apiv3app section from mitaks's paste.ini 14:11:04 okay 14:11:09 * sigmavirus24 trusts you ativelkov :) 14:11:14 ativelkov: will be better than the cycle after the next one? 14:11:18 * sigmavirus24 also only woke up 30 min ago 14:11:31 but we will leave the " glance.api.v3.router:API.factory" code module 14:11:44 this is the module referenced in Liberty's paste.ini 14:12:00 and this module will return the 301 you speak about 14:12:25 so, new Mitaka's deployment will have no hint of /v3 in glance-api 14:12:57 upgrades from Liberty to Mitaka will work but will return 301 if /v3 is accessed 14:13:11 So, this should work 14:13:40 OK, I'll update this patch today then 14:13:55 :D 14:13:58 #agreed to leave a /v3 stub to return a 301 for Liberty->mitaka upgrades 14:14:16 makes sense 14:14:30 Another question is the version prefix for Glare 14:14:35 cool :) 14:14:45 right now in glance we have a v{major} prefix 14:14:52 i.e. we have /v2/images 14:14:56 Right 14:15:05 since glare is experimental, it should be v0.x 14:15:08 v0.1? 14:15:16 yup, v0.1 currently 14:15:19 ativelkov: if it's any consolation Keystone went from /v2.0 to /v3 14:15:22 yes, only major 14:15:40 So it's not unheard of for APIs to have versioning that is not consistent (although it's not ideal, which i assume is your point) 14:15:41 so, what should be the prefix in this case? /v0/artifacts or /v0.1/artifacts? 14:16:04 ativelkov: why not just v1 ? 14:16:05 ativelkov: so I think jaypipes has argued against v0 in the past 14:16:14 v-1 :) 14:16:19 nikhil: isn't v1 deprecated? 14:16:21 :P 14:16:26 glare v1 :) 14:16:28 nikhil: if v1 is deprecated, why are we adding features to it now 14:16:30 not glance v1 14:16:35 no, v1 is bad 14:16:36 oh true 14:16:39 different port 14:16:44 * sigmavirus24 is still tired 14:16:47 sorry again 14:16:54 it's an experimental api 14:16:59 it will be a separate in keystone one so don't think a problem exists 14:17:28 I think we can propose v1 and see if there's any pushback 14:17:31 hmm.. but the real version of this API is not v1 14:17:38 rather than assuming worse 14:17:58 ativelkov: oh? 14:18:03 nikhil: so, you are proposing to keep developing v0.x, but host it under the v1 prefix? 14:18:12 maybe just "vx" - which means eXperimental 14:18:13 Idk, I like v0.1 to be consistent with our more recent messaging but I don't feel strongly 14:18:24 mfedosin: eh 14:18:52 nikhil: we are going to address the API-WG and defcore concerns (there is a spec for that already), and it will be a breaking change in glare API 14:18:59 sigmavirus24: I just like X-men comics 14:19:27 mfedosin: I do too! 14:19:47 ativelkov: I doubt if this should fall in the realm of api version name considerations from those groups 14:20:06 so, I'd prfer the current API to be called v0.1, have the next version (based on the https://review.openstack.org/#/c/254710/ spec) set to 0.2, and once the API is stable, renabme it to 1.0 14:20:10 mostly because we said it's experimental 14:20:17 nikhil: ativelkov if we're going to break it after mitaka, I'd rather see it as v0.1 honestly 14:20:28 sigmavirus24: ++ 14:20:29 nikhil: what we say, and what people do, do not often match 14:20:31 sigmavirus24: that's true 14:20:40 both :) 14:20:47 ok, I don't mind v0.1 14:20:59 just feels a bit weird 14:21:09 going back to that version after one year 14:21:13 so, the prefix should it be v0 or v0.1? 14:21:45 well, it may be v0.94 to reflect the long history of this thing :)) 14:21:58 #startvote should prefix be v0 or v0.1? 0, 0.1, NA 14:21:59 Begin voting on: should prefix be v0 or v0.1? Valid vote options are 0, 0, 1, NA. 14:22:00 Vote using '#vote OPTION'. Only your last vote counts. 14:22:34 #endvote 14:22:35 It does not have proper voting options 14:22:35 Voted on "should prefix be v0 or v0.1?" Results are 14:22:41 #startvote should prefix be v0 or v0.1? 0, 0-1, NA 14:22:42 Begin voting on: should prefix be v0 or v0.1? Valid vote options are 0, 0-1, NA. 14:22:43 Vote using '#vote OPTION'. Only your last vote counts. 14:22:47 I think in this case 0.1 is preferable 14:22:53 #vote 0-1 14:22:55 # vote 0-1 14:23:00 #vote 0-1 14:23:18 because there may be huge differences between 0.1 and 0.2 14:23:18 #vote NA 14:23:24 #vote 0-1 14:23:41 sigmavirus24: wanna vote or leaving be? 14:23:42 #vote 0-1 14:23:47 thanks 14:23:51 you're welcome 14:23:51 #endvote 14:23:52 Voted on "should prefix be v0 or v0.1?" Results are 14:23:53 NA (1): nikhil 14:23:55 0-1 (4): mfedosin, sigmavirus24, kairat, ativelkov 14:24:11 #agreed prefix be v0.1 14:24:11 #agreed to have version prefix as /v0.1/artifacts 14:24:22 :) 14:24:34 ok, we've a few mins left 14:24:44 is there anything more important on this topic? 14:24:52 OK, and just as a reminder: I have written a spec for the public API, addressing API-WG and DefCore concerns 14:24:56 #link https://review.openstack.org/#/c/254710/ 14:25:00 anymore important things* 14:25:16 ativelkov: when a spec about plugins will be published? 14:25:19 #topic Public API spec on review 14:25:26 #link https://review.openstack.org/#/c/254710/ 14:25:39 I just wanted some initial comments from the Glance team on this before I send an email to API-WG ML 14:26:06 mfedosin: what do you mean by "spec about plugins"? 14:26:23 oslo.vo 14:26:29 and other stuff 14:26:35 will glare support it? 14:27:16 mfedosin: that's a different story. It will, but I don't want to push with it. We need to agree upon the API. o.vo and other stuff are implementation details 14:28:00 There will be two sets of API: the public one (i.e. plugin-independent, to complu with defcore's reqs) and the internal one (plugin-driven) 14:28:08 the public one is covered with the spec 14:28:14 I would love to hear more on this 14:28:31 nikhil: we are almost out of time, we may proceed in #glance 14:28:40 what do people think of having a video session for one hour instead of the meeting next week? 14:28:47 yes, but what about the lower part of the iceberg 14:28:56 nikhil: I like the idea 14:29:08 thanks ativelkov 14:29:12 don't mind 14:29:21 seems like we've a good number of items to discuss 14:29:31 nikhil: I won't be around so ¯\_(ツ)_/¯ 14:29:32 and we have the meeting time set on schedule 14:29:37 oh 14:29:46 ok, then let me setup a doodle 14:29:55 sigmavirus24: not sure if it's vacay? 14:30:09 Let's continue the other convo on -glance 14:30:11 doodle will be nice, thanks nikhil 14:30:22 nikhil: it is vacation 14:30:32 I've been taking all of my vacation at the end of the year :P 14:30:34 ativelkov: cool 14:30:39 we are out of time 14:30:44 sigmavirus24: haha, nice. happy vacation 14:30:49 Thanks everyone 14:30:51 okay. thanks everyone! 14:30:54 thanks! 14:30:58 #endmeeting