Tuesday, 2015-02-03

*** annashen has joined #openstack-glance00:04
*** annegent_ has quit IRC00:07
*** EmilienM is now known as EmilienM|afk00:11
*** TravT has quit IRC00:14
*** TravT has joined #openstack-glance00:15
*** TravT has quit IRC00:27
*** annegent_ has joined #openstack-glance00:30
*** TravT has joined #openstack-glance00:31
*** annegent_ has quit IRC00:38
*** cpallares has quit IRC00:39
*** chipmanc has joined #openstack-glance00:41
*** nellysmitt has joined #openstack-glance00:55
*** annashen has quit IRC01:00
*** nellysmitt has quit IRC01:00
*** junhongl__ has quit IRC01:00
*** jwang has joined #openstack-glance01:01
*** takedakn has joined #openstack-glance01:02
*** zhiyan has quit IRC01:10
*** briancurtin has quit IRC01:11
*** ameade has quit IRC01:11
*** junhongl__ has joined #openstack-glance01:17
*** briancurtin has joined #openstack-glance01:18
*** zhiyan has joined #openstack-glance01:21
*** ameade has joined #openstack-glance01:21
*** 21WAA8C7O has joined #openstack-glance01:32
*** sigmavirus24_awa is now known as sigmavirus2401:36
*** ericpete_ has quit IRC01:36
*** TravT has quit IRC01:36
*** diegows has quit IRC01:47
*** takedakn has quit IRC01:58
*** Longgeek has joined #openstack-glance02:12
*** Longgeek has quit IRC02:13
*** Longgeek has joined #openstack-glance02:15
*** ericpeterson has joined #openstack-glance02:41
*** nellysmitt has joined #openstack-glance02:56
*** nellysmitt has quit IRC03:01
*** chipmanc has quit IRC03:04
*** chipmanc has joined #openstack-glance03:09
*** ericpeterson has quit IRC03:20
*** flwang has quit IRC03:24
*** flwang has joined #openstack-glance03:35
*** bkopilov has quit IRC03:37
*** jyoti-ranjan has joined #openstack-glance03:42
*** Longgeek has quit IRC03:59
*** cchipman has joined #openstack-glance04:00
*** chipmanc has quit IRC04:01
*** annashen has joined #openstack-glance04:02
*** Longgeek has joined #openstack-glance04:04
*** Longgeek has quit IRC04:05
*** harlowja has quit IRC04:08
*** flwang has quit IRC04:09
*** Longgeek has joined #openstack-glance04:09
openstackgerritSteve Lewis proposed openstack/glance: Rewrite SSL tests  https://review.openstack.org/14840004:12
*** Longgeek has quit IRC04:17
*** Longgeek has joined #openstack-glance04:17
*** Longgeek has quit IRC04:18
*** ivasilevskaya1 has quit IRC04:18
*** ivasilevskaya has joined #openstack-glance04:21
*** TravT has joined #openstack-glance04:25
*** TravT_ has joined #openstack-glance04:29
*** sigmavirus24 is now known as sigmavirus24_awa04:30
*** TravT has quit IRC04:30
*** cchipman has quit IRC04:41
*** hollandais has quit IRC04:47
*** Longgeek has joined #openstack-glance04:50
*** annashen has quit IRC04:52
*** hollandais has joined #openstack-glance04:52
*** nellysmitt has joined #openstack-glance04:57
*** nellysmitt has quit IRC05:02
*** ozialien has quit IRC05:07
*** bkopilov has joined #openstack-glance05:10
*** takedakn has joined #openstack-glance05:15
*** takedakn has quit IRC05:24
*** echevemaster has quit IRC05:27
*** takedakn has joined #openstack-glance05:30
*** takedakn has quit IRC05:31
*** annashen has joined #openstack-glance05:38
*** TravT has joined #openstack-glance05:45
*** TravT_ has quit IRC05:47
*** TravT_ has joined #openstack-glance05:48
*** TravT has quit IRC05:49
*** rwsu is now known as rwsu-afk05:51
*** spzala has quit IRC06:02
openstackgerritOpenStack Proposal Bot proposed openstack/glance: Imported Translations from Transifex  https://review.openstack.org/14676506:03
*** annashen has quit IRC06:14
*** Longgeek has quit IRC06:16
*** Longgeek has joined #openstack-glance06:16
*** Longgeek has quit IRC06:17
*** annashen has joined #openstack-glance06:19
*** nlevinki has joined #openstack-glance06:32
*** nellysmitt has joined #openstack-glance06:58
*** nellysmitt has quit IRC07:03
*** groen692 has joined #openstack-glance07:15
*** annashen has quit IRC07:26
*** takedakn has joined #openstack-glance07:27
*** takedakn has quit IRC07:29
*** takedakn has joined #openstack-glance07:30
*** takedakn has quit IRC07:34
openstackgerritRajesh Tailor proposed openstack/glance: Handle location URLs that 404 in create-image  https://review.openstack.org/13751507:49
*** TravT_ has quit IRC07:50
*** TravT has joined #openstack-glance07:51
*** TravT has quit IRC07:51
*** TravT has joined #openstack-glance07:52
*** TravT has quit IRC07:52
*** TravT has joined #openstack-glance07:54
*** TravT has quit IRC07:54
*** TravT has joined #openstack-glance07:55
*** TravT has quit IRC07:55
*** TravT has joined #openstack-glance07:55
*** TravT has quit IRC07:55
*** chlong has quit IRC07:56
*** TravT has joined #openstack-glance07:56
*** TravT has quit IRC07:56
*** TravT has joined #openstack-glance07:57
*** TravT has quit IRC07:58
*** tshefi has joined #openstack-glance07:58
*** TravT has joined #openstack-glance08:00
*** TravT has quit IRC08:00
*** TravT has joined #openstack-glance08:01
*** TravT has quit IRC08:01
*** TravT has joined #openstack-glance08:02
*** TravT has quit IRC08:02
*** TravT has joined #openstack-glance08:03
*** TravT has quit IRC08:03
*** TravT has joined #openstack-glance08:04
*** TravT has quit IRC08:04
*** TravT has joined #openstack-glance08:04
*** TravT has quit IRC08:05
*** jyoti-ranjan has quit IRC08:05
*** belmoreira has joined #openstack-glance08:05
*** TravT has joined #openstack-glance08:05
*** TravT has quit IRC08:05
*** TravT has joined #openstack-glance08:06
*** TravT has quit IRC08:06
*** TravT has joined #openstack-glance08:07
*** TravT has quit IRC08:07
*** TravT has joined #openstack-glance08:08
*** TravT has quit IRC08:08
*** TravT has joined #openstack-glance08:09
*** TravT has quit IRC08:09
*** TravT has joined #openstack-glance08:10
*** TravT has quit IRC08:10
*** TravT has joined #openstack-glance08:11
*** TravT has quit IRC08:11
*** TravT has joined #openstack-glance08:12
*** TravT has quit IRC08:12
*** sgotliv has joined #openstack-glance08:12
*** TravT has joined #openstack-glance08:13
*** TravT has quit IRC08:13
*** TravT has joined #openstack-glance08:14
*** TravT has quit IRC08:14
*** jyoti-ranjan has joined #openstack-glance08:15
*** TravT has joined #openstack-glance08:15
*** TravT has quit IRC08:15
*** TravT has joined #openstack-glance08:15
*** TravT has quit IRC08:16
*** TravT has joined #openstack-glance08:16
*** TravT has quit IRC08:16
*** TravT has joined #openstack-glance08:17
*** TravT has quit IRC08:17
*** TravT has joined #openstack-glance08:18
*** TravT has quit IRC08:18
*** TravT has joined #openstack-glance08:19
*** TravT has quit IRC08:19
*** TravT has joined #openstack-glance08:20
*** TravT has quit IRC08:20
*** TravT has joined #openstack-glance08:21
*** TravT has quit IRC08:21
*** TravT has joined #openstack-glance08:22
*** TravT has quit IRC08:22
*** TravT has joined #openstack-glance08:23
*** TravT has quit IRC08:23
*** TravT has joined #openstack-glance08:24
*** nellysmitt has joined #openstack-glance08:24
*** TravT has quit IRC08:24
*** TravT has joined #openstack-glance08:25
*** TravT has quit IRC08:25
*** TravT has joined #openstack-glance08:26
*** TravT has quit IRC08:26
*** TravT has joined #openstack-glance08:27
*** TravT has quit IRC08:27
*** TravT has joined #openstack-glance08:28
*** TravT has quit IRC08:28
*** flwang has joined #openstack-glance08:29
*** TravT has joined #openstack-glance08:29
*** TravT has quit IRC08:29
*** TravT has joined #openstack-glance08:30
*** TravT has quit IRC08:30
*** TravT has joined #openstack-glance08:30
*** TravT has quit IRC08:30
*** TravT has joined #openstack-glance08:31
*** TravT has quit IRC08:31
*** TravT has joined #openstack-glance08:32
*** TravT has quit IRC08:32
*** TravT has joined #openstack-glance08:34
*** TravT has quit IRC08:34
*** TravT has joined #openstack-glance08:35
*** TravT has quit IRC08:35
*** TravT has joined #openstack-glance08:35
*** TravT has quit IRC08:36
*** TravT has joined #openstack-glance08:36
*** TravT has quit IRC08:37
*** TravT has joined #openstack-glance08:38
*** TravT has quit IRC08:38
*** TravT has joined #openstack-glance08:39
*** TravT has quit IRC08:39
*** TravT has joined #openstack-glance08:40
*** TravT has quit IRC08:40
*** TravT has joined #openstack-glance08:41
*** TravT has quit IRC08:41
*** TravT has joined #openstack-glance08:42
*** TravT has quit IRC08:42
*** TravT has joined #openstack-glance08:42
*** TravT has quit IRC08:43
*** TravT has joined #openstack-glance08:45
*** TravT has quit IRC08:45
*** TravT has joined #openstack-glance08:45
*** TravT has quit IRC08:46
*** TravT has joined #openstack-glance08:47
*** TravT has quit IRC08:47
*** TravT has joined #openstack-glance08:49
*** TravT has quit IRC08:49
*** TravT has joined #openstack-glance08:50
*** TravT has quit IRC08:50
*** TravT has joined #openstack-glance08:51
*** TravT has quit IRC08:51
*** TravT has joined #openstack-glance08:52
*** TravT has quit IRC08:52
*** TravT has joined #openstack-glance08:52
*** TravT has quit IRC08:53
*** TravT has joined #openstack-glance08:53
*** jistr has joined #openstack-glance08:58
openstackgerritKamil Rykowski proposed openstack/glance: Notifications for metadefinition resources  https://review.openstack.org/14854609:01
*** markus_z has joined #openstack-glance09:14
kragnizsigmavirus24_awa: nikhil_k that math is not correct, since the sleep only takes place on the store retries, not the swiftclient retries09:14
*** junhongl__ is now known as junhongl09:18
junhonglsigmavirus24_awa: Hi Ian, do you have any plan to implement https://blueprints.launchpad.net/glance/+spec/migrate-replicator-to-requests09:19
junhonglsigmavirus24_awa: The https support in glance-replicator.09:19
*** MattMan has quit IRC09:19
junhonglsigmavirus24_awa: I appreciate if you can share with me any progress or tell me anything i can help to implement this in early future, the sooner the better. :)09:21
*** pdb has joined #openstack-glance09:25
*** krykowski has joined #openstack-glance09:26
flwangjunhongl: why don't you submit a spec to take it? :)09:28
flwangjunhongl: you can collaborate with sigmavirus24_awa09:28
*** jyoti-ranjan has quit IRC09:31
*** eglynn has joined #openstack-glance09:34
junhonglflwang: i saw sigmavirus24_awa has already take it, so would like to know his idea, :)09:39
junhonglflwany: sure, i would like to cowork with him, hah09:39
flwangjunhongl: i think it's easy to implement, since requests can support https perfectly09:39
junhonglflwang: yep, i think so.09:40
*** MattMan has joined #openstack-glance09:45
*** krykowski has quit IRC09:48
*** krykowski has joined #openstack-glance10:16
*** nellysmitt has quit IRC10:50
*** krykowski has quit IRC10:50
*** aix has joined #openstack-glance10:51
*** krykowski has joined #openstack-glance10:58
*** 21WAA8C7O has quit IRC11:04
*** krykowski has quit IRC11:06
*** groen692 has quit IRC11:14
*** groen692 has joined #openstack-glance11:16
*** jistr has quit IRC11:21
*** aix has quit IRC11:27
*** jistr has joined #openstack-glance11:27
*** aix has joined #openstack-glance11:28
*** jyoti-ranjan has joined #openstack-glance11:43
*** diegows has joined #openstack-glance11:44
*** chlong has joined #openstack-glance12:06
*** EmilienM|afk is now known as EmilienM12:08
openstackgerritAbhishek Kekane proposed openstack/glance: Zero downtime configuration reload  https://review.openstack.org/12218112:18
*** boris-42 has quit IRC12:22
*** boris-42 has joined #openstack-glance12:22
*** aix has quit IRC12:24
*** Longgeek has joined #openstack-glance12:29
*** cpallares has joined #openstack-glance12:30
*** jyoti-ranjan has quit IRC12:31
cpallaresflaper87: you around?12:31
*** Longgeek has quit IRC12:33
*** aix has joined #openstack-glance12:37
*** TravT_ has joined #openstack-glance12:38
flaper87cpallares: yo :D12:39
*** TravT has quit IRC12:41
*** diegows has quit IRC12:50
*** alex_xu_ has joined #openstack-glance12:53
*** belmorei_ has joined #openstack-glance12:54
*** belmoreira has quit IRC12:55
*** g4rg4m3|_ has joined #openstack-glance12:57
*** flwang has quit IRC12:57
*** jasondotstar has quit IRC12:57
*** alex_xu has quit IRC12:57
*** flwang has joined #openstack-glance12:57
openstackgerritRakesh H S proposed openstack/python-glanceclient: return 130 for keyboard interrupt  https://review.openstack.org/12393413:02
openstackgerritRakesh H S proposed openstack/python-glanceclient: Use utils.exit rather than print+sys.exit  https://review.openstack.org/13025613:02
*** diegows has joined #openstack-glance13:08
*** eglynn is now known as eglynn-sick13:10
*** belmorei_ has quit IRC13:11
*** jyoti-ranjan has joined #openstack-glance13:21
*** eglynn-sick has quit IRC13:24
*** eglynn-sick has joined #openstack-glance13:24
*** jasondotstar has joined #openstack-glance13:28
*** bkopilov has quit IRC13:32
*** Longgeek has joined #openstack-glance13:35
*** Longgeek has quit IRC13:54
*** mjturek has joined #openstack-glance14:01
*** sgotliv has quit IRC14:01
*** tellesnobrega has quit IRC14:01
*** eglynn-sick has quit IRC14:02
*** eglynn has joined #openstack-glance14:02
*** annegentle has joined #openstack-glance14:05
*** jasondotstar has quit IRC14:08
*** sgotliv has joined #openstack-glance14:10
*** spzala has joined #openstack-glance14:13
openstackgerritYusuke Ide proposed openstack/glance: Add detail description image_cache_max_size  https://review.openstack.org/15252314:14
*** jasondotstar has joined #openstack-glance14:20
*** jyoti-ranjan has quit IRC14:30
*** boris-42 has quit IRC14:32
*** changbl has quit IRC14:35
*** jgrimm is now known as zz_jgrimm14:42
*** Longgeek has joined #openstack-glance14:51
*** eglynn has quit IRC14:53
*** eglynn has joined #openstack-glance14:54
*** eglynn has quit IRC14:59
*** eglynn has joined #openstack-glance14:59
*** nlevinki_ has joined #openstack-glance15:00
*** nlevinki has quit IRC15:02
*** krykowski has joined #openstack-glance15:05
*** sigmavirus24_awa is now known as sigmavirus2415:08
sigmavirus24junhongl: yeah I've been busy but I'll prioritize that for today unless you have it mostly working15:09
sigmavirus24In which case I can update the spec to assign you as the sole worker15:09
*** Longgeek has quit IRC15:11
*** eglynn has quit IRC15:12
*** eglynn has joined #openstack-glance15:13
*** vijendar has joined #openstack-glance15:14
*** haomaiwang has joined #openstack-glance15:14
openstackgerritMerged openstack/glance_store: Remove retry on failed uploads to VMware datastore  https://review.openstack.org/14951515:14
openstackgerritMerged openstack/glance_store: Rename oslo.concurrency to oslo_concurrency  https://review.openstack.org/14463115:16
openstackgerritMerged openstack/glance_store: Add needed extra space to error message  https://review.openstack.org/14615215:16
*** haomaiwang has quit IRC15:19
openstackgerritMerged openstack/glance_store: Use testr directly from tox  https://review.openstack.org/14180915:25
*** haomaiwang has joined #openstack-glance15:25
sigmavirus24kragniz: did you update the review with the correct math?15:26
*** nellysmitt has joined #openstack-glance15:27
*** ericpeterson has joined #openstack-glance15:27
*** tellesnobrega has joined #openstack-glance15:28
markus_zIf a glanceclient core member could have a look at the 3x+1 review https://review.openstack.org/#/c/133632/ that would be great.15:29
markus_zIt's plain documentation, no code.15:29
*** TravT_ has quit IRC15:31
*** bkopilov has joined #openstack-glance15:34
ndoneganHi, using glance-replicator in anger locally, and ran into a whole load of, mostly small, show stoppers.15:35
*** peristeri has joined #openstack-glance15:35
ndoneganAll fixed in a local fork of glance-replicator from Icehouse, but I'd prefer not to be maintining a fork :)15:35
ndoneganFor pushing upstrem, should I really be making sure the bug fixes work on Juno/Trunk?15:36
kragnizsigmavirus24: no, I'll post comments on what the times should be15:39
sigmavirus24kragniz: fwiw, those numbers didn't sound right, but I figured I wanted to point them out in case they were =P15:40
sigmavirus24ndonegan: yes. You should be pushing them to trunk aka kilo15:40
sigmavirus24if they're acceptable, we can backport them to icehouse and/or juno15:41
kragnizsigmavirus24: it should be ~56 seconds, not 192 days :P15:41
sigmavirus24right15:41
sigmavirus24that's just the first 5 numbers then.15:41
ndonegansigmavirus24: Time to spin up a more up to date devstack for myself so.15:41
*** zz_jgrimm is now known as jgrimm15:41
sigmavirus24ndonegan:15:43
sigmavirus24*yes sounds like you do :)15:44
*** krykowski has quit IRC15:44
*** krykowski_ has joined #openstack-glance15:44
*** haomaiwang has quit IRC15:45
ndoneganFor various reasons, don't ask, work is still aiming at Icehouse. However, the fixes in question still apply to Kilo/Trunk.15:45
*** thangp has joined #openstack-glance15:50
*** diegows_ has joined #openstack-glance15:53
sigmavirus24ndonegan: yeah, I know of places still running Grizzly so there's no judgment from me :D15:57
*** diegows has quit IRC15:57
nikhil_kjcook: around?16:00
*** belmoreira has joined #openstack-glance16:00
nikhil_kjcook: flaper87 : we need to talk about https://review.openstack.org/#/q/topic:bp/replace-snet-config-with-endpoint-config,n,z16:01
nikhil_kflaper87: that is a very rackspace specific things16:02
nikhil_kthing*16:02
nikhil_kjcook: can probably add a note in the commit message and in the documentation/config (for the new one as well) that it continues to be16:02
nikhil_kplus, I agree with flaper87 that it needs a deprecation path16:03
jcooknikhil_k: yeah I'm here16:04
nikhil_kcool16:04
nikhil_kjcook: https://review.openstack.org/#/c/139726/816:04
kragnizsigmavirus24: commented16:05
kragnizsigmavirus24: tell me if I'm being crazy16:05
jcooknikhil_k: one min in meeting16:05
nikhil_kjcook: ok, I've added some comments here too https://review.openstack.org/#/c/150144/16:06
*** annegentle has quit IRC16:08
*** dkingshott has joined #openstack-glance16:11
*** TravT has joined #openstack-glance16:13
*** diegows has joined #openstack-glance16:14
flaper87nikhil_k: jcook here now if you want to talk16:14
flaper87I replied to jokke_'s comment16:15
flaper87damn, I hate jokke_ for leaving this channel and breaking my irc auto-completion16:15
nikhil_klol16:16
nikhil_kflaper87: we're in a meeting, join you in 516:16
flaper87kk16:17
kragnizflaper87: did you have a look at the spec for that store patch?16:17
kragnizflaper87: that's where all the cool kids put their -1s :P16:17
*** groen692 has quit IRC16:18
flaper87kragniz: the spec was merged and I unfortunatelly got late to the party16:18
flaper87lemme clarify something on the review16:18
kragnizflaper87: ah, I mean my store patch16:19
kragniz(too many patches!)16:19
*** annegentle has joined #openstack-glance16:19
flaper87kragniz: ah mmh, sorry. I believe I did but I'll read it again. Just to be clear, I'm not against it, I'm just hoping we can find a better way that doesn't require adding more options16:21
flaper87:D16:21
jcooknikhil_k, flaper87: ok, I'm here now, let me catch up16:22
nikhil_kjcook: flaper87 : we've added some more comments to the patches. Please ping me if you need more info.16:22
*** pennerc has joined #openstack-glance16:29
jcooknikhil_k, flaper87: The documentation is clear that the option should not be used unless you are Rackspace. No expectation is given that this option is broadly supported or used. The Danger! DO NOT USE! was explicit. If a deployer would fail because of this change it is in no way upstream or Rackspace's responsibility. In any event, the likelihood of someone using this hack outside Rackspace is minimal. This is a case where deprecation is unecessary p16:30
flaper87jcook: I must have missed something. Where's that written in glance's docs ?16:31
sigmavirus24flaper87: it's in the comments around the option, but I haven't looked at the docs yet16:31
flaper87tbh, I don't really care about the option itself but the config. That option was made public and we can't simply expect people to not use config options that we added ourselves. we shouldn't added them to begin with16:33
flaper87sigmavirus24: omg, I think I'm blind :(16:33
flaper87I can't find those comments16:33
flaper87sigmavirus24: are those comments in the patch?16:33
jcookflaper87: the option is not documented in the docs at all. It is documented here in teh config: https://github.com/openstack/glance/blob/fd5a55c7f386a9d9441d5f1291ff6a92f7e6cc1b/etc/glance-api.conf#L52016:33
sigmavirus24flaper87: what jcook said16:33
sigmavirus24jcook: is it me, or does this discussion keep happening? ;)16:33
flaper87ahhh, in the config file16:34
jcooksigmavirus24: keeps happening16:34
jcook;)16:34
flaper87sorry about that16:34
sigmavirus24flaper87: no worries16:34
sigmavirus24even other rackers missed that16:34
jcookyep :P16:34
sigmavirus24I read it, but then ben confused me16:34
flaper87sigmavirus24: jcook fwiw, it should've been in the config help text16:34
flaper87:P16:34
jcookflaper87: it shouldn't have been hacked like that in the first place :P16:35
jcookthat's why I removed it16:35
sigmavirus24And honestly, I'm the kind of jerk to use snet just because config told me not to, so there have to be others ;{16:35
flaper87jcook: I guess by removing the config option we're not changing the behavior16:35
jcookcorrect16:35
jcookdefault is false16:35
sigmavirus24flaper87: we're replacing it with betterer behaviour16:35
jcooktrue story16:35
sigmavirus24It's more betterer with less Rackspace16:35
jcookhey...well I still agree16:35
flaper87sigmavirus24: yeah, I'm just wondering if there's a way to not break cases where people like sigmavirus24 set it to True16:35
flaper87anyway, I think I'm fine now16:36
jcookcool16:36
sigmavirus24flaper87: I deserve to have a headache16:36
jcookthanks16:36
sigmavirus24And so do people like me16:36
sigmavirus24I have no sympathy for myself16:36
jcookhaha16:36
jcookIf it makes you feel better, it was a super easy change at least on our end. Just added the endpoint to the config and it was all happy16:37
flaper87jcook: sigmavirus24 I'll comment on the patch again with my changed thoughts16:37
jcookflaper87: thanks16:37
flaper87lets wait for nikhil_k to chime in again16:37
nikhil_kI'm here listening16:38
openstackgerritMerged openstack/glance_store: Validate metadata JSON file  https://review.openstack.org/14131116:38
nikhil_ksigmavirus24: I do sympathize . If we keep the bold comments like flaper87 did in his v1-v2 patch, it would solve all problems ;)16:39
sigmavirus24nikhil_k: I really can't think of another operator that would be using ServiceNet though16:39
sigmavirus24And no one has replied to jcook's emails to -dev or -operators16:40
nikhil_kflaper87: jcook : should we move ahead with what is proposed in the patch ? I _may_ be okay with it16:40
jcooknikhil_k: yes, please16:40
sigmavirus24We can wait a week for someone to reply, but I'm 99% certain that no one will reply16:40
nikhil_ksigmavirus24: +116:41
flaper87nikhil_k: jcook sigmavirus24 commented16:41
kragnizthe option should probably have been originally named i_am_rackspace = False :P16:42
flaper87WAIT16:42
flaper87nobody move16:42
openstackgerritInessa Vasilevskaya proposed openstack/glance: Declarative definitions of type-specific Artifact properties  https://review.openstack.org/11917416:42
openstackgerritInessa Vasilevskaya proposed openstack/glance: A mixin for jsonpatch requests validation  https://review.openstack.org/14858816:42
openstackgerritInessa Vasilevskaya proposed openstack/glance: Artifacts API  https://review.openstack.org/13662916:42
openstackgerritInessa Vasilevskaya proposed openstack/glance: Artifacts Repository - DB  https://review.openstack.org/11599816:42
openstackgerritInessa Vasilevskaya proposed openstack/glance: Artifacts Domain  https://review.openstack.org/13289816:42
openstackgerritInessa Vasilevskaya proposed openstack/glance: Artifacts plugin loader  https://review.openstack.org/13430016:42
* sigmavirus24 moves16:42
* nikhil_k rofl16:43
kragnizartifacts moved16:43
nikhil_kor rackspace_am_i16:43
sigmavirus24rackspace_is_my_name_snet_is_the_game16:43
flaper87ok, commented again16:43
kragnizwe haven't added glance-yoda yet, nikhil_k16:43
flaper87jcook: can you remove the option from the sample ?16:43
sigmavirus24flaper87: don't do it16:44
flaper87why?16:44
* flaper87 confused16:44
nikhil_kflaper87: nice catch16:44
flaper87sigmavirus24: ah you're trolling me16:44
flaper87>.>16:44
flaper87:P16:44
nikhil_kkragniz: yoda yoda - there you go :P16:44
*** changbl has joined #openstack-glance16:45
nikhil_kflaper87: my +2 will come after yours. see here https://review.openstack.org/#/c/150144/16:47
nikhil_k(why)16:47
* nikhil_k bbiab16:48
flaper87ok16:48
*** diegows_ has quit IRC16:48
*** diegows has quit IRC16:49
*** krykowski_ has quit IRC16:49
jcookflaper87, nikhil_k, sigmavirus24: sorry juggle multiple things16:50
*** annegentle has quit IRC16:51
jcookoption from the sample?16:51
flaper87jcook: nvm, +216:52
flaper87you already did it in a separate review16:52
jcookflaper87: cool, thanks16:52
flaper87jcook: thank you!16:52
jcooknp, ping me if you need me :)16:52
sigmavirus24flaper87: yes, I was teasing you16:53
* flaper87 pulls sigmavirus24 chair and watches him fall16:53
sigmavirus24flaper87: I use a standing desk. You're welcome16:54
* flaper87 pulls sigmavirus24 desk and watches his laptop fall and all sigmavirus24's hopes vanish16:54
sigmavirus24well that's just rude16:54
flaper87LOL16:54
*** Longgeek has joined #openstack-glance16:57
*** pdb has quit IRC16:59
*** boris-42 has joined #openstack-glance17:03
*** Longgeek has quit IRC17:03
sigmavirus24flaper87: it'd be more effective if you removed the +2 from the enum patch on store capabilities =P17:04
flaper87sigmavirus24: why?17:04
sigmavirus24That would be a far superiour troll to pulling my chair out from under me17:05
sigmavirus24=P17:05
kragnizflaper87: that's worse than pulling sigmavirus24's desk17:05
sigmavirus24Just be like -Code-Review "I changed my mind. YOLO"17:05
kragnizsigmavirus24 has strange values17:05
flaper87omg, I'm very slow today17:05
* flaper87 has been in meetings for 2 days17:05
sigmavirus24flaper87: you need more RAM17:05
sigmavirus24Use downloadmoreram.com for quick upgrades17:05
*** pdb has joined #openstack-glance17:05
kragnizsigmavirus24: everyone uses bittorrent to download their ram these days17:06
*** changbl has quit IRC17:06
sigmavirus24kragniz: they also offer bitcoins17:06
sigmavirus24http://downloadmorebitcoin.com/17:06
*** annegentle has joined #openstack-glance17:09
openstackgerritMerged openstack/glance: Simplify context by using oslo.context  https://review.openstack.org/14344917:13
*** diegows has joined #openstack-glance17:14
*** rwsu-afk is now known as rwsu17:15
*** annashen has joined #openstack-glance17:16
*** belmoreira has quit IRC17:17
*** sgotliv has quit IRC17:23
kragnizsigmavirus24: it would suck to wait almost a month for a VM to boot17:28
sigmavirus24wait a second17:28
sigmavirus24there are more than 194 days in a month? TIL!17:28
kragnizwhat is wrong with me17:29
kragnizsigmavirus24: please forgive me17:32
sigmavirus24kragniz: why?17:32
kragnizsigmavirus24: please17:32
sigmavirus24what did you do kragniz ?17:32
sigmavirus24what did you -1 now?17:32
sigmavirus24=P17:32
kragnizhalf a year is not under a month17:33
kragnizI am not worthy to -1 anything17:33
*** annegentle has quit IRC17:33
*** pennerc has quit IRC17:34
cpallareskragniz: except that store patch17:35
sigmavirus24cpallares: ++17:35
cpallareskragniz: just kidding17:35
kragnizcpallares: ;_;17:35
kragnizn-not you, too17:35
*** diegows has quit IRC17:37
*** jistr has quit IRC17:38
*** tshefi has quit IRC17:47
*** nlevinki_ has quit IRC17:48
*** krtaylor has quit IRC17:48
*** pdb has quit IRC17:49
openstackgerritMerged openstack/glance: Update vmware_adaptertype metadef values  https://review.openstack.org/15190117:52
*** krtaylor has joined #openstack-glance17:54
*** nellysmitt has quit IRC17:58
*** MattMan has quit IRC18:02
*** changbl has joined #openstack-glance18:04
*** flwang has quit IRC18:04
*** krykowski has joined #openstack-glance18:05
*** mjturek has left #openstack-glance18:10
*** harlowja has joined #openstack-glance18:15
openstackgerritInessa Vasilevskaya proposed openstack/glance: Artifacts API  https://review.openstack.org/13662918:36
kragniznikhil_k: around?18:42
nikhil_kkragniz: yo18:42
kragnizwhat do you think a workaround for swift retry stuff going over rate limits could be?18:42
nikhil_kkragniz: lemme get back to you in a couple hours on that18:43
kragnizrate limiting is disabled by default in swift18:43
kragnizokay, sounds good18:43
nikhil_ksorry about it18:43
kragnizthat's okay18:43
*** Longgeek has joined #openstack-glance18:48
*** markus_z has quit IRC18:51
*** delatte has joined #openstack-glance18:51
*** delattec has quit IRC18:55
openstackgerritMerged openstack/glance: Replace snet config with endpoint config  https://review.openstack.org/15014418:59
*** aix has quit IRC18:59
*** delatte has quit IRC19:00
*** krykowski has quit IRC19:00
*** changbl has quit IRC19:05
*** Longgeek has quit IRC19:10
openstackgerritIan Cordasco proposed openstack/python-glanceclient: Remove graduated gettextutils from openstack/common  https://review.openstack.org/14527319:20
openstackgerritIan Cordasco proposed openstack/python-glanceclient: Ignore NoneType when encoding headers  https://review.openstack.org/15215919:22
*** jasondotstar has quit IRC19:30
openstackgerritInessa Vasilevskaya proposed openstack/glance: Artifacts API  https://review.openstack.org/13662919:33
*** changbl has joined #openstack-glance19:34
*** vijendar has quit IRC19:36
*** nellysmitt has joined #openstack-glance19:48
nikhil_kkragniz: o/19:54
* sigmavirus24 steals the wave intended for kragniz19:54
nikhil_k:)19:55
nikhil_kwill just leave a message19:55
* sigmavirus24 hopes kragniz uses a reliable messaging queue19:55
nikhil_kkragniz: basically, I see a complete separation of the ideologies here. And both seem to be right in their own way. So, your point about a workaround seems like the right direction.19:56
nikhil_kAs these are configs and the issue is with defaults, I do not see a clear way for us to propose a workaround (without having to make the code overtly complicated)19:57
openstackgerritEddie Sheffield proposed openstack/glance: Add ability to deactivate an image  https://review.openstack.org/13271719:58
nikhil_kBest thing to do in this situation sounds like going to the openstack operators group and getting a vote. Let this become a democratic debate on defaults.19:58
nikhil_kTechnically we seem to have failed miserably anyways (atm)19:58
nikhil_ksigmavirus24: hey, I've been requested to look into the deactivate spec, as it did not make it to the k2 milestone20:00
nikhil_kthis one https://review.openstack.org/#/c/135122/20:00
sigmavirus24Yep. I remember it20:00
*** thumpba has quit IRC20:00
nikhil_ksigmavirus24: can we sync up on this on Friday?20:00
* sigmavirus24 takes no responsibility for the API design argument started there since he was asked to bring those people into the discussion =P20:01
sigmavirus24nikhil_k: I'm travelling Friday morning20:01
nikhil_kand involve whomever we need to for resolving the conflicts20:01
nikhil_ksigmavirus24: no issues, I understand and appreciate the open debate20:01
* sigmavirus24 ✈︎ tennessee20:01
nikhil_ksigmavirus24: I can meet you in person :P20:01
sigmavirus24Will you be at PyTennessee?20:01
*** shakamunyi has joined #openstack-glance20:02
* nikhil_k looks up20:02
nikhil_ksigmavirus24: looks interesting. Would like to - though it seems rather difficult20:04
nikhil_k10% chance that I would be there on Sat20:04
sigmavirus24hah20:04
sigmavirus24What about PyCon20:04
sigmavirus24Anyway20:05
*** chlong has quit IRC20:05
nikhil_kagain montreal :(20:05
sigmavirus24Next year then20:05
sigmavirus24I think I like Michael's last suggestion (the most recent comment about the API design)20:06
nikhil_kthis is was successive year in montreal20:06
sigmavirus24Yes. Next year it'll be in Portland iirc.20:06
stevellewill be nice for me20:07
sigmavirus24stevelle: you can ride your bicycle to your favorite hipster free-trade artisinal coffee-shop before heading to the conference each day20:08
nikhil_kheh20:08
stevelleand I'll do it wearing a kilt and vibrams20:08
sigmavirus24^520:08
nikhil_ksigmavirus24: I think we lose the functional aspect of it in essense20:09
nikhil_kessence20:09
nikhil_kThe argument that Miguel has is the 'action' is bad and that we need to operate on the status20:11
nikhil_k'action' symantics is a bad style*20:11
nikhil_kgah, *semantics*20:11
* nikhil_k takes a deep breath20:12
*** boris-42 has quit IRC20:12
nikhil_kThe main reason why such a proposal was made in the first place was to indicate that this kind of operation is a 'functional' aspect of the image entity20:12
nikhil_kthe image entity ==  image record (with metadata) + image data20:13
sigmavirus24hold on, let me find Miguel20:13
nikhil_kcool20:13
openstackgerritMerged openstack/glance_store: Replace snet config with endpoint config  https://review.openstack.org/13972620:15
*** vijendar has joined #openstack-glance20:15
*** flwang has joined #openstack-glance20:16
*** miguelgrinberg has joined #openstack-glance20:16
miguelgrinbergnikhil_k: so I'm being summoned to defend my "actions are bad" argument :)20:18
sigmavirus24heh20:18
miguelgrinberghaving lots of little URLs that perform actions is a bad design, it goes against what REST is20:19
miguelgrinbergreally, in a REST API there are no "functional" operations, you only have resources and state transitions20:20
*** sgotliv has joined #openstack-glance20:23
stevellethe crux of this blueprint seems to be a state transition20:23
nikhil_kmiguelgrinberg: yeah, the weird thing is that openstack is not always REST friendly20:23
*** shakamunyi has quit IRC20:23
nikhil_kstevelle: it seems that way though it is a _little_ different than that20:23
miguelgrinbergnikhil_k: of course, but we should try to fix that20:23
nikhil_kheh20:23
sigmavirus24nikhil_k: that's something a group of people are working to fix though20:23
sigmavirus24And just because it isn't already doesn't mean we can't start trending towards it20:24
miguelgrinbergthis is a nice opportunity, you guys don't have a /actions yet, for other it is too late20:24
sigmavirus24esheffield: you around?20:24
nikhil_kmiguelgrinberg: Mark had originally proposed to go this route. If you don't mind, can I share some of the viewpoints?20:24
miguelgrinbergsure20:24
esheffieldsigmavirus24, what's up?20:25
*** vijendar has left #openstack-glance20:25
sigmavirus24We're discussing your spec20:25
nikhil_kmiguelgrinberg: this proposal stems from the new feature that we have in Glance. Called async tasks20:25
sigmavirus24Thought you'd be interested20:25
*** jasondotstar has joined #openstack-glance20:25
esheffieldsure20:26
nikhil_kmiguelgrinberg: you can have a task of kind 'import' where the user has the opportunity to upload a custom image20:26
nikhil_kmiguelgrinberg: of course, the tasks will have a mechanism for the operator to perform a specific set of checks on the image before it can be used in a production system20:27
*** flwang2 has joined #openstack-glance20:27
*** flwang has quit IRC20:27
nikhil_kthis being a different kind of image and Glance states being conservatively kept to a small number (with good reason), we want the operator to be able to prevent any boot operations in certain conditions20:28
nikhil_kHence, a operator specific API was proposed with certain functional aspects to it - activate and deactivate in this case20:29
nikhil_kwe are using /tasks URL for the import, so /actions seems a good way for admins to deactivate and image and re-activate it (after whatever offline checks they have done - besides what the async task script does)20:30
nikhil_kthey == admins20:31
nikhil_ks/and image/an image/g20:31
* nikhil_k ends the context discussion20:31
* nikhil_k hands over the mic to miguelgrinberg 20:31
miguelgrinbergsorry, had to step away for a sec, let me read this20:33
miguelgrinbergthis is the RPC way of thinking. It's not wrong, it's just not REST20:34
miguelgrinberginstead you can have the same thing done by altering the state of the image20:34
miguelgrinbergthen you don't need to start creating new URLs20:34
miguelgrinbergwhich, BTW, hurt chances of ever getting hypermedia properly implemented20:35
miguelgrinbergsigmavirus24: you can roll your eyes at ^, you have my permission20:35
stevellemiguelgrinberg to be fair, altering the state of the image isn't addressing the existing state model available to Glance20:35
miguelgrinbergwhat I don't get, is why do it with actions, when you can do the same with a state transition and without having to create new URLS20:37
sigmavirus24So for what my 2 ¢ are worth, I like miguelgrinberg's last proposal on the review20:38
sigmavirus24I also understand that the existing services that have similar functionality all use /actions/{foo}20:38
nikhil_kmiguelgrinberg: so, this is where it gets complicated. We do not want to enable explicit state transitions on image.20:38
nikhil_ksomething that is not exposed by the API20:39
sigmavirus24That said, I'm not sure I understand the way the operators are expected to use this20:39
sigmavirus24Are we expecting them to use curl, glanceclient, openstackcli, what?20:39
nikhil_kImage 'state' is very internal aspect of the entity and that is for a good reason20:39
nikhil_ksigmavirus24: so, the glanceclient would support whatever the g-api does20:40
sigmavirus24Right, so my thing is this: If the operator isn't going to see the route and method, why do we care how they use the API?20:40
nikhil_kand operators would have option to choose between the client or any UI that the operator has setup for them (what UI uses it up to them)20:41
sigmavirus24I would expect there to be only a few direct consumers of the API: client wrappers, horizon, people who like to script things with curl20:41
nikhil_ksigmavirus24: well, the issue is not with how operators use it. The issue is about exposing operations on the image state out in the API20:41
nikhil_kand that is complete no, no20:42
sigmavirus24So I fail to see how POST /images/{image-id}/actions/inactive and PUT /images/{image-id}/inactive are so different in their design20:46
sigmavirus24I mean one is subjectively better than the other and far clearer20:46
nikhil_kOne suggestes that you have to perform a certain operations on the image to make it inactive and not just change its state20:48
*** openstackgerrit has quit IRC20:50
*** jasondotstar has quit IRC20:50
*** openstackgerrit has joined #openstack-glance20:50
*** annashen has quit IRC20:52
stevelle /images/{image-id}/members does not change the image state20:53
stevellebut it does imply a state transition for the image in terms of availability20:53
nikhil_kThat is a slightly different aspect of the system20:55
nikhil_kIt is dealing with the members who have access to the image and not deal with the availability of the resource20:55
nikhil_kAlthough, I do find it a little odd20:56
stevelleavailability is in the spectrum of access in this case.20:56
miguelgrinbergnikhil_k: you say you do not want to enable an explicit transition, but allowing the client to change its enabled (or active, can't remember what it was exactly) is a state transition disguised as an action20:56
*** Longgeek has joined #openstack-glance20:56
nikhil_kstevelle: yeah, I agree to that point20:56
stevellemiguelgrinberg: are you thinking of  "published" iirc?20:56
miguelgrinbergback when I reviewed this I tihnk it was to "deactivate" an image? I think that's what it was20:57
nikhil_kyes, deactivate20:57
stevelleI see now. ty20:57
nikhil_kmiguelgrinberg: well, it's not exactly so. It is allowing an op (internal admin) to perform a certain checks on the image and then put it in deactivate state20:58
miguelgrinbergso this is an multi-task action?20:58
nikhil_ka certain number of checks*20:58
miguelgrinberga single URL will trigger a bunch of things?20:58
nikhil_kit's deactivation20:59
nikhil_khow it does is Glance's reponsibility20:59
sigmavirus24nikhil_k: the spec seemed to imply a state transition as the main way of handling this20:59
nikhil_k(basically, a tricky question to answer in an open source project)20:59
nikhil_ksigmavirus24: ^21:00
miguelgrinbergso the image is either deactivate or it is not. That's how I think about this in terms of states. I know you have a "state" property, that may be unrelated to this.21:00
*** Longgeek has quit IRC21:00
sigmavirus24nikhil_k: so the thing is you're exposing the making of the sausage to the user21:00
sigmavirus24you're saying "You want to deactivate an image and prevent anyone from booting from it"21:01
miguelgrinbergnikhil_k: so if you have a property in the image resource that indicates if the image is in this "deactivated" state, then have the op send a PUT request editing that property.21:01
nikhil_krosmaita: you around? Just want to know if we have plans to perform more than state change on the image.21:01
sigmavirus24Which would seem to be a simple action on the part of the operator21:01
stevelleI feel like the naming may make this feel more opaque than it needs to, but that's another discussion21:01
sigmavirus24Like to the operator their conceptual model doesn't need to be anything other than "I want to deactivate this image" or "I want to reactivate this image"21:01
nikhil_kmiguelgrinberg: that is what we do not want. It's a read only property as far as user is concerned21:01
nikhil_khere the user is op21:01
miguelgrinbergit's not read only, you want the operator to change this state bit!21:02
*** annegent_ has joined #openstack-glance21:02
miguelgrinbergyou are confusing your big "state" with this particular sub-state21:02
*** diegows has joined #openstack-glance21:02
miguelgrinbergthe image deactivated state is separate from your read-only global state for the image21:02
sigmavirus24I think the plan is to use the same attribute to convey all of this21:03
*** sgotliv has quit IRC21:03
nikhil_kmiguelgrinberg: when you will ask the op to perform an action on this image, the backend API _can_ perform something before changing the state. It's not a straightforward transition.21:03
sigmavirus24Which may be simpler and have less of a data model impact but may not be the right choice given this discussion21:03
stevellethat this property is not modifiable by the owner, only by operator, seems like it supports the idea that this belongs to a separate resource ideally21:03
miguelgrinbergsigmavirus24: I know, but that's wrong for this, because you don't want to allow edits to this attributte21:03
miguelgrinbergI'm fine with having a read-only property, but that doesn't mean you can alter state through other writable properties21:04
miguelgrinbergthat in turn may translate into a change in the read-only prop21:04
stevellemiguelgrinberg: I might nit pick over that big about altering state through side effects21:04
stevelles/big/bit/21:05
miguelgrinbergwell, then don't make your state read-only, that's causing most of this confusion. How do other states get set?21:05
miguelgrinbergstevelle: give me an example of how another state transition happens, without editing the state property21:06
nikhil_kfor example, an image goes from queued to saving when the user starts uploading data21:06
stevellecommand-query separation21:06
nikhil_k(or the data is being uploaded by some other mechanism)21:07
stevelleCQS REST APIs are legitimate, but it's best if the whole semantics of the API is built that way21:07
miguelgrinbergnikhil_k: aren't you mixing two categories of states then?21:07
miguelgrinbergyou have states that are a consequence of a major even in the life-cycle of the image21:08
miguelgrinbergbut this is a man-made state21:08
nikhil_kmiguelgrinberg: it's not. It provides a way for glance to establish a deactivated (or whatever appropriate) state21:08
nikhil_kthere are multiple ways an image can go from queued to saving today21:09
*** nellysmitt has quit IRC21:09
miguelgrinbergbut none of them implies the operator setting state=saving21:09
nikhil_ktomorrow there could be multiple ways an image can go from <myimage_state> to deactivated21:09
stevellethe state property is a semi-computed property already, which is part of the challenge.  if it was fully computed that would make this easier21:09
miguelgrinbergare there any circumstances in which state can be edited by the client?21:10
miguelgrinbergI mean edited directly21:10
stevelleI'm not familiar with one, but not authoritative21:10
nikhil_kstevelle: I did not get that completely. Mind elaborating a little bit? It would be really useful for us to make Glance image transitions better21:10
nikhil_kmiguelgrinberg: no, we do not allow that21:11
nikhil_kmiguelgrinberg: user/client needs to perform something on the image before state changes21:11
miguelgrinbergI think you have a first situation in which  the image must be put into a state, without an event triggering that transition.21:11
nikhil_kor even glance has to perform something that triggers this state change21:11
miguelgrinbergit's just arbitrary, the operator wants to do it21:11
stevellenikhil_k: when an image state == "saving" that is a state that is not computed.  You have nowhere you can look to identify that it is saving.  See also glance bugs21:11
sigmavirus24So here's a thought21:12
sigmavirus24This is being proposed mostly for use in situations when an operator wants to audit an image, yes?21:12
nikhil_kstevelle: yes, you can have some images that are stuck. agreed. However, the upload process has started on the image at some point21:12
nikhil_ksigmavirus24: yes (that's the fundamental use case)21:13
sigmavirus24What other use cases do we envision people using this for?21:13
nikhil_ksigmavirus24: introspection for one21:13
nikhil_ksigmavirus24: may be if metadata, headers etc need to be changed on the disk21:14
nikhil_kor if the backend storage is under maintenance21:14
nikhil_kthis can be adopted further21:15
sigmavirus24Okay so that kind of destroys the idea that I had for resolving this21:15
sigmavirus24I wonder if a more generic event system around images would be better21:15
miguelgrinbergnikhil_k: what do you think would happen if you allow certain writes to the state property?21:15
miguelgrinbergyou would have validation in place, so the client can ask for any state to be set, but you would only allow it when it makes sense21:16
nikhil_kThe main worry is that Nova would want to own some of the state transistions and that would destroy the fundamental aspect of glance owning the image and being source of truth21:17
miguelgrinbergso for example, active ==> deactivated would be allowed, but saving ==> deactivated would not21:17
miguelgrinbergyou can continue having events that alter the state, but now you also allow the state to change on its own, for event-less state changes21:18
*** annegent_ has quit IRC21:18
* sigmavirus24 away shortly21:19
miguelgrinbergnikhil_k: but you never lose control, nova still has to go through you for any state changes, and you can only allow what you think is valid21:19
miguelgrinbergmaking the state writeable does not mean anybody can set any state, you still keep tight control21:20
miguelgrinbergany weird state change you reply with a 40021:20
nikhil_kmiguelgrinberg: I see your point, however the one thing that hurts in the process is exposing state specific write operations to the user and not keeping it internal to the system. Something that the program does not want to do.21:21
nikhil_kAnd trust me, I've been on the other side of the seat21:22
nikhil_kand had this response for such a proposal. It's such a conservative aspect of the code that we would like it to be as-is.21:22
miguelgrinbergso what I see is that by the definition of this feature, you have a user selectable state. You can try to disguise it any way you want, but that is what this is.21:22
miguelgrinbergyou want to let an operator arbitrarily take the image offline to do something, doesn't matter what. This is arbitrary, no life-cycle event associated with it.21:23
nikhil_kmiguelgrinberg: It seems as if, it's an operation on the state. However, it's more than that. It's being able to say that this image is no longer going to be able to be provisioned.21:23
nikhil_kAnd that could mean many things, really.21:24
nikhil_kSome operators have specific metadata on their images which are allowed on certain specific kind of images21:24
miguelgrinbergbut it all comes down to putting something that is != "active" in the state. That is how the whole system will know to not use this image.21:24
nikhil_kexample: windows image - we need to ensure licensing21:24
nikhil_kmiguelgrinberg: well, that is how the current exposure of the image to the user is. If it is not active, you cannot use it.21:25
miguelgrinbergnikhil_k: okay, tell me what happens to the state when you have a windows image w/o license21:25
hemanth_sorry for jumping in late on this conversation but I think we should take a generic idea of functional operations and not just 'deactivation'21:26
nikhil_kmiguelgrinberg: the state will go to deactivated however, it _may_ perform an operation of unsetting or setting a property on the image21:26
hemanth_deactivation is just one possible functional operation21:27
*** annashen has joined #openstack-glance21:27
miguelgrinbergnikhil_k: sorry, but I don't get this. I upload a windows image, what state does it go to?21:27
* sigmavirus24 lied and is still here21:27
hemanth_when zhiyan proposed functional operations in Atlanta summit, it was to support various actions that couldn't supported in a REST style21:27
sigmavirus24hemanth_: is that a challenge?21:28
* sigmavirus24 is kidding when he asks that21:28
hemanth_providing context, I'd say21:29
nikhil_kmiguelgrinberg: So, you did an import and the image went successfully into active. However, a week later the operator does not want specific windows images on the hosts. The way to do it would be using this approach and make them not useable by putting in deactivate state.21:29
nikhil_khemanth_: Ok, glad that you mentioned that. Do we have a list of them?21:30
miguelgrinbergnikhil_k: so it's a state override21:30
hemanth_nikhil_k: I'm trying to find the etherpad that zhiyan had21:30
hemanth_also, in several conversations I heard that deactivation is an admin operation, which need not be the case21:31
hemanth_its just a policy driven operation (just that it may default to admins)21:32
sigmavirus24hemanth_: the image owner could deactivate tit too21:32
hemanth_yeah21:32
nikhil_khemanth_: this one https://etherpad.openstack.org/p/glance-adding-functional-operations-to-api ?21:32
stevellemore signs point at a sub-resource21:32
stevelleas that suggests a many-to-one of inactives to an image21:33
hemanth_nikhil_k: yeah, that one21:33
hemanth_nikhil_k: similarity is one example in there21:34
hemanth_there are few example under #121:34
miguelgrinberghemanth_: would you explain what the similarity action does?21:34
miguelgrinbergis it a diff of two imgs?21:35
hemanth_miguelgrinberg: sorta21:35
miguelgrinberghave you seen the URLs for diffs in github?21:38
miguelgrinberghemanth_: for example, http://github.com/project/compare/tag1...tag221:38
miguelgrinbergthis is a resource, not an action. Wouldn't the same work for images?21:38
sigmavirus24(very similar URI for the GitHub API too, before someone says "but that's not the API")21:41
miguelgrinbergsigmavirus24: of course, thanks21:41
sigmavirus24tl;dr there are much better inspirations for API design than the existing OpenStack APIs and since the API-WG is writing guidelines to help people write better ones (and the WG was specifically solicited for feedback here), I don't understand the trouble in not using /actions/21:42
sigmavirus24I mean if the WG's feedback isn't desired to be anything other than a mindless rubber stamp here, fine, don't ask for our input. /actions is almost certainly going to die in the WG guidelines though so you can count on that at least21:42
nikhil_kso, see here: line 31 -  We settled on 3b as an initial proposal (format -> /v2/images/{image_id}/actions/{action_name} )21:44
nikhil_kfollowed by line 3221:44
nikhil_kis there a consistency group that we need to talk to or is it just API-WG now?21:44
miguelgrinbergnikhil_k: I think that's us in the API-WG21:45
nikhil_kok, great!21:45
nikhil_khemanth_: did we ever hear from TC on this http://lists.openstack.org/pipermail/openstack-dev/2014-May/036416.html ?21:45
sigmavirus24nikhil_k: perhaps this would make more sense to discuss in the next API-WG IRC meeting (tomorrow night EST)21:46
hemanth_nikhil_k: I think we got a couple of responses21:46
nikhil_ksigmavirus24: noted . https://wiki.openstack.org/wiki/Meetings/API-WG21:48
nikhil_kit shows Thursdays so, day after then21:48
sigmavirus24nikhil_k: So it's 0000 UTC Thursday21:48
sigmavirus24which should be 7PM EST Wednesday21:49
nikhil_koh!21:49
stevelleread as 0001 Thursday UTC21:49
nikhil_kgot it21:49
nikhil_kThanks!21:49
nikhil_kok, I will discuss a bit more with Brian and may be we can try to dig a bit more on the emails21:51
nikhil_kmay be esheffield hemanth_ and I can sync up before the same21:51
nikhil_ksigmavirus24:  how do I add item to the agenda ? just edit it or talk to someone before doing so?21:52
sigmavirus24nikhil_k: just add it (might want to sign it so we know who added it)21:52
nikhil_ksigmavirus24: ack21:52
nikhil_ksigmavirus24: added21:56
nikhil_kmiguelgrinberg: sigmavirus24 stevelle hemanth_ esheffield : Thanks for your time and input. Much appreciated. Hope we get this resolved soon.21:56
miguelgrinbergnikhil_k: yup, I hope so, it's useful to have these discussions, feel free to grab me if you have questions or want to continue the discussion.21:57
nikhil_khemanth_: esheffield : I've added the item on https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda . It's at 7pm ET so, depending on who is online we will play it by ear ;)21:57
hemanth_nikhil_k: sure21:58
nikhil_kmiguelgrinberg: roger. Thanks again, helps to know what's going on and plan ahead.21:58
miguelgrinbergnikhil_k, sigmavirus24: I may not be able to attend tomorrow's meeting due to an medical appointment. Depending on how it goes and wi-fi availability I'll do my best to join.21:59
nikhil_kmiguelgrinberg: no issues, this is planned for k3 so we've time. you take care :)21:59
sigmavirus24miguelgrinberg: no worries22:00
*** eglynn has quit IRC22:05
* nikhil_k afk to get food22:07
*** peristeri has quit IRC22:13
*** sigmavirus24 is now known as sigmavirus24_awa22:14
*** jaypipes has quit IRC22:15
hemanth_miguelgrinberg: still around?22:18
miguelgrinberghemanth_: yes22:18
hemanth_just confirming, this is what you are proposing, right? PUT /v2/images/{image_id}/inactive and DELETE /v2/images/{image_id}/inactive22:18
hemanth_like 'inactive' as a resource and we are modifying that with PUT and DELETE22:19
miguelgrinberghemanth_: no, I believe that is sigmavirus24_awa compromise proposal. It's better than /actions, but what I would do myself is to add a "inactive" boolean to the image representation. You then edit it with PUT.22:19
hemanth_I see22:20
*** eglynn has joined #openstack-glance22:20
miguelgrinbergthat is, assuming you guys remain on your decision to not make the state writable22:20
*** jasondotstar has joined #openstack-glance22:20
hemanth_miguelgrinberg: yeah, not sure if we'd like to make the state writable22:21
hemanth_let's see, I'll give it more thought22:22
miguelgrinbergI think the solution becomes more complicated because of that design decision. Ideally you just let the client change the state. So second to that I would propose an additional state variable, and sigmavirus24_awa's proposal would be my #322:22
TravTI was just joking with a co-worker that we're going to propose a new HTTP verb... DOIT  as in Do It22:26
*** cpallares has quit IRC22:27
*** harlowja is now known as harlowja_away22:28
TravTBecause the entire HTTP verb list is not very conducive to handling actions22:28
TravTalthough POST does state this: The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.22:29
nikhil_k:)22:29
miguelgrinbergTravT: in reality, HTTP does not restrict you from implementation actions. It's perfectly fine to have actions in a POST or a  PUT request.22:30
TravTactually, nikhil_k that was you I was joking with. :)22:30
nikhil_kTravT: heh, yeah22:31
*** thangp has quit IRC22:31
*** TravT has quit IRC22:33
*** sigmavirus24_awa is now known as sigmavirus2422:41
sigmavirus24The fun thing is that in HTTP you can return whatever status code you want really. No one follows conventions anyway22:43
stevellehemanth_: if you want to maintain multiple actors being able to place/remove their own lock on an image, the compromise is stronger because that lets different actors manage their own lock and you can record the owner of the lock, and date/times for events for each image22:43
sigmavirus24stevelle: so that, to me, is trending towards a full-fledged event based way of handling this22:44
lifelesssigmavirus24: uhm22:44
sigmavirus24lifeless: ?22:44
lifelesssigmavirus24: *no*, you can't. Lots of intermediaries (like squid, and application level firewalls (e.g. cisco PIX)) will toss out unknown status codes22:44
sigmavirus24lifeless: I was joking22:44
lifelesssigmavirus24: and make assumptions about caching and so forth based on the code that you did use22:45
lifelesssigmavirus24: ah, phew. Sorry!22:45
stevellesigmavirus24: Yes. And?22:45
* lifeless takes off the HTTP-serious-hat22:45
sigmavirus24lifeless: my favorite thing will be if PHK is right about HTTP/2's affect on proxies22:45
*** jasondotstar has quit IRC22:46
sigmavirus24it may mean the gradual slow death of proxies finally22:46
hemanth_stevelle: its not locking for a particular user(s), at least not yet22:46
sigmavirus24stevelle: oh, I prefer that system myself but I feel like esheffield hemanth_ zhiyan nikhil_k etc. all wanted the simplest possible solution to DOIT now22:46
stevellehemanth_: sorry for confusion.  Consider logic of if image.locks.length > 0: calculated-image-status = inactive22:47
*** tellesnobrega has quit IRC22:47
stevellenot locking FOR a user, but locking by.22:47
*** TravT has joined #openstack-glance22:47
stevelleand user may actually just be a keystone role22:47
* sigmavirus24 goes back to looking at these artifacts splayed across his screen22:48
lifelesssigmavirus24: oh? I must have missed his latest rant22:48
sigmavirus24lifeless: oh this has been the same rant for several months now22:48
lifelesssigmavirus24: we're seeing more and more ssl MITM configurations for squid these days... if we get /2 out there I don't think HTTP/2 will affect it at all22:49
sigmavirus24HTTP/2 will apparently break the ability to filter out things corporations want to filter out22:49
nikhil_ksigmavirus24: we are looking for a solution that works for the project use cases without tying to semantics22:49
lifelessheh, no.22:49
*** tellesnobrega has joined #openstack-glance22:49
sigmavirus24lifeless: please join the chorus of others who tried telling PHK that22:49
lifelessit will break the ability for ISPs to do country level intercepting proxies, in the absence of legal intervention (with CAs)22:49
* nikhil_k rules are meant to be broken, after all22:50
lifelesswhich is a good thing, except where the ISP is a govt body :/22:50
* nikhil_k afk22:50
sigmavirus24You'd think PHK would at that point be in favor of Opportunistic Security because it would be easier to MITM22:50
lifelesssigmavirus24: Oh, I'd never try to tell PHK something.22:50
sigmavirus24lifeless: he'd just write about it in the ACM Queue angstily22:50
sigmavirus24No danger to you22:50
lifeless:)22:51
lifelessI was thinking more that its a waste of my time22:51
sigmavirus24Wait, other people don't freely waste their time? What's wrong with all of you?22:51
stevellewe use it up at the same rate, doesn't matter so much what it's spent on does it? :)22:52
openstackgerritSabari proposed openstack/glance_store: Fix sorting query string keys for arbitrary url schemes  https://review.openstack.org/14876722:53
*** EmilienM is now known as EmilienM|afk23:03
*** ericpeterson has quit IRC23:03
*** TravT has quit IRC23:04
*** changbl has quit IRC23:06
*** jaypipes has joined #openstack-glance23:07
*** briancurtin has quit IRC23:08
*** TravT has joined #openstack-glance23:08
*** zhiyan has quit IRC23:08
*** ameade has quit IRC23:09
*** nellysmitt has joined #openstack-glance23:10
*** TravT has quit IRC23:12
*** esheffield has quit IRC23:12
*** nellysmitt has quit IRC23:14
*** jasondotstar has joined #openstack-glance23:15
openstackgerritOpenStack Proposal Bot proposed openstack/glance: Updated from global requirements  https://review.openstack.org/15271123:15
*** zhiyan has joined #openstack-glance23:21
*** ameade has joined #openstack-glance23:21
openstackgerritOpenStack Proposal Bot proposed openstack/python-glanceclient: Updated from global requirements  https://review.openstack.org/14997723:22
*** TravT has joined #openstack-glance23:30
*** harlowja_away is now known as harlowja23:32
*** briancurtin has joined #openstack-glance23:33
*** jasondotstar has quit IRC23:45
*** jgrimm is now known as zz_jgrimm23:47
*** annashen has quit IRC23:52
*** TravT has quit IRC23:58

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!