*** GheRivero_ has quit IRC | 00:01 | |
*** byeager has joined #openstack-dev | 00:07 | |
rmk | Maybe this is a bit open ended of a question but are there any obvious incompatibilities between the Essex dash and Diablo API? I haven't dug into this much but deleting instances doesn't work via essex dash to diablo api, just wonder how deep that goes. | 00:08 |
---|---|---|
*** dtroyer has quit IRC | 00:11 | |
tomoe_ | hello. does anyone know the status of floating ip and melange integration? | 00:15 |
*** dolphm has joined #openstack-dev | 00:23 | |
*** dtroyer has joined #openstack-dev | 00:30 | |
*** eglynn__ has quit IRC | 00:36 | |
openstackgerrit | Verification of a change to openstack/horizon failed: Improve usability of syspanel instance list. https://review.openstack.org/4281 | 00:49 |
*** crobinso has quit IRC | 01:09 | |
*** dolphm has quit IRC | 01:09 | |
*** markvoelker has quit IRC | 01:10 | |
*** bengrue has quit IRC | 01:10 | |
*** dolphm has joined #openstack-dev | 01:17 | |
*** dolphm has quit IRC | 01:45 | |
*** andrewsmedina has quit IRC | 01:50 | |
*** andrewsmedina has joined #openstack-dev | 01:58 | |
*** anotherjesse has joined #openstack-dev | 02:08 | |
*** Guest29011 has joined #openstack-dev | 02:08 | |
*** rods has quit IRC | 02:08 | |
Guest29011 | ? | 02:09 |
*** negronjl has quit IRC | 02:13 | |
*** Guest29011 has quit IRC | 02:14 | |
*** jog0 has left #openstack-dev | 02:19 | |
*** dtroyer has quit IRC | 02:24 | |
*** jog0_ has joined #openstack-dev | 02:25 | |
*** jog0_ has left #openstack-dev | 02:25 | |
*** mjfork has quit IRC | 02:40 | |
*** zul has quit IRC | 02:48 | |
*** zul has joined #openstack-dev | 02:50 | |
*** dtroyer has joined #openstack-dev | 02:55 | |
*** novas0x2a|laptop has quit IRC | 03:02 | |
*** novas0x2a|laptop has joined #openstack-dev | 03:02 | |
*** jog0 has joined #openstack-dev | 03:03 | |
*** jog0 has quit IRC | 03:03 | |
*** andrewbogott_ is now known as andrewbogott__af | 03:11 | |
*** pixelbeat has quit IRC | 03:13 | |
*** jdg has quit IRC | 03:15 | |
*** jdg has joined #openstack-dev | 03:16 | |
*** dubsquared has quit IRC | 03:17 | |
*** dubsquared has joined #openstack-dev | 03:18 | |
*** heckj has quit IRC | 03:24 | |
*** danwent has quit IRC | 03:38 | |
*** mjfork has joined #openstack-dev | 03:47 | |
*** stuntmachine has quit IRC | 04:13 | |
*** hattwick has quit IRC | 04:20 | |
*** dubsquared has quit IRC | 04:25 | |
*** jdg has quit IRC | 04:29 | |
*** mjfork has quit IRC | 04:38 | |
*** hattwick has joined #openstack-dev | 04:40 | |
*** jdg has joined #openstack-dev | 04:51 | |
*** ootz0rz has joined #openstack-dev | 04:52 | |
*** jdg has quit IRC | 04:56 | |
*** jdg has joined #openstack-dev | 04:57 | |
*** dubsquared has joined #openstack-dev | 05:01 | |
*** dubsquared has quit IRC | 05:01 | |
*** danwent has joined #openstack-dev | 05:02 | |
*** dubsquared has joined #openstack-dev | 05:03 | |
*** negronjl has joined #openstack-dev | 05:05 | |
*** anotherjesse has quit IRC | 05:18 | |
*** anotherjesse has joined #openstack-dev | 05:20 | |
*** mnewby has quit IRC | 05:24 | |
*** jdg has quit IRC | 05:24 | |
*** mnewby has joined #openstack-dev | 05:28 | |
*** ncode has joined #openstack-dev | 05:28 | |
*** ncode has joined #openstack-dev | 05:28 | |
*** mnewby has quit IRC | 05:30 | |
*** ootz0rz has quit IRC | 05:30 | |
*** anotherjesse has quit IRC | 05:55 | |
*** quantum2112 has joined #openstack-dev | 05:57 | |
*** anotherjesse has joined #openstack-dev | 06:00 | |
*** sannes has joined #openstack-dev | 06:06 | |
quantum2112 | hi | 06:06 |
*** deshantm has quit IRC | 06:07 | |
quantum2112 | to create quantum network, what api is used? nova or quantum | 06:07 |
quantum2112 | quantum api seems to augment network creation, when do you use the quantum api to create network that can be used by nova? | 06:11 |
*** journeeman has joined #openstack-dev | 06:11 | |
*** ootz0rz has joined #openstack-dev | 06:20 | |
*** danwent has quit IRC | 06:24 | |
*** bepernoot has joined #openstack-dev | 06:37 | |
*** ncode has quit IRC | 06:42 | |
*** journeeman has quit IRC | 06:42 | |
*** viveksnv has joined #openstack-dev | 06:45 | |
*** sannes has quit IRC | 06:46 | |
*** journeeman has joined #openstack-dev | 06:49 | |
*** anotherjesse has quit IRC | 06:50 | |
*** bepernoot has quit IRC | 06:51 | |
*** littleidea has quit IRC | 06:52 | |
*** zaitcev has quit IRC | 06:53 | |
*** littleidea has joined #openstack-dev | 06:53 | |
*** eglynn__ has joined #openstack-dev | 07:02 | |
*** eglynn__ has quit IRC | 07:07 | |
*** littleidea has quit IRC | 07:11 | |
*** adjohn has quit IRC | 07:12 | |
*** viveksnv has quit IRC | 07:14 | |
*** sleepsonthefloo has quit IRC | 07:17 | |
justinsb | If I can crash the compute server, should I file the bug as a security vulnerability? | 07:31 |
*** dubsquared has quit IRC | 07:33 | |
*** rmk has quit IRC | 07:48 | |
*** rmk has joined #openstack-dev | 07:49 | |
*** eglynn__ has joined #openstack-dev | 07:52 | |
*** quantum2112 has quit IRC | 07:53 | |
soren | justinsb: Very likely, yes. | 08:16 |
*** rbasak has quit IRC | 08:20 | |
justinsb | soren: Thanks ... I decided better to be safe than sorry, so I filed it as a vulnerability | 08:21 |
*** tomoe_ has quit IRC | 08:34 | |
*** apevec has joined #openstack-dev | 08:35 | |
*** zigo has joined #openstack-dev | 08:35 | |
*** rbasak has joined #openstack-dev | 08:38 | |
*** zigo has quit IRC | 08:38 | |
*** zigo has joined #openstack-dev | 08:39 | |
*** zigo has quit IRC | 08:46 | |
*** zigo has joined #openstack-dev | 08:46 | |
*** shevek_ has joined #openstack-dev | 08:58 | |
*** hashar has joined #openstack-dev | 08:59 | |
*** reidrac has joined #openstack-dev | 09:00 | |
*** zigo has quit IRC | 09:00 | |
*** zigo has joined #openstack-dev | 09:03 | |
*** derekh has joined #openstack-dev | 09:03 | |
*** darraghb has joined #openstack-dev | 09:05 | |
*** zigo-_- has joined #openstack-dev | 09:12 | |
*** zigo has quit IRC | 09:13 | |
*** pixelbeat has joined #openstack-dev | 09:14 | |
*** berendt has joined #openstack-dev | 09:15 | |
*** mancdaz has joined #openstack-dev | 09:16 | |
berendt | can somebody from the keystone or jenkins team have a look at the bug report #937265, the tarballs on jenkins are not usable at the moment | 09:16 |
*** ncode has joined #openstack-dev | 09:19 | |
*** ncode has joined #openstack-dev | 09:19 | |
*** shang has joined #openstack-dev | 09:19 | |
*** ncode has quit IRC | 09:20 | |
*** Mkenneth has joined #openstack-dev | 09:22 | |
*** shang has quit IRC | 09:27 | |
*** Mkenneth has quit IRC | 09:27 | |
*** derekh has quit IRC | 09:30 | |
*** shang has joined #openstack-dev | 09:32 | |
*** derekh has joined #openstack-dev | 09:34 | |
*** Mkenneth has joined #openstack-dev | 09:40 | |
*** reed has quit IRC | 09:44 | |
*** reed has joined #openstack-dev | 09:44 | |
*** reed has quit IRC | 09:48 | |
*** Vek has quit IRC | 09:50 | |
*** jeremy_ has joined #openstack-dev | 10:07 | |
*** HugoKuo_ has quit IRC | 10:22 | |
*** Remco_ has joined #openstack-dev | 10:32 | |
*** Ryan_Lane has quit IRC | 10:33 | |
*** justinsb has quit IRC | 10:35 | |
*** justinsb has joined #openstack-dev | 10:36 | |
*** Ryan_Lane has joined #openstack-dev | 10:36 | |
*** Remco_ has quit IRC | 10:42 | |
*** Remco_ has joined #openstack-dev | 10:49 | |
*** shang has quit IRC | 10:59 | |
*** zykes_ has joined #openstack-dev | 11:07 | |
zykes_ | anyone from netstack here ? | 11:07 |
*** tryggvil has quit IRC | 11:08 | |
*** tryggvil has joined #openstack-dev | 11:08 | |
*** tryggvil has quit IRC | 11:11 | |
*** tryggvil has joined #openstack-dev | 11:11 | |
*** shang has joined #openstack-dev | 11:13 | |
*** hashar has quit IRC | 11:29 | |
*** markmc has joined #openstack-dev | 11:31 | |
*** mjfork has joined #openstack-dev | 11:39 | |
*** Vek has joined #openstack-dev | 11:45 | |
*** hub_cap has joined #openstack-dev | 11:50 | |
*** hub_cap has quit IRC | 11:51 | |
*** shang has quit IRC | 11:52 | |
*** sandywalsh has joined #openstack-dev | 11:55 | |
*** hashar has joined #openstack-dev | 11:56 | |
*** rods has joined #openstack-dev | 12:00 | |
*** shang has joined #openstack-dev | 12:05 | |
*** hashar has left #openstack-dev | 12:06 | |
*** Remco__ has joined #openstack-dev | 12:07 | |
*** Remco_ has quit IRC | 12:08 | |
*** sandywalsh has quit IRC | 12:09 | |
*** Remco__ has quit IRC | 12:12 | |
*** Remco_ has joined #openstack-dev | 12:13 | |
*** dneary has joined #openstack-dev | 12:15 | |
*** sandywalsh has joined #openstack-dev | 12:21 | |
*** jeroenhn has joined #openstack-dev | 12:29 | |
*** maploin has joined #openstack-dev | 12:32 | |
*** maploin has quit IRC | 12:32 | |
*** maploin has joined #openstack-dev | 12:32 | |
*** journeeman has left #openstack-dev | 12:42 | |
*** andrewbogott__af has quit IRC | 12:51 | |
*** andrewbogott__af has joined #openstack-dev | 12:51 | |
*** bsza has joined #openstack-dev | 12:57 | |
*** dprince has joined #openstack-dev | 13:07 | |
*** markvoelker has joined #openstack-dev | 13:09 | |
*** rickfoosusa has joined #openstack-dev | 13:20 | |
*** jeroenhn has quit IRC | 13:21 | |
*** rickfoosusa has quit IRC | 13:22 | |
*** Remco_ has quit IRC | 13:25 | |
*** berendt has quit IRC | 13:35 | |
zul | morning | 13:42 |
*** jeroenhn has joined #openstack-dev | 13:42 | |
*** lts has joined #openstack-dev | 13:51 | |
*** stuntmachine has joined #openstack-dev | 13:56 | |
*** mattray has joined #openstack-dev | 13:57 | |
*** berendt has joined #openstack-dev | 14:02 | |
*** jeroenhn has quit IRC | 14:04 | |
*** doude has joined #openstack-dev | 14:06 | |
doude | Hi all, someone can explain me how works the 'Simple Match' authorization policy in Keystone ? | 14:07 |
doude | or point out a documentation | 14:08 |
*** kbringard has joined #openstack-dev | 14:12 | |
*** jeroenhn has joined #openstack-dev | 14:17 | |
*** shang has quit IRC | 14:22 | |
*** ayoung has joined #openstack-dev | 14:23 | |
*** zykes_ has quit IRC | 14:34 | |
*** stuntmachine has quit IRC | 14:35 | |
*** shang has joined #openstack-dev | 14:36 | |
*** stuntmachine has joined #openstack-dev | 14:43 | |
*** sandywalsh has quit IRC | 14:43 | |
*** littleidea has joined #openstack-dev | 14:44 | |
*** deshantm has joined #openstack-dev | 14:45 | |
annegentle | can an admin add Pete Johnson to openstack-cla? https://launchpad.net/~openstack-cla/+members#proposed | 14:46 |
annegentle | also I need David Mortman added to openstack-cla | 14:47 |
*** ewindisch has joined #openstack-dev | 14:52 | |
ewindisch | hi | 14:52 |
*** blamar_ has quit IRC | 14:56 | |
annegentle | mtaylor jaypipes soren vishy ttx jeblair ^^ need some housekeeping on the openstack-cla list | 14:57 |
annegentle | pretty please :) | 14:57 |
*** ncode has joined #openstack-dev | 14:58 | |
*** ncode has joined #openstack-dev | 14:58 | |
ttx | annegentle: looking | 14:58 |
*** RobertLaptop has joined #openstack-dev | 14:58 | |
annegentle | ttx: thanks | 14:59 |
annegentle | Pete Johnson and David Mortman are my two confirmed | 14:59 |
*** blamar has joined #openstack-dev | 15:00 | |
ttx | annegentle: done | 15:01 |
annegentle | ttx: appreciate it | 15:01 |
*** dneary has quit IRC | 15:02 | |
*** kbringard has quit IRC | 15:04 | |
*** kbringard has joined #openstack-dev | 15:05 | |
*** joesavak has joined #openstack-dev | 15:12 | |
*** dubsquared has joined #openstack-dev | 15:12 | |
*** yamahata___ has joined #openstack-dev | 15:18 | |
*** Remco_ has joined #openstack-dev | 15:20 | |
*** dtroyer has quit IRC | 15:29 | |
*** dolphm has joined #openstack-dev | 15:32 | |
YorikSar | Hello! Can anyone review this change: https://review.openstack.org/1416 | 15:38 |
YorikSar | It hangs there for some time already. | 15:39 |
*** Gordonz has joined #openstack-dev | 15:42 | |
YorikSar | There is quite a mess with patchsets, #5 has some inline comments and #6 was approved by vishy | 15:42 |
*** zzed has joined #openstack-dev | 15:43 | |
*** deshantm_ has joined #openstack-dev | 15:45 | |
*** deshantm has quit IRC | 15:48 | |
*** deshantm_ is now known as deshantm | 15:48 | |
*** map_nw has joined #openstack-dev | 15:52 | |
*** andrewbogott__af is now known as andrewbogott_ | 15:55 | |
*** andrewbogott_ has joined #openstack-dev | 15:55 | |
*** andrewbogott_ is now known as andrewbogott | 15:56 | |
*** reed has joined #openstack-dev | 15:57 | |
*** ghe_rivero has joined #openstack-dev | 16:00 | |
*** berendt has quit IRC | 16:02 | |
*** davlap has joined #openstack-dev | 16:07 | |
*** jperkin_ has left #openstack-dev | 16:08 | |
*** shang has quit IRC | 16:09 | |
*** dolphm has quit IRC | 16:11 | |
*** kbringard has quit IRC | 16:11 | |
*** shang has joined #openstack-dev | 16:12 | |
*** Remco_ has quit IRC | 16:12 | |
*** jeroenhn has quit IRC | 16:12 | |
*** yamahata___ has quit IRC | 16:14 | |
*** dolphm has joined #openstack-dev | 16:19 | |
*** dolphm has quit IRC | 16:23 | |
*** dolphm has joined #openstack-dev | 16:24 | |
tr3buchet | ttx: just read http://fnords.wordpress.com/2012/02/21/open-dev-releases-quality/ | 16:25 |
tr3buchet | +1 :) | 16:25 |
*** jdg has joined #openstack-dev | 16:25 | |
ttx | tr3buchet: cool :) | 16:25 |
*** dneary has joined #openstack-dev | 16:28 | |
*** dneary has quit IRC | 16:28 | |
*** dneary has joined #openstack-dev | 16:28 | |
*** danwent has joined #openstack-dev | 16:29 | |
*** mdomsch has joined #openstack-dev | 16:30 | |
*** ncode has quit IRC | 16:30 | |
*** kbringard has joined #openstack-dev | 16:36 | |
*** jaypipes has quit IRC | 16:39 | |
*** apevec has quit IRC | 16:42 | |
*** maplebed has joined #openstack-dev | 16:44 | |
*** andrewsmedina has quit IRC | 16:46 | |
*** dolphm has quit IRC | 16:49 | |
*** andrewsmedina has joined #openstack-dev | 16:50 | |
jdg | Has anybody else seen devstack prompting for sudo passowrd lately? | 16:51 |
jdg | I was having trouble creating instances and volumes, when watching screen I noticed I'm getting prompts | 16:52 |
*** dolphm_ has joined #openstack-dev | 16:55 | |
bcwaldon | jdg: yeah, I was seeing it in just the last screen window, and my ability to boot instances wasnt affected | 16:55 |
kbringard | are any of the debian package maintainers here? | 16:56 |
jdg | bcwadlon: Strange, it seems intermittent. Guess I'll just keep an eye on it and see if i can find a pattern. | 16:57 |
jdg | At least it's not just me then :) | 16:57 |
LinuxJedi | kbringard: try #openstack-packaging | 16:57 |
kbringard | thanks LinuxJedi | 16:57 |
bcwaldon | jdg: ok, I was using a vanilla 11.10 box with a user I created a added to sudo | 16:57 |
*** andrewbogott has quit IRC | 16:57 | |
*** andrewbogott has joined #openstack-dev | 16:59 | |
*** andrewbogott has joined #openstack-dev | 16:59 | |
jdg | bcwaldon: Pretty much the same setup here, for now maybe I'll just add my user to sudoers with no password required. And later try to figure out why. | 16:59 |
*** cp16net has joined #openstack-dev | 16:59 | |
*** Daviey has quit IRC | 17:02 | |
*** n0ano has quit IRC | 17:05 | |
ewindisch | russellb: here? | 17:05 |
*** cp16net has quit IRC | 17:06 | |
*** nati2 has joined #openstack-dev | 17:06 | |
*** nikhil_ has quit IRC | 17:07 | |
*** nikhil_ has joined #openstack-dev | 17:07 | |
*** ghe_rivero is now known as ghe_ubuntu | 17:08 | |
*** reidrac has quit IRC | 17:08 | |
*** ghe_ubuntu is now known as ghe_rivero | 17:08 | |
andrewbogott | jdg: Yes, that's happening to me a lot, especially in nova-volume. I have to tab through all my screens periodically and make sure nothing's blocked by a password prompt. | 17:09 |
*** zzed_ has joined #openstack-dev | 17:09 | |
*** cp16net has joined #openstack-dev | 17:09 | |
*** sleepsonthefloo has joined #openstack-dev | 17:09 | |
andrewbogott | I tried using nova-rootwrap but it didn't seem to help | 17:10 |
*** Daviey has joined #openstack-dev | 17:10 | |
jdg | andrewbogott: Ok, exactly the same thing. Once I finsih what I'm working on now I'll see if I can find a way to "fix" it. Seems kinda strange. | 17:12 |
*** markmc has quit IRC | 17:12 | |
*** zzed has quit IRC | 17:12 | |
*** zzed_ is now known as zzed | 17:12 | |
andrewbogott | jdg: I poked at it a while over the weekend and gave up and decided to live with it. You'll make my day if you find a solution. | 17:13 |
jdg | andrewbogott: Temporarily I'm going to try adding my user to sudoers with NOPASSWD the next time I restart. If I figure something more out I'll let you know. | 17:14 |
andrewbogott | jdg: Yeah, that's a valid approach. I can't do that because my sudoers is automatically refreshed by puppet. | 17:14 |
jdg | DOH!!! | 17:14 |
Ryan_Lane | andrewbogott: can stick it into /etc/sudoers.d | 17:17 |
Ryan_Lane | which devstack should be doing anyway :) | 17:17 |
andrewbogott | Hm... | 17:17 |
andrewbogott | That is an obvious, yet good, suggestion. | 17:18 |
Ryan_Lane | devstack really shouldn't edit the sudoers file on systems that support sudoers.d, unless sudoers.d is disabled | 17:18 |
*** corXi has quit IRC | 17:19 | |
jdg | Ryan_Lane: Any thoughts on having a specific stack user added to sudoers.d with no password in stack.sh? | 17:19 |
Ryan_Lane | sounds reasonable to me | 17:20 |
jdg | Ahh.. looks like it it already set there... hmm. | 17:20 |
jdg | Just missing some commands perhaps | 17:21 |
andrewbogott | It says andrew ALL = (root) NOPASSWD: SETENV: NOVADEVCMDS | 17:21 |
andrewbogott | that means that NOVADEVCMDS is defined someplace, and that's the set of things I can do w/out a password? | 17:21 |
jdg | andrewbogott: The NOVADEVCMDS should be defined in that file as well | 17:22 |
* andrewbogott nods | 17:22 | |
jdg | And Yes, that's the set of things you're allowed to do with NOPASSWD | 17:22 |
*** andrewsmedina has quit IRC | 17:23 | |
jdg | andrewbogott: So for iscsi volumes tgtadm needs added | 17:24 |
andrewbogott | ok, should be easy to fix this then. | 17:24 |
jdg | I don't know what I am missing for Nova instances yet because I have no buffer in my screen :( | 17:24 |
andrewbogott | You know about ctrl-a [ ? | 17:25 |
jdg | andrewbogott: Oh WONDERFUL!!!! | 17:25 |
andrewbogott | Then you can use arrow-keys. And ctrl-a ] to exit the mode. | 17:25 |
andrewbogott | I think it's meant for cut-n-paste but I only ever use it for scrolling. | 17:25 |
openstackgerrit | Verification of a change to openstack/nova failed: Scheduler notifications added. https://review.openstack.org/4194 | 17:26 |
jdg | AWESOME!! Thank you! I finally just started using screen instead of screwing around tyring to convert to upstart etc | 17:26 |
Ryan_Lane | I use ctrl-a esc, then page-up/page-down (or ctrl-f, ctrl-b) | 17:26 |
jdg | It's actually much easier once you quit fighting it :) | 17:26 |
*** maploin has quit IRC | 17:27 | |
Ryan_Lane | esc again to leave the buffer | 17:27 |
jdg | Ryan_lane: This is turning out to be a very productive morning for me. :) | 17:27 |
*** Mkenneth has quit IRC | 17:27 | |
andrewbogott | Pretty sure my keyboard doesn't have a page-up. although there's probably some lucky keycombination for that. | 17:27 |
Ryan_Lane | I didn't even know ctrl-[ worked :) | 17:27 |
Ryan_Lane | yeah, ctrl-f, ctrl-b are page-up, page-down | 17:27 |
andrewbogott | Hm... is there a mnemonic for that or are those letters just picked at random? | 17:28 |
Ryan_Lane | forward, and back | 17:28 |
andrewbogott | v | 17:28 |
andrewbogott | versus 'previous' and 'next' which do something else :/ | 17:28 |
Ryan_Lane | heh | 17:28 |
andrewbogott | Of course, I use vi so I can't ever, ever complain about arbitrary key assignments. | 17:29 |
Ryan_Lane | :D | 17:29 |
jdg | :) | 17:29 |
*** reidrac has joined #openstack-dev | 17:29 | |
jdg | Come on p/n/w/q/s vi makes perfect sense :) | 17:29 |
*** reidrac has left #openstack-dev | 17:30 | |
andrewbogott | jdg: Hm... looks to me like devstack rewrites that file on startup. So we'll need to make a copy | 17:31 |
*** andrewsmedina has joined #openstack-dev | 17:32 | |
*** blamar has quit IRC | 17:32 | |
*** mnewby has joined #openstack-dev | 17:33 | |
andrewbogott | oh crap! Ryan_Lane: The problem was never that devstack was altering sudoers. It's that if there's a parse error in one of the sudoers.d files then sudo errors out. | 17:33 |
Ryan_Lane | :D | 17:33 |
jdg | adrewboggott: I was thinking of adding the "extras" in stack.sh and resubmitting back to git repo | 17:33 |
andrewbogott | And, having just modified a sudoers.d file, I have learned this | 17:33 |
*** blamar has joined #openstack-dev | 17:33 | |
Ryan_Lane | I can see that :) | 17:33 |
andrewbogott | jdg: That's fair. I'm working on a custom volume driver so I have to add extra stuff anyway. | 17:33 |
jdg | LOL... we're doing the same thing it sounds like. I have a list :) | 17:34 |
andrewbogott | um... what file system? | 17:34 |
andrewbogott | Ryan_Lane: Can you use your omniscient might to change /etc/sudoers.d/stack_sh_nova_andrew so that I can edit it? | 17:35 |
jdg | andrewbogott: Just a basic volume driver of SolidFire devices. Now I"m trying to figure out the remount bug/issue in Luanchpad | 17:35 |
* Ryan_Lane nods | 17:35 | |
andrewbogott | thanks. | 17:35 |
Ryan_Lane | which instance? | 17:35 |
andrewbogott | driver-dev | 17:35 |
*** dtroyer has joined #openstack-dev | 17:35 | |
openstackgerrit | Verification of a change to openstack/nova failed: Update api-paste.ini with new auth_token settings. https://review.openstack.org/4016 | 17:36 |
Ryan_Lane | just remove it? | 17:36 |
andrewbogott | chown andrew so I can fix it | 17:36 |
Ryan_Lane | ah | 17:36 |
Ryan_Lane | done | 17:36 |
andrewbogott | Although maybe sudo won't tolerate a file that isn't owned by root... we'll see. | 17:36 |
Ryan_Lane | it doesn't ;) | 17:37 |
andrewbogott | It warns but doesn't fail. | 17:38 |
*** ramyao has joined #openstack-dev | 17:38 | |
*** sandywalsh has joined #openstack-dev | 17:40 | |
*** n0ano has joined #openstack-dev | 17:40 | |
*** berendt has joined #openstack-dev | 17:40 | |
berendt | can somebody fix the build of the glance tarball on jenkins? it's broken since weeks | 17:40 |
*** ramyao has left #openstack-dev | 17:42 | |
*** anotherjesse has joined #openstack-dev | 17:43 | |
*** jog0 has joined #openstack-dev | 17:44 | |
*** map_nw has quit IRC | 17:46 | |
berendt | how can i create a pdf of the documents provided in the repository compute-api? | 17:49 |
annegentle | berendt: install maven, then run mvn clean generate-sources in the directory that contains the pom. See http://wiki.openstack.org/Documentation/HowTo | 17:50 |
berendt | annegentle: thank you | 17:50 |
annegentle | berendt: the PDF ends up in the target/webhelp directory since the pom file copies it out of the PDF dir into the webhelp dir | 17:50 |
*** utlemming has quit IRC | 17:52 | |
*** utlemming has joined #openstack-dev | 17:52 | |
*** zzed has quit IRC | 17:52 | |
*** jdurgin has joined #openstack-dev | 17:52 | |
berendt | urgs.. have to install a lof of stuff for maven :( (Install 225 Packages) | 17:52 |
*** ghe_rivero has quit IRC | 17:53 | |
*** zzed has joined #openstack-dev | 17:54 | |
*** cp16net_ has joined #openstack-dev | 17:55 | |
*** cp16net has quit IRC | 17:56 | |
*** cp16net_ is now known as cp16net | 17:56 | |
*** derekh has quit IRC | 17:57 | |
*** shang has quit IRC | 17:57 | |
*** doude has quit IRC | 17:58 | |
*** hub_cap has joined #openstack-dev | 17:58 | |
*** rods has quit IRC | 17:59 | |
*** shevek_ has quit IRC | 18:00 | |
*** stuntmachine has quit IRC | 18:01 | |
*** stuntmac_ has joined #openstack-dev | 18:01 | |
*** heckj has joined #openstack-dev | 18:03 | |
*** mattstep has quit IRC | 18:03 | |
*** mattstep has joined #openstack-dev | 18:04 | |
*** gyee has joined #openstack-dev | 18:05 | |
openstackgerrit | Verification of a change to openstack/nova failed: Extract get_network in quantum manager https://review.openstack.org/4093 | 18:06 |
*** pixelbeat has quit IRC | 18:07 | |
mortman | thanks annegentle :-) | 18:15 |
*** joesavak has quit IRC | 18:17 | |
*** jakedahn has joined #openstack-dev | 18:20 | |
*** lts has quit IRC | 18:23 | |
zykes | anotherjesse, here ? | 18:29 |
zykes | or danwent ? | 18:29 |
*** adjohn has joined #openstack-dev | 18:29 | |
anotherjesse | I am (currently focusing on the keystone in #openstack-meeting) | 18:29 |
zykes | ah ok | 18:29 |
danwent | zykes: what's up? sounds like I am the second choice :) | 18:30 |
*** zigo-_- has quit IRC | 18:30 | |
zykes | danwent, done anything with the DNS stuff ? | 18:30 |
danwent | zykes: nope, wasn't planning on doing any DNS stuff. Though I imagine you saw the wikimedia patch that went into nova a while back (automatically adding DNS entries for allocated IPs) | 18:31 |
zykes | i meant more for DNSaaS | 18:31 |
kbringard | is the preferred Ubuntu for running diablo-stable 11.10? | 18:32 |
danwent | zykes: yeah, no plans on that front. | 18:32 |
kbringard | for a "production" environment | 18:32 |
zykes | danwent, why not ? :p | 18:32 |
danwent | zykes: no time. | 18:32 |
zykes | ah | 18:32 |
zykes | hire me ;Ã¥p | 18:33 |
danwent | zykes: perhaps I gave you the wrong impression, but I was actually never planning on working on DNSaaS | 18:33 |
*** gyee has quit IRC | 18:33 | |
danwent | zykes: now if you want to work on other quantum stuff, perhaps :) | 18:33 |
ewindisch | russellb: here? | 18:34 |
zykes | hmmm, ttx here ? | 18:34 |
russellb | ewindisch: hey, yep | 18:34 |
russellb | ewindisch: so i guess the exception thing was the unit test problem? | 18:34 |
ewindisch | russellb: yes, I fixed it in the latest patch | 18:35 |
*** gyee has joined #openstack-dev | 18:35 | |
russellb | ewindisch: cool. | 18:36 |
ewindisch | I have another patch that fixes all the i18n issues (in debugging). Otherwise, I'm still searching for feedback. The patch needs to come through today, if it is to make essex. | 18:36 |
russellb | cool, well at this point I don't really have any objections, since it's sell contained. I'm not in nova-core though, so I can't approve. | 18:37 |
russellb | why is the new service needed btw? the reply service? | 18:37 |
*** Ryan_Lane has quit IRC | 18:37 | |
russellb | did you need it to implement the timeout, or something else? | 18:37 |
ewindisch | because we don't have a return path to the caller. | 18:38 |
ewindisch | when you do rpc.cast(), I don't know who you are or how to find you. | 18:38 |
russellb | rpc.call() you mean? | 18:39 |
ewindisch | well, rpc.call() is a pair of casts here. | 18:39 |
ewindisch | so the replies are cast() to the reply service and it publishes to an IPC queue. A call() blocks, subscribed to the IPC queue, until the reply message arrives. | 18:40 |
russellb | ok. | 18:43 |
*** bengrue has joined #openstack-dev | 18:48 | |
*** Remco_ has joined #openstack-dev | 18:50 | |
russellb | ewindisch: so this IPC queue ... "ipc:///tmp/zmq_reply_queue" ... is that creating a unix socket in tmp? | 18:51 |
*** lts has joined #openstack-dev | 18:51 | |
*** adjohn has quit IRC | 18:51 | |
ewindisch | yes. It isn't ideal, but I couldn't figure out another way of handling return casts without more data passed into call() | 18:52 |
russellb | well i was just thinking of suggesting /var/run/openstack-nova/ or something instead of /tmp | 18:52 |
russellb | using /tmp is kind of evil from a security perspective :) | 18:53 |
ewindisch | reasonable. | 18:53 |
russellb | ok I think I'm done with comments for real now, heh | 18:56 |
*** Mandell has quit IRC | 18:57 | |
russellb | ewindisch: i guess ping the ML in response to your FFE thread asking for reviews to see if you can get it in? | 18:58 |
*** jog0_ has joined #openstack-dev | 18:58 | |
ewindisch | russellb: I already emailed vish, and everyone on the review is already there. I'm making that ipc change now, and I'll upload that with the i18n fixes. | 18:59 |
russellb | cool, sounds good | 19:01 |
russellb | there's also the project meeting today where you could bring it up | 19:01 |
*** jog0 has quit IRC | 19:01 | |
*** jog0_ is now known as jog0 | 19:01 | |
heckj | markmc: ping? | 19:02 |
*** heckj has quit IRC | 19:02 | |
*** heckj has joined #openstack-dev | 19:02 | |
*** viraptor has quit IRC | 19:02 | |
*** shang has joined #openstack-dev | 19:03 | |
*** Mandell has joined #openstack-dev | 19:03 | |
zul | anotherjesse: ping https://review.openstack.org/#change,4351 | 19:04 |
*** Drakiz has joined #openstack-dev | 19:05 | |
heckj | zul: lookin' | 19:06 |
heckj | zul: approved | 19:07 |
zul | heckj: thanks | 19:07 |
*** darraghb has quit IRC | 19:07 | |
heckj | dprince: ping | 19:08 |
*** RobertLaptop has left #openstack-dev | 19:11 | |
anotherjesse | heckj: termie and I communicated, and he will summarize our stance on default tenants | 19:11 |
termie | heckj: hola, here's our thoughts | 19:12 |
dprince | heckj: hello | 19:12 |
heckj | dprince: just commented on a couple of your change requests - tweaking setup.py | 19:12 |
heckj | termie: shoot! | 19:12 |
dprince | heckj: SUre. I already approved zul's MANIFEST.in patch... | 19:13 |
dprince | heckj: So my patch in combination with his makes this work. | 19:13 |
termie | heckj: so, the existing api has been traditionally difficult to understand in that it allows two different types of responses from the same endpoint, at current nearly all calls in all systems require a tenant (and the couple that don't won't be hurt by it being present), so we think it'd be best to standardize on that call always returning a tenant or an error | 19:13 |
heckj | Ah - got it, missed that. | 19:13 |
heckj | dprince: ^ | 19:13 |
dprince | heckj: ack | 19:14 |
heckj | termie: 100% agreement there | 19:14 |
*** pixelbeat has joined #openstack-dev | 19:14 | |
termie | heckj: in the cases where a default tenant might be difficult the implementation can decide what it would like to do to pick one or whather to throw an error | 19:14 |
termie | heckj: always accepting that a tenant can also be passed in to make the choice explicit | 19:15 |
heckj | termie: seems reasonable | 19:15 |
heckj | termie: how does that play into tokens, and do we want to support the strange condition where a user is defined without a tenant? | 19:16 |
termie | heckj: tokens always have a tenant, no more unscoped tokens, and a user without a tenant can't do anything so we'd return an authentication error | 19:16 |
heckj | termie: I'd prefer to assert something that setting that up isn't valid - that a user must always be created in a baseline sense assocaited at least to a single tenant | 19:16 |
heckj | termie: sounds like we're on the same page | 19:16 |
termie | heckj: we felt that you should still be allowed to create a user without a tenant, (for example if importing a user base) but then they have to be associated with one before they can log in | 19:17 |
termie | s/log in/authenticate/ | 19:17 |
heckj | that seems reasonable - and a good use case. | 19:17 |
* heckj notes to add that in.. | 19:17 | |
termie | heckj, anotherjesse: some other things that popped to mind from a ux standpoint, 1) we could return a list of valid tenants with the error message if no tenant was defined | 19:18 |
*** pixelbeat has quit IRC | 19:18 | |
termie | heckj, anotherjesse: 2) we could make a configurable default default tenant | 19:18 |
termie | the second would only be useful for simple systems, but might add too much confusion | 19:19 |
heckj | termie: at a minimum, I'd like to see a log message (log.ERROR) with a notice that the user attemped to auth and was denied because didn't have an assocaited tenant | 19:19 |
anotherjesse | ayoung: is the ldap work you are doing support specification of default tenant? | 19:19 |
termie | the first doesn't really have a precendent in the system yet | 19:19 |
*** spinningcog has joined #openstack-dev | 19:19 | |
ayoung | anotherjesse, I'm not quite sure how to model it | 19:19 |
heckj | termie: I like (2)- but I can see a few use cases where you wanted want that automatically | 19:20 |
heckj | god I suck at typing reasonable sentences, lemme try that again ^ | 19:20 |
termie | heckj: s/wanted/wouldn't/g | 19:20 |
termie | ? | 19:20 |
spinningcog | Anyone know what happened to the sampledata that used to be bundled with keystone? | 19:20 |
heckj | termie: I like the option 2, but know that some implementations wouldn't want that. i.e. to your point of being configurable, is good. | 19:21 |
heckj | spinningcog: it's moved into devstack entirely | 19:21 |
anotherjesse | heckj / termie - going with option 2 would mean a change to the API, client libraries, horizon, ... | 19:21 |
termie | spinningcog: there is a bug open asking that it be provided in keystone again though | 19:21 |
termie | anotherjesse: that's number 1 | 19:22 |
heckj | anotherjesse: yeah, probably not somehting we should do before folsom, but I'd like to consider for the v.next API discussion | 19:22 |
heckj | spinningcog: https://github.com/openstack-dev/devstack/blob/master/files/keystone_data.sh at the moment. | 19:22 |
termie | anotherjesse: agreed, i don't mean to make that data for the computer, but rather to display in the error text | 19:22 |
spinningcog | it makes sense to me that it should be included with keystone since the documentation for exercising the service/admin API's expects it to be available. | 19:22 |
ewindisch | russellb: yeah… time is tight. vish wanted it before today's meeting. | 19:23 |
spinningcog | thanks for letting me know where it is :) | 19:23 |
termie | spinningcog: https://bugs.launchpad.net/keystone/+bug/934331 | 19:23 |
uvirtbot` | Launchpad bug 934331 in keystone "create a sample-data script for quick development use" [Medium,Confirmed] | 19:23 |
ewindisch | just uploaded a new patch. Maybe vish will review soon. ;-) | 19:23 |
termie | anotherjesse: as in, just a ux thing, not an api design thing | 19:24 |
heckj | termie: ++ | 19:24 |
* anotherjesse backs away from default tenant discussion - looks like you guys can handle it ;) | 19:24 | |
ayoung | spinningcog, if you run the unit tests, they populate a sqlite database with some sample data. I've had some success using that, too | 19:24 |
heckj | anotherjesse: HEY! Come back here | 19:24 |
heckj | ;-) | 19:24 |
*** zzed_ has joined #openstack-dev | 19:24 | |
anotherjesse | heckj: for sql/kvs I think having default tenant is the right thing | 19:25 |
*** zzed_ has quit IRC | 19:25 | |
heckj | termie - I hesitate to open this can of worms, but how do you suggestion I describe the relationship of roles in the current API. | 19:25 |
ayoung | anotherjesse, if that is the case, then LDAP, too | 19:25 |
anotherjesse | if you work with ayoung about how to model it in LDAP (perhaps it is just the first tenant or an attribute of the user?) | 19:25 |
termie | ayoung: you're in the most difficult of the default tenant stuff, what do you think about.... and anotherjesse just finished what i was going to say | 19:26 |
heckj | anotherjesse: I like the idea - it makes the UX experience much, much better | 19:26 |
anotherjesse | for clarification - right now dashboard & CLI are implemented assuming tenant is required to be specified | 19:26 |
ayoung | termie, well, I am trying to use the default schemas. My thinking is that we are most likely to be in the situation where the user list is not under out control | 19:26 |
ayoung | so lets try to come up with a solution if we can't add default tenant to the user record | 19:27 |
termie | heckj: i think sorta like this, tenants == resource, user == authentication credentials associated with various resources (tenants), roles == granular control of a resource (tenant) for given auth creds (user) | 19:27 |
anotherjesse | dashboard has a hack that lists all the tenants for the user and choses the first (with the idea eventually it could store your last used tenant at the dashboard layer and always default to that) | 19:27 |
ayoung | remember, this is for access to modify configuration for machines, not to access the machines themselves. I think explicit tenant specification is probably a good thing | 19:28 |
*** zzed has quit IRC | 19:28 | |
heckj | termie: at the moment, roles are being returned as words - keep with that setup until the next API, or do we want to try and explicitly document through the actions/capabilities/etc setup that was discussed back at Diablo summit? | 19:28 |
ayoung | If we can modify the use record, we have to figure out where to store the default tenant | 19:28 |
heckj | termie: I'm having trouble reconciling what we want to do, and when, with that past discussion and what's defined and available in V2 API | 19:29 |
termie | heckj: roles are being returned the way things expect them at the moment, but the name of a role itself is no longer interesting once rbac hits | 19:29 |
ayoung | heckj, actions etc probably don't belong in the IdM store | 19:29 |
termie | heckj: the roles just map to rulesets | 19:29 |
ayoung | ah..is all of that being pushed into Keystone? | 19:29 |
termie | heckj: and the rulesets are defined by the services | 19:29 |
*** cp16net has quit IRC | 19:29 | |
ayoung | rulesets and actions? | 19:29 |
termie | ayoung: i can point you at the policy stuff in nova | 19:30 |
ayoung | termie, thanks, please do | 19:30 |
heckj | termie - is this still relevant: http://etherpad.openstack.org/canhaz | 19:30 |
heckj | ? | 19:30 |
*** cp16net has joined #openstack-dev | 19:30 | |
termie | heckj: not vastly so since there is already a working implementation | 19:30 |
termie | https://github.com/openstack/nova/blob/master/nova/policy.py | 19:30 |
heckj | termie: kk - I'll dump that as a reference | 19:30 |
termie | and https://github.com/openstack/nova/blob/master/etc/nova/policy.json | 19:31 |
heckj | termie - what's your thinking for timing on "when RBAC hits"? | 19:31 |
*** zzed has joined #openstack-dev | 19:31 | |
termie | heckj: well, it's already there in nova, we just need to copy it over, i'd prefer to do it soon | 19:31 |
heckj | termie - can we pull it of prior to march 1st? | 19:31 |
termie | heckj: i think we might be able to, it will require a meeting or two to make sure we don't miss some controls we need | 19:32 |
heckj | termie - Ok, how can I help coordinate that? I'd like to get it in - not feeling like I know what the critical pieces are | 19:32 |
*** pixelbeat has joined #openstack-dev | 19:33 | |
termie | it feels pretty clear in my mind, but the default rules for how we modify keystone data are probably a bit wider-sweeping than just guessing at | 19:33 |
termie | heckj: so what is left to iron out, to me, is deciding who is allowed to modify, for example, which tenants a user is in (probably something like keystone:tenant_admin role can add the user), who can modify service info (because that is above tenant, possibly only keystone:admin could do that) | 19:34 |
*** hub_cap has quit IRC | 19:34 | |
termie | heckj: but i do think having an example set of code for it out is pretty critical | 19:35 |
termie | 'cause most people don't understand teh system on first glance | 19:35 |
termie | (it's the old double-pointer problem) | 19:35 |
heckj | termie: ++, I sure didn't - and I'm not sure I entirely get it now until I walk through it a few more times | 19:35 |
termie | i'm okay with taking on the initial bits, but it probably means updating aa decent amount of tests, because many of them have been naive to permissions | 19:36 |
heckj | termie: want to get a patch set for it and use that as a discussion piece with the code? We could either do a meeting based on that later this week or use next tuesday's keystone meeting for that discussion | 19:36 |
ayoung | termie, let me get this straight: we need to be able to have keystones back end record 1: resources in openstack, like glance servers, nova, and the like. 2. lists of actions on each one, and 3. assignments of roles that can perform those actions? | 19:36 |
termie | heckj: yeah, i'm expecting to be swamped in reviews and email today | 19:36 |
heckj | I figured you would be | 19:37 |
termie | ayoung: not exactly | 19:37 |
heckj | termie, ayoung: I figured we'd be driving that from a config file or such (i.e. policy.json) that we have for each service to start, build manipulating that into an API for the next rev of that API | 19:38 |
termie | ayoung: right now the services have their "actions" (we aren't using actions as a term as it is misleading since they are abstract rules that usually map to a specific action) | 19:38 |
ttx | zykes: yes ? | 19:38 |
termie | ayoung: keystone will only be handling the assignment of roles in this first rev | 19:38 |
zykes | ttx, is there any activity in the nordics ? | 19:38 |
ayoung | termie, assignment of a user to a role in a tenant, right? | 19:39 |
termie | ayoung: and deciding who can modify keystone data, with a set of code similar to policy.json | 19:39 |
termie | erm, policy.py | 19:39 |
termie | ayoung: yeah | 19:39 |
termie | ayoung: so for now, we're not doing anything to modify what rules exist in the api (that would be providing a policy service), so services are all managing their rules via config file | 19:40 |
dprince | heckj: thanks for sending my branch. One question though. Do keystone branches need 2 core approvals? Are we in a 'get-r-done' mode or something? | 19:41 |
ayoung | termie, so instead of adding in a new concept, we can make an administrative role for each tenant, and use that to manage tenant membership | 19:41 |
ttx | zykes: define activity | 19:41 |
termie | ayoung: and the services define which roles they care about by including a match for that role in their rules | 19:41 |
zykes | ttx, is there someone that's chatting about it from here ? | 19:41 |
termie | ayoung: that's my current thinking (though i don't know which new concept you're refering to) | 19:41 |
heckj | dprince: for most of the code, yes - two approvals, but I'm pushing to get some things out of the way quickly that seem relatively simple | 19:41 |
ayoung | termie, "actions" and the like | 19:41 |
ttx | zykes: I know of at least one developer in Denmark, if that counts as "activity in the nordics" | 19:42 |
termie | ayoung: there is no managing of rules | 19:42 |
termie | ayoung: only roles | 19:42 |
ayoung | so that still begets the question of who can manage the managers | 19:42 |
*** ncode has joined #openstack-dev | 19:42 | |
*** ncode has joined #openstack-dev | 19:42 | |
zykes | ah, i meant more like companies | 19:42 |
termie | ayoung: we'll have a static config file like policy.json for keystone | 19:42 |
termie | ayoung: that defines which conditions need to be matched for somebody to be allowed to change something | 19:42 |
ttx | soren: you had the name of a company working on OpenStack in Sweden, IIRC ? | 19:42 |
ttx | soren: if yes and you remember the name, cc zykes | 19:42 |
termie | ayoung: an example would be something like "to change the membership of this tenant" you need "to have the tenant_admin role within that tenant" | 19:43 |
ayoung | termie, OK, so the roles will be in the Identity backend, buyt how they are processed will be read out of a confi file | 19:43 |
ayoung | and changing rules would require a server restart | 19:43 |
termie | ayoung: only within keystone, they will be used differently by the services | 19:43 |
ayoung | termie, understood | 19:43 |
termie | ayoung: for the naivest implementation a server restart, sure, but that is not really an interesting problem | 19:44 |
*** Ryan_Lane has joined #openstack-dev | 19:44 | |
*** pixelbeat has quit IRC | 19:44 | |
termie | ayoung: you cna just reload the file often, if you wanted | 19:44 |
ayoung | termie, kill -HUP | 19:44 |
ayoung | reread the config file | 19:44 |
termie | ayoung: i am saying it isn't worth talking about whether a server restart is required for this, since it obviously is not as soon as we write something to load it without restart | 19:44 |
ayoung | right | 19:45 |
ayoung | OK...so what does it mean if someone is a member of a tenant, but they are not assigned to any roles in that tenant? | 19:45 |
termie | ayoung: doesn't mean anything unless some service thinks it should | 19:45 |
*** rods has joined #openstack-dev | 19:45 | |
termie | ayoung: i would expect a service like nova to allow stuff like "list instances" | 19:45 |
ayoung | termie, so by extension, a default tenant would mean even less | 19:46 |
termie | ayoung: unrleated | 19:46 |
termie | ayoung: default tenant != default tenant if you have no tenants, it means the default to choose from your available tenants if you don't specify one | 19:46 |
ayoung | termie, not really. if it means something, then a default tenant means something | 19:46 |
ayoung | termie, understood. Sounds like it really is a UI concept | 19:47 |
termie | ayoung: it is not a global default tenant, it just means which one gets picked of your existing tenants if you don't specify it on the authenticate call | 19:47 |
ayoung | or a default to be used for "list roles" if you don't specify "for which tenant" | 19:47 |
termie | ayoung: no | 19:47 |
termie | ayoung: only authenticate call, after that your token includes a tenant | 19:48 |
heckj | ayoung: "list roles" without specifying a tenant should result in an erro | 19:48 |
heckj | ayoung: but as termie mentions, as soon as you auth, you have a tenant against which you can apply that command as a default | 19:48 |
ayoung | heckj, better example would be List users | 19:48 |
heckj | ayoung: same, yeah | 19:49 |
ayoung | termie comment there is : NOTE(termie): I'd prefer if this listed only the users for a given | 19:49 |
ayoung | tenant. | 19:49 |
termie | ayoung: no calls are made without a tenant, your token has a tenant once you authenticate | 19:49 |
ayoung | termie, yes, I get it | 19:49 |
anotherjesse | termie: since you guys are chatting for a long time - I'm thinking of posting a bug about https://github.com/openstack/keystone/blob/master/tests/test_keystoneclient.py#L47 (setting roles should be done by role api not via metadata) | 19:49 |
termie | ayoung: whether calls do something specific based on your tenant is an api design issue (and an ugly leftover from legacy api design where it exists currently) | 19:49 |
termie | anotherjesse: yes pls, let's get rid of the old stuff | 19:50 |
ayoung | termie, so your preference would be to always specify Tenant for API calls? | 19:50 |
anotherjesse | termie: I hit that when I was exploring a zookeeper backend for keystone | 19:50 |
termie | ayoung: not exactly, depending on what you are talking about | 19:50 |
ayoung | termie, so not "always" bu "if the tenant id is relavant to the call" | 19:51 |
ayoung | but | 19:51 |
termie | ayoung: your tenant _will_ always be specified by your token, when you list users for a tenant i think you should include the tenant you want to list users for | 19:51 |
termie | ayoung: rather than have the call be contextually scoped to who you are acting as | 19:51 |
ayoung | right...that is what I was trying to say...for calls where the result set is scoped to the tenant | 19:51 |
zykes | offtopic question, is anyone hiring developers ? :) | 19:51 |
heckj | anotherjesse: ++ | 19:51 |
termie | ayoung: then we're tentatively in agreement, i'm still not sure we're talking about the same thing since you've talked abotu what appears to be 3 different hings in close successsion | 19:52 |
ayoung | sorry | 19:53 |
heckj | ayoung: I think you're on the right page | 19:53 |
anotherjesse | termie / heckj - https://bugs.launchpad.net/keystone/+bug/938103 | 19:53 |
uvirtbot` | Launchpad bug 938103 in keystone "don't set roles via metadata in backend api " [Undecided,New] | 19:53 |
ayoung | termie, they are related, though | 19:53 |
termie | ayoung: (or in agreeement about what i am saying at least, not necessarily on the stuff being discussed) | 19:53 |
ttx | zykes: I think most companies around here are. | 19:53 |
ttx | zykes: http://www.openstack.org/jobs/ | 19:53 |
zykes | overseas as well ? : ) | 19:53 |
termie | ayoung: i'll list that under subjected relatedness ;) | 19:53 |
termie | s/subjected/subjective/ | 19:53 |
termie | ayoung: one thing is related to who is allowed to do things, another is related to how you determine who you are, another is related to how you determine who you are talking about when making api calls | 19:54 |
ayoung | termie, still thinking about whether default tenant should be specified in authentication. If we change the APIs such that they are never modified by the callers tenant ID, then I don't think it is | 19:55 |
termie | ayoung: that is only for api calls within keystone, the other services still need to know which tenant you are | 19:55 |
ayoung | termie, tenant ID is this implicit context in calls. It becomes necessary when 1. calls need to be scoped to tenants and 2. authenticate calls don't allow you to specify tenant | 19:55 |
soren | ttx: Err... No, that doesn't ring a bell at all. | 19:56 |
ayoung | for example, basic auth, or kerberso for that matter | 19:56 |
ewindisch | does gerrit automatically install anything in pip-requires? | 19:56 |
*** mdomsch has quit IRC | 19:56 | |
termie | ayoung: again, that is not something that matters to other services, they are agnostic to keystone internal structure and require a specific tenant | 19:57 |
termie | ayoung: inside keystone it is still useful to have a token be scoped to a tenant so that we can determine if that user has permissions on that tenant without an additional look up | 19:57 |
ayoung | termie, so would default tenant be solely for Keystone use? | 19:57 |
termie | ayoung: the goal of having the tenant be specified in calls like list_users would be to make it easier for an admin user to list the users for another tenant | 19:58 |
termie | ayoung: the default tenant is how we specify which of your tenants you are associated with if you do not provide a tenant, that is it, only | 19:58 |
ayoung | I should have types: sole for use with keystone | 19:58 |
termie | ayoung: all other systems respond exactly the same way | 19:58 |
termie | ayoung: they just get a token with a tenant attached | 19:58 |
termie | ayoung: same as they always have | 19:58 |
termie | s/always have/always eventually have/ | 19:59 |
heckj | heh | 19:59 |
*** hub_cap has joined #openstack-dev | 19:59 | |
termie | i gotta go eat pretty soon | 19:59 |
ayoung | termie, the reason I am making such a fuss is that I think the dominant use case will not support changing the user object | 20:00 |
heckj | termie: I'm good | 20:00 |
ayoung | one possibility is that we keep a shadow object in the local identity store, | 20:00 |
termie | ayoung: i don't understand that statement, could you elaborate? | 20:00 |
ayoung | termie, corporate LDAP | 20:01 |
termie | the previous one, not the shadow object, which is relatively understandable | 20:01 |
ayoung | Openstack is run in a lab | 20:01 |
ayoung | if you log in using keystione, you authenticate against corp LDAP, | 20:01 |
ayoung | but we keep a user object in the local LDAP, too | 20:01 |
termie | local ldap? | 20:01 |
ayoung | it "shadows" the corp ldap | 20:01 |
ayoung | termie, yes | 20:02 |
ayoung | local LDAP is for storing tenatns and roles | 20:02 |
ayoung | as well as assignments | 20:02 |
ayoung | and Keystone is allowed to modify it | 20:02 |
termie | why would we store that in ldap, rather than say, sql | 20:02 |
ayoung | termie, because LDAP will allow the passthrough to corporate to work seamlessly | 20:02 |
ayoung | fairly common approach | 20:02 |
termie | ayoung: so where is the "local" one living? | 20:03 |
ayoung | termie, remember, the virtual machines running in the ldap also need an Identity tore | 20:03 |
ayoung | store | 20:03 |
ayoung | termie, in the Lab | 20:03 |
ayoung | local LDAP is probably running on the same server as keystone | 20:03 |
termie | so you are referring to a case where the virtual machines are also using ldap as a login | 20:04 |
ayoung | termie, yeop | 20:04 |
ayoung | yep | 20:04 |
ayoung | but even ignoring hts, say we use SQL as the local | 20:04 |
ayoung | you still have the same general solution | 20:04 |
ayoung | authenticate to corporate LDAP, but keep a user record in the local SQL DB | 20:04 |
ttx | ewindisch: try asking jeblair or mtaylor | 20:05 |
termie | ayoung: alright, with you there, where does not being able to modify the user fit in? | 20:05 |
ewindisch | ttx: for now, I've just decided to toss the module out of pip-requires... | 20:06 |
ayoung | termie, I was assuming we would not have to keep a local user object | 20:06 |
*** jog0 has quit IRC | 20:06 | |
ayoung | that we would only fetch the user object from the corp LDAP | 20:06 |
*** jog0 has joined #openstack-dev | 20:06 | |
ayoung | I'd still prefer that | 20:06 |
ayoung | as, right now, the only thing we'd need to stick in the local user is the default tenant | 20:06 |
termie | ayoung: will corp not support tenants? | 20:06 |
ewindisch | vishy: if you can spare a moment to review the zeromq branch, I'd be grateful. | 20:07 |
termie | ayoung: i.e., will they always be stored locally | 20:07 |
ayoung | termie, if Corp is AD, changing the schema is prohibitive | 20:07 |
termie | ayoung: is that a yes or a no | 20:07 |
ayoung | termie, it is a no | 20:08 |
ayoung | with some caveats | 20:08 |
termie | ayoung: sorry, let me rephrase, do we have to support storing tenants locally | 20:08 |
ayoung | termie, yes | 20:08 |
ayoung | OK, let me try to be clearer | 20:08 |
termie | ayoung: what is the benefit of not caching a local copy of the user with additional data? we still auth against corp, but stack some more metadata locally | 20:09 |
termie | ayoung: if, in the common case, we aren't going to be able to get tenants out of the corp auth and still need to keep copies around | 20:09 |
ayoung | termie, we will always need to go to corp ldap to authenticate, as we will not be allowed to cache a copy of the password hash. | 20:10 |
ayoung | so the question is "do we really need to cache locally" | 20:10 |
ayoung | understand. | 20:10 |
ayoung | the tenants are in a different subtree in LDAP, and roles assignements are under them | 20:10 |
termie | ayoung: if we are already managing tenants locally then managing additional metadata does not seem weird | 20:10 |
ayoung | so right now, we don't really need the user subtree | 20:10 |
ayoung | termie, users are not under tentnats | 20:11 |
ayoung | all that the tenants have is a collection of roels | 20:11 |
ayoung | roles | 20:11 |
ayoung | roles have a list of users assigned to those roles | 20:11 |
ayoung | but that list is just a primary key | 20:11 |
ayoung | so, with corp LDAP, we don't need any user object locally | 20:11 |
termie | ayoung: but you do if you want to add additional data, like, default tenant | 20:12 |
ayoung | right | 20:12 |
termie | ayoung: so... we do need it | 20:12 |
ayoung | unless I can figure out another way, yes | 20:12 |
termie | ayoung: unless there is some other way to go about it | 20:12 |
termie | it doesn't seem like a problem to me though if we're already managing other stuff in there | 20:12 |
termie | we still auth against corp and then pull up our associated user | 20:13 |
ayoung | termie, what happens if we auth to corporate, and we don't have a local record? | 20:13 |
ayoung | we still don't have a default tenant | 20:13 |
termie | ayoung: yup, but we also don't even have tenants until people assign them | 20:13 |
ayoung | yes | 20:13 |
termie | ayoung: so there isn't an extra step, we're still referencing a user that exists in corp and probividing additional data (so far tenants and roles, and hopefully soon default tenant) | 20:14 |
termie | ayoung: the first tenant being assigned to can be its default, so we can handle it in that step | 20:15 |
ayoung | it really isn't a question until they have 2 or more | 20:15 |
openstackgerrit | Verification of a change to openstack/nova failed: Extract get_network in quantum manager https://review.openstack.org/4093 | 20:16 |
*** stuntmac_ has quit IRC | 20:16 | |
*** stuntmachine has joined #openstack-dev | 20:16 | |
termie | ayoung: well, you can either just pick the first tenant result every time as default | 20:16 |
termie | ayoung: or store the additional data | 20:16 |
ewindisch | russellb: I know your'e not core, but if you can mark a 'lgtm' I'd appreciate it (if you're okay with doing so, of course) | 20:16 |
termie | ayoung: i need to go eat though | 20:16 |
ayoung | termie, problem is, with LDAP, there is no ordering guarantees with queries | 20:16 |
ayoung | go eat | 20:16 |
russellb | ewindisch: k | 20:17 |
russellb | ewindisch: did you try it after moving to /var/run/nova/ ? I just wasn't sure if something was already creating that dir | 20:18 |
ewindisch | I did…. but I didn't run pep8, I had a spurious newline, so I've uploaded a new patch. | 20:18 |
*** dolphm_ has quit IRC | 20:19 | |
russellb | ok. | 20:19 |
*** dolphm has joined #openstack-dev | 20:19 | |
ewindisch | It does a mkdir, chown, chmod on the directory… for good measure | 20:19 |
wwkeyboard2 | I see a failure with this build https://jenkins.openstack.org/job/gate-nova-unittests/1130/console but no indication what the failure was | 20:20 |
*** wwkeyboard2 is now known as wwkeyboard | 20:20 | |
ewindisch | (which actually lead me to find some places where we might have unsafe use of os.mkdir in the code… should file some bug reports...) | 20:20 |
*** zykes- has joined #openstack-dev | 20:21 | |
*** zykes has quit IRC | 20:25 | |
*** mattray has quit IRC | 20:26 | |
*** davidkranz has joined #openstack-dev | 20:33 | |
*** dprince has quit IRC | 20:34 | |
russellb | ewindisch: last couple of tweaks noted in review, then I'll +1 it | 20:34 |
*** jaypipes has joined #openstack-dev | 20:35 | |
*** jaypipes has quit IRC | 20:36 | |
*** andrewsmedina has quit IRC | 20:36 | |
*** shang has quit IRC | 20:36 | |
*** jaypipes has joined #openstack-dev | 20:38 | |
termie | ayoung: so, i'd say then store it, we can update it with calls to update user | 20:39 |
ewindisch | russellb: updated. | 20:40 |
russellb | ewindisch: done | 20:42 |
russellb | nice work | 20:42 |
ewindisch | thanks | 20:42 |
*** andrewsmedina has joined #openstack-dev | 20:42 | |
*** joesavak has joined #openstack-dev | 20:45 | |
YorikSar | johan_-_: here? | 20:46 |
*** ncode has quit IRC | 20:47 | |
*** mikeyp has joined #openstack-dev | 20:49 | |
ayoung | termie, the thing is, I don't want to write a custom schema for Keystone. There are standard schema's shipped with the LDAP servers and I am using them with the knowledge that they are in the format that all other applications expect. If we were to do tenatns as posix groups, for example, then I would put the default tenant ID as the gid field in the posixUser object. | 20:49 |
ayoung | I've tried to write the LDAP code so that the end user can use their existing schema if they so desire | 20:50 |
anotherjesse | I have a silly launchpad question - is there a button I can click to see "open bugs" without "fix commited" being included? | 20:51 |
joesavak | jesse: try an advanced search: https://bugs.launchpad.net/keystone/+bugs?advanced=1 | 20:52 |
anotherjesse | joesavak: thx | 20:52 |
anotherjesse | seems like it would be a link by default - give me the list of stuff that needs to be done | 20:53 |
joesavak | i agree | 20:53 |
termie | ayoung: are we doing them as posix groups? are there other schemas we could add as different options? | 20:53 |
termie | ayoung: as in, if we can map it appropriately based on some standard schemas maybe we can just have a few different implementations based on those | 20:53 |
ayoung | termie, I am not doing them as posix groups | 20:54 |
ayoung | I went with a simpler schema | 20:54 |
anotherjesse | danwent or other quantum folks - can we get a review on https://review.openstack.org/#change,4242 | 20:54 |
ayoung | the tenants are "groupsOfNames" | 20:54 |
ayoung | the roles are "organizationalRoles" | 20:54 |
ayoung | and membership in the role is in the attribute roleOccupant | 20:54 |
danwent | anotherjesse: will do | 20:55 |
ayoung | termie, https://review.openstack.org/#patch,sidebyside,4362,1,keystone/identity/backends/ldap/role.py | 20:55 |
ayoung | line 40-ish | 20:55 |
termie | ayoung: i am just asking whether there are any other schemas that we can have code for that would solve this problem for some significant portion of users | 20:56 |
Ryan_Lane | unlikely | 20:56 |
ayoung | Ryan_Lane, I assume "unlikey" is in response to "other schemes"? | 20:57 |
termie | Ryan_Lane: welcome to the convo, we're trying to decide how to allow a user to make one of their tenants a default if they don't provide a tenant | 20:57 |
Ryan_Lane | I think ayoung's schema choice is appropriate | 20:57 |
Ryan_Lane | ah | 20:57 |
Ryan_Lane | hn | 20:57 |
Ryan_Lane | *hm | 20:57 |
termie | Ryan_Lane: options so far seem to be: store additional local user data | 20:57 |
Ryan_Lane | that's a good question | 20:57 |
Ryan_Lane | or add a default on their account, via some attribute | 20:58 |
termie | you guys wanna chat about it a little bit? i haven't even gotten to start reveiws or email yet | 20:58 |
ayoung | Ryan_Lane, so my assumption has been that for most uses people are not going to be able/want to modify the user record | 20:59 |
*** hashar has joined #openstack-dev | 20:59 | |
openstackgerrit | Verification of a change to openstack/nova failed: xenapi: nova-volume support for multiple luns https://review.openstack.org/4267 | 20:59 |
ayoung | so if we want user specific data, we need to handle it some other way | 20:59 |
*** markmc has joined #openstack-dev | 20:59 | |
*** hashar has quit IRC | 21:00 | |
*** hashar has joined #openstack-dev | 21:00 | |
*** zzed has quit IRC | 21:00 | |
Ryan_Lane | probably true | 21:00 |
Ryan_Lane | modifying the user account for this one specific case is kind of annoying | 21:00 |
ayoung | Ryan_Lane, agreed | 21:00 |
Ryan_Lane | is there any way around it, though? | 21:00 |
ayoung | and, if we state that they can modify it, it messes up the case where they have an existing LDAP install, and they want to use their existing user objects. Modiofying the schema ex-post-facto PITA | 21:01 |
ayoung | Ryan_Lane, probably | 21:01 |
*** zzed has joined #openstack-dev | 21:02 | |
ayoung | somethuing ugly like recording the default tenant for a user inside the Tenant tree somewhere | 21:02 |
Ryan_Lane | let's see what inetorguser has for this... | 21:02 |
ayoung | Ryan_Lane, so the question I have is, if we need to store this one piece of data, is it going to scope creep to "store configuration options for users" | 21:02 |
ayoung | Ryan_Lane, nothing pretty | 21:03 |
Ryan_Lane | :( | 21:03 |
ayoung | ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ em | 21:03 |
ayoung | ployeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ ini | 21:03 |
ayoung | tials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo | 21:03 |
ayoung | $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ pre | 21:03 |
ayoung | ferredLanguage $ userSMIMECertificate $ userPKCS12 ) ) | 21:03 |
Ryan_Lane | inetorgperson* that is | 21:03 |
ayoung | Ryan_Lane, posixAccount has MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) | 21:04 |
ayoung | MAY ( userPassword $ loginShell $ gecos $ description ) ) | 21:04 |
ayoung | but that is likely to be used for something else | 21:04 |
Ryan_Lane | not all ldap servers implement posixaccount, either | 21:05 |
Ryan_Lane | AD has it, but most people don't enable it | 21:05 |
Ryan_Lane | so, there's nothing inherently wrong in making a schema | 21:05 |
Ryan_Lane | as long as everyone knows it will be written once and hopefully never changed | 21:06 |
Ryan_Lane | unless it's changed in backwards compatible ways, and even then, very rarely | 21:06 |
ayoung | Ryan_Lane, yes, but I am not sure that this usage calls for it, and I'd prefer the simpler solution if it exists | 21:07 |
* Ryan_Lane nods | 21:07 | |
*** cp16net has quit IRC | 21:07 | |
*** hub_cap has quit IRC | 21:07 | |
*** cp16net has joined #openstack-dev | 21:07 | |
ayoung | if, OTOH hand this is essential, it really seems to me to be part of storing configuration information about the user, and we will have a wider array of values to store than just "default tenant" | 21:07 |
*** hub_cap has joined #openstack-dev | 21:07 | |
*** hub_cap has quit IRC | 21:08 | |
Ryan_Lane | yeah. we need to know what all of them are ahead of time, if that's the route to go | 21:10 |
Ryan_Lane | otherwise things become much more painful down the line | 21:10 |
ayoung | So, as you can see, I am little wary here | 21:10 |
*** stuntmachine has quit IRC | 21:11 | |
ayoung | seems to me that user preferences like that are really a Horizon issue, as that is far more likely to care about configuration options.... | 21:11 |
ayoung | Of course, they are going to want to store them in Keystone.... | 21:11 |
*** stuntmachine has joined #openstack-dev | 21:12 | |
*** apevec has joined #openstack-dev | 21:14 | |
ayoung | Ryan_Lane, I thin we can safely use the "Secretary" field of the inetorguser | 21:14 |
ayoung | does anyone even have secretaries any more? | 21:14 |
Ryan_Lane | heh | 21:15 |
Ryan_Lane | is it only horizon that cares about this? | 21:15 |
*** stuntmachine has quit IRC | 21:17 | |
*** zns has joined #openstack-dev | 21:18 | |
*** stuntmachine has joined #openstack-dev | 21:24 | |
*** bhall has joined #openstack-dev | 21:25 | |
*** davidkranz has quit IRC | 21:28 | |
*** mikeyp has quit IRC | 21:29 | |
wwkeyboard | looks like gate-nova-unittests is hosed, who should I notify? | 21:32 |
jk0 | mtaylor or jblair | 21:33 |
wwkeyboard | thanks, then I'll wait till after the meeting | 21:34 |
*** rackerjoe has joined #openstack-dev | 21:35 | |
russellb | ewindisch: i didn't think that change should affect your driver, since it's just nova.rpc.amqp .. | 21:42 |
ewindisch | russellb: it changes common. I'd need to check.. | 21:42 |
russellb | nah, common tests | 21:43 |
ewindisch | ah | 21:43 |
russellb | just removing some tests | 21:43 |
*** heckj has quit IRC | 21:45 | |
*** pixelbeat has joined #openstack-dev | 21:45 | |
*** heckj has joined #openstack-dev | 21:45 | |
*** eglynn__ has quit IRC | 21:45 | |
YorikSar | vishy: When can I bother you with Nexenta driver review? | 21:45 |
*** eglynn__ has joined #openstack-dev | 21:46 | |
vishy | never! | 21:46 |
vishy | :) | 21:46 |
vishy | it looks like there are still comments on your last patchset of the dependent review | 21:46 |
YorikSar | vishy: There is doubts on the exception handling in manager, but I believe that they are not too relevant here. | 21:47 |
YorikSar | vishy: If you can push foward that change too (one more time), it'd be great | 21:48 |
adam_g | is it currently possible to incrementally migrate a keystone sql backend? AFAICS, anything declared as part of a sql model in a backend driver will be created as part of migration v01. | 21:54 |
mikal | Oh, are we bothering vishy for code reviews? I should join the queue... | 21:55 |
anotherjesse | adam_g: not sure - maybe dolphm or termie knows | 21:56 |
anotherjesse | adam_g: assuming you are talking about the current branch | 21:56 |
adam_g | anotherjesse: yes | 21:56 |
adam_g | im looking at trying to add a sql backend for services, but the way in which migrations are handled seems strange | 21:57 |
*** nati2 has quit IRC | 21:58 | |
Ryan_Lane | ayoung: if only horizon needs default tenants, then can't we let horizon stick in into its daabase? | 21:58 |
ayoung | Ryan_Lane, I don't think that is the case | 21:58 |
ayoung | I think that default tenants are across the boards | 21:59 |
ayoung | where as other config options will be Horizon specific | 21:59 |
Ryan_Lane | ah | 21:59 |
termie | adam_g: that is the current case until we make a release | 22:00 |
*** stuntmachine has quit IRC | 22:00 | |
termie | adam_g: part of the release process will be to freeze those | 22:00 |
Ryan_Lane | ayoung: I can't think of a reasonable way to handle this, except for adding schema | 22:00 |
*** eglynn has joined #openstack-dev | 22:00 | |
*** pixelbeat has quit IRC | 22:01 | |
anotherjesse | zul: ubuntu might be interested in the patch to migrate users from nova's deprecated auth to keystone users | 22:01 |
adam_g | termie: gotcha, so if im adding a new table, just tack it onto the current models and not worry about a migration script? | 22:01 |
termie | adam_g: assuming it is a table we want ;) | 22:01 |
ayoung | Ryan_Lane, create a groupOfNames called defaultForUsers under the tenants | 22:01 |
ayoung | keystone will have to make sure a user is in exactly one | 22:02 |
Ryan_Lane | how to ensure a user doesn't get added in more than one? | 22:02 |
termie | adam_g: but yeah, you'll have to include it in that script if it is an extension | 22:02 |
ayoung | Ryan_Lane, brute force | 22:02 |
Ryan_Lane | heh | 22:02 |
anotherjesse | zul: there are reviews out if you want to read them https://review.openstack.org/#change,4334 and https://review.openstack.org/#change,4304 | 22:02 |
*** joesavak has quit IRC | 22:03 | |
ayoung | seriously, though, Keystone can assume responsiblity for setting this. If someone does an end run around keystone, the answer is non-determinisitc | 22:03 |
* Ryan_Lane nods | 22:03 | |
*** eglynn__ has quit IRC | 22:03 | |
Ryan_Lane | what if none is set at all? | 22:03 |
ayoung | Ryan_Lane, I expect that to be quite common. | 22:04 |
ayoung | Probably an error condition. | 22:04 |
*** gabrielhurley has joined #openstack-dev | 22:04 | |
ayoung | Ryan_Lane, an authenticate call made without an explicit tenant for a user that has no default tenant set will return HTTP 403 | 22:05 |
Ryan_Lane | ah ok | 22:05 |
Ryan_Lane | that sounds reasonable | 22:05 |
ayoung | Ryan_Lane, one possibility is | 22:05 |
ayoung | we use the member field of the Tenant to specify the users that have it as default | 22:06 |
ayoung | and then we use a role for users to specify access | 22:06 |
*** deshantm has quit IRC | 22:06 | |
Ryan_Lane | could we use a role as default? | 22:06 |
ayoung | so if we need a default role, we make organizationalRole cn=default. | 22:06 |
ayoung | Ryan_Lane, precisely | 22:06 |
Ryan_Lane | since roles sit under tenants, it could work to just add a defaulttenant role | 22:07 |
*** andrewsmedina has quit IRC | 22:07 | |
ayoung | I think it is the most elegant solution, then membership is really just another role | 22:07 |
Ryan_Lane | yeah | 22:08 |
ayoung | Ryan_Lane, when listing members of a tenant, we would find all roles, grap all of the attributes roleOccupant and then perform a unique-sort on the list | 22:08 |
*** cp16net has quit IRC | 22:09 | |
Ryan_Lane | hm. wait, you are saying tenant membership would be a role? | 22:10 |
Ryan_Lane | or that default tenant membership would be a role? | 22:10 |
ayoung | Ryan_Lane, both | 22:11 |
ayoung | Ryan_Lane, one role would be for general membership | 22:11 |
Ryan_Lane | so, the groupofnames tenant wouldn't have a list of members? | 22:11 |
ayoung | Ryan_Lane, seems a bit heavy handed, doesn't it? | 22:11 |
Ryan_Lane | no | 22:11 |
ayoung | Ah...so one role for general membership | 22:12 |
Ryan_Lane | it makes sense to have a tenant with a list of members, even if they have no roles | 22:12 |
ayoung | OK...so we don't use the member attribute | 22:12 |
ayoung | or we use it, and then make a default Role | 22:12 |
Ryan_Lane | why not? | 22:12 |
ayoung | and membership is the roleOccupant values of that role | 22:12 |
Ryan_Lane | lemme pastebin what I'm thinking | 22:13 |
*** troytoman-away is now known as troytoman | 22:13 | |
YorikSar | vishy: I wrote a little something on SnapshotIsBusy cnahge. I think, all other discussion should be held in some other change or thread. Can you approve it? | 22:15 |
*** zykes- has quit IRC | 22:15 | |
Ryan_Lane | ayoung: http://pastebin.com/qJCBn07c | 22:15 |
vishy | YorikSar: I will take a look soon | 22:15 |
vishy | YorikSar: still catching up on email from my 4 day vacation :) | 22:15 |
Ryan_Lane | ayoung: there's advantages to keeping a list of members in the tenant | 22:16 |
openstackgerrit | Verification of a change to openstack/nova failed: Avoid copying file if dst is a directory. https://review.openstack.org/4368 | 22:16 |
Ryan_Lane | here's one: http://pastebin.com/dMRT87gE | 22:16 |
Ryan_Lane | ayoung: ^^ now I can extend that tenant to also be a posix group, which can be used in instances that are connected to the same LDAP store | 22:17 |
ayoung | Ryan_Lane, OK, that works for me | 22:17 |
ayoung | I think that was what I was origianlly thinking | 22:17 |
Ryan_Lane | which is amazingly useful for private clouds | 22:17 |
ayoung | Ryan_Lane, OK, we are on the same sheet | 22:17 |
ayoung | of music | 22:17 |
Ryan_Lane | cool | 22:17 |
Ryan_Lane | that seems like a reasonable implementation | 22:18 |
jdg | Has anybody tried attaching iSCSI volumes in a devstack setup lately? | 22:18 |
ayoung | Ryan_Lane, now, for role, I am using organizationalRole. Any issue with that? | 22:18 |
Ryan_Lane | none that I can think of | 22:19 |
ayoung | we could, potentiall, use something differnet for default tenants | 22:19 |
ayoung | IE another group of names | 22:19 |
Ryan_Lane | true, but it makes searching harder | 22:19 |
*** ewindisch has quit IRC | 22:19 | |
ayoung | termie, would you have any issue with us using a role to identify the default tenants for a user? | 22:20 |
YorikSar | vishy: Looking forward to your comments. Unfortunately, time shift gives me not much time to interact here. | 22:20 |
anotherjesse | jdg: what is the issue you are seeing? | 22:20 |
*** zykes has joined #openstack-dev | 22:20 | |
jdg | anotherjesse: Not sure "exactly" yet, but the attach never happens, and I get an assert in nova-compute | 22:21 |
termie | ayoung: i haven't been apying attention to your convo but last i checked role was under tenant, so wouldn't you hvae to find the tenant first in order to find the role? | 22:21 |
*** nikhil__ has quit IRC | 22:21 | |
termie | ayoung: i'm okay with a hack where you have a role that gets filtered out of the results though (like with an underscore or something) | 22:21 |
*** nikhil__ has joined #openstack-dev | 22:21 | |
jdg | http://paste.openstack.org/show/4930/ | 22:21 |
jdg | anotherjesse: there's still one issue in sudoers.d that I hadn't sorted yet as you see in the pastebin but that's no big deal. | 22:22 |
ayoung | termie, we pretty much have to do something like this to find all roles for a user now anyway | 22:22 |
Ryan_Lane | termie: you can do a recursive search | 22:23 |
jdg | I'm not sure what's up with the iscsiadm --rescan command, and I can't get it to run outside either. | 22:23 |
Ryan_Lane | (roleoccupant=<user>) | 22:23 |
ayoung | Ryan_Lane, so it would be something like | 22:23 |
termie | ayoung: well, one does not find all roles for a user, you find all teh roles within a tenant for a user | 22:23 |
anotherjesse | jdg: are you using a the solidfire driver? | 22:23 |
*** rackerjoe has quit IRC | 22:23 | |
ayoung | (&(roleoccupant=<user>)(cn=defaultRole)) | 22:23 |
Ryan_Lane | (&(roleoccupant=<user>)(cn=_default_tenant)) | 22:23 |
Ryan_Lane | indeed | 22:23 |
Ryan_Lane | heh | 22:23 |
jdg | anotherjesse: yes | 22:23 |
*** zaitcev has joined #openstack-dev | 22:24 | |
Ryan_Lane | then you can walk up the tree to find the tenant | 22:24 |
ayoung | termie, yes, but we *can* query for all roles for a user | 22:24 |
ayoung | Ryan_Lane, no need | 22:24 |
ayoung | the tenenat will be in the DN | 22:24 |
* Ryan_Lane nods | 22:24 | |
Ryan_Lane | that's what I meant | 22:24 |
jdg | anotherjesse: was trying to figure out if there was a way to use the generic iscsi driver, but I tested the driver with devstack when I submitted | 22:24 |
jdg | So I'm suspicious that maybe something changed in the manager code | 22:25 |
*** zykes has quit IRC | 22:25 | |
*** zykes has joined #openstack-dev | 22:25 | |
anotherjesse | jdg: perhaps - I just created an instance, a volume and attached them | 22:27 |
Ryan_Lane | vishy: I'm starting to think I should just abandon these change, and defer this bug to folsom: https://review.openstack.org/#change,3524,patchset=1 | 22:27 |
Ryan_Lane | thoughts? | 22:27 |
Ryan_Lane | the reason I think so, is because filtering support is missing for way more than just describeinstance | 22:27 |
jdg | anotherjesse: via iscsi or LVM? | 22:27 |
Ryan_Lane | it's missing everywhere it is supported | 22:27 |
anotherjesse | jdg: iscsi | 22:27 |
jdg | anotherjesse: Well there goes that theory :) | 22:28 |
anotherjesse | I'm double checking that | 22:28 |
*** mattray has joined #openstack-dev | 22:28 | |
jdg | anotherjesse: Local volumes work fine (w/ the exception of the sudo permissions) | 22:28 |
*** zykes- has joined #openstack-dev | 22:28 | |
jdg | anotherjesse: If you have iscsi your results will be great for me to hear, maybe something in the way I implemented the SF driver | 22:29 |
jdg | anotherjesse: But I'm still hung up on the iscsiadm --rescan that I can't seem to make work on any system | 22:30 |
anotherjesse | jdg: d0h - it was on the same machine - creating another volume | 22:30 |
andrewbogott | jdg: By chance, does euca-describe-instances hang for you? | 22:30 |
jdg | andrewbogott: I can try it, typically I try to use just nova api if possible. | 22:31 |
andrewbogott | It hangs via Horizon as well. | 22:31 |
andrewbogott | I switched to euca to reduce variables... | 22:31 |
anotherjesse | jdg: created another volume which is definitely on another machine | 22:31 |
jdg | andrewbogott: Nope, I'm good on horizon and via nova api | 22:31 |
andrewbogott | hm, ok. Thanks for checking. | 22:32 |
*** lts has quit IRC | 22:32 | |
*** zykes has quit IRC | 22:32 | |
*** dneary has quit IRC | 22:32 | |
jdg | anotherjesse: and it attached no problem? | 22:32 |
anotherjesse | jdg: successful attachment | 22:33 |
anotherjesse | jdg: sorry I didn't find the bug - perhaps vishy or sleepsonthefloo can help | 22:33 |
jdg | anotherjesse: DOHHHHH... well that leaves my driver as a "special" case | 22:33 |
*** Remco_ has quit IRC | 22:34 | |
jdg | anotherjesse: No, that's great... you at least narrowed it down to my driver (most likely) | 22:34 |
jdg | anotherjesse: Thanks for taking the time! | 22:34 |
jdg | anotherjesse: Whatever it is, it has to be in my export implementation which is only a few lines of code | 22:34 |
jdg | :) | 22:35 |
*** ewindisch has joined #openstack-dev | 22:42 | |
*** pixelbeat has joined #openstack-dev | 22:43 | |
gyee | anotherjesse, you have a list of which extension will be ported over to KSL and by when? | 22:44 |
*** berendt has quit IRC | 22:44 | |
*** ewindisch has quit IRC | 22:45 | |
*** heckj has quit IRC | 22:46 | |
openstackgerrit | Verification of a change to openstack/nova failed: Clarify use of Use of deprecated md5 library https://review.openstack.org/4342 | 22:49 |
anotherjesse | gyee: dolph is working on exposing the actual extension api | 22:50 |
gyee | I also see some gaps in the middleware as well | 22:50 |
anotherjesse | gyee: then there is the cert based token validation - https://bugs.launchpad.net/keystone/+bug/928047 (which is HIGH meaning for E4) | 22:50 |
uvirtbot` | Launchpad bug 928047 in keystone "port cert validation from keystone master to redux" [High,Confirmed] | 22:50 |
anotherjesse | gyee: is there a bug for that already (the middleware gap?) | 22:50 |
gyee | for example, the memcache functionality in E3 is no longer there in KSL | 22:51 |
gyee | auth_token.py used to support caching | 22:51 |
anotherjesse | gyee: filing a bug - the auth_token that was pulled over was from diablo | 22:53 |
anotherjesse | making it HIGH | 22:53 |
anotherjesse | gyee: https://bugs.launchpad.net/keystone/+bug/938253 | 22:55 |
uvirtbot` | Launchpad bug 938253 in keystone "need to update auth_token to most recent version" [High,Confirmed] | 22:55 |
*** ewindisch has joined #openstack-dev | 22:55 | |
*** hazmat has joined #openstack-dev | 22:58 | |
*** ayoung has quit IRC | 22:59 | |
*** ewindisch has quit IRC | 22:59 | |
*** apevec has quit IRC | 23:00 | |
*** jog0_ has joined #openstack-dev | 23:00 | |
*** apevec has joined #openstack-dev | 23:02 | |
anotherjesse | gyee: still around? | 23:02 |
*** Gordonz has quit IRC | 23:03 | |
*** jog0 has quit IRC | 23:03 | |
*** jog0_ is now known as jog0 | 23:03 | |
*** spinningcog has quit IRC | 23:05 | |
*** spinningcog has joined #openstack-dev | 23:05 | |
*** deshantm has joined #openstack-dev | 23:05 | |
*** markmc has quit IRC | 23:07 | |
gyee | anotherjesse, thanks, sorry I was in a meeting | 23:09 |
*** davlap has quit IRC | 23:12 | |
*** davlap has joined #openstack-dev | 23:13 | |
*** dtroyer has quit IRC | 23:13 | |
*** nati2 has joined #openstack-dev | 23:14 | |
*** davlap has quit IRC | 23:14 | |
*** markvoelker has quit IRC | 23:15 | |
openstackgerrit | Verification of a change to openstack/nova failed: blueprint host-aggregates: xenapi implementation https://review.openstack.org/3761 | 23:15 |
anotherjesse | gyee: looking for the PDF/spec info for the SSL cert | 23:15 |
anotherjesse | validation | 23:16 |
anotherjesse | https://github.com/openstack/keystone/tree/milestone-proposed/keystone/content is where the legacy code is | 23:16 |
gyee | not sure if there's a pdf on it | 23:18 |
anotherjesse | is there a wadl or ? | 23:18 |
gyee | lemme check | 23:18 |
*** cp16net has joined #openstack-dev | 23:18 | |
anotherjesse | actually prefer a text description (can be blueprint or ...) | 23:18 |
*** zzed has quit IRC | 23:20 | |
gyee | anotherjesse, it was under doc/source/ssl.rst | 23:21 |
gyee | there was a BP as well | 23:22 |
anotherjesse | gyee - thanks - updating the cert bug | 23:22 |
*** dneary has joined #openstack-dev | 23:23 | |
*** dneary has quit IRC | 23:23 | |
*** dneary has joined #openstack-dev | 23:23 | |
anotherjesse | gyee: if you want to add yourself to https://bugs.launchpad.net/keystone/+bug/928047 (click this affects you?) | 23:24 |
uvirtbot` | Launchpad bug 928047 in keystone "port cert validation from keystone master to redux" [High,Confirmed] | 23:24 |
*** kbringard has quit IRC | 23:24 | |
anotherjesse | gyee: so the remaining extensions are: | 23:24 |
anotherjesse | s3/ec2 - which already exist in the port | 23:24 |
anotherjesse | os-ksadm which exists | 23:25 |
mikal | Does Mark McLoughlin hang out on irc? What's his nick? | 23:25 |
anotherjesse | mikal: markmc | 23:26 |
anotherjesse | I thnk | 23:26 |
anotherjesse | os-kscatalog - doesn't exist - and we propose delaying to folsom | 23:26 |
gyee | I am also interested in hp-idm-serviceid extension since it address a security vulnerability | 23:26 |
andrewbogott | ok... when I click on Project->Access and Security, I get a hang. The last thing that nova-api says is 'Connected to AMQP server on localhost' | 23:27 |
andrewbogott | can anyone suggest what it might be waiting for? I don't see anything interesting in any of my logs. | 23:27 |
andrewbogott | (My next step will be to add debug lines to the horizon code :( ) | 23:27 |
anotherjesse | access & security lists secgroups, keypairs & floating ips | 23:28 |
anotherjesse | gyee: see private chat ping | 23:28 |
*** cp16net has quit IRC | 23:28 | |
anotherjesse | andrewbogott: what happens when you hit each of those list commands individually from nova cli? | 23:28 |
* andrewbogott digs in the code to see what gets listed | 23:29 | |
openstackgerrit | Verification of a change to openstack/nova failed: Alter output format of volume types resources https://review.openstack.org/4361 | 23:30 |
sleepsonthefloo | andrewbogott - what does n-net say? | 23:30 |
anotherjesse | andrewbogott: nova floating-ip-list; nova secgroup-list; nova keypair-list | 23:30 |
andrewbogott | It is floating-ip-list that is hanging. | 23:31 |
andrewbogott | Looks like a lock file issue... "Attempting to grab file lock "iptables" for method "apply"... from (pid=6137) inner /opt/stack/nova/nova/utils.py:832" | 23:31 |
andrewbogott | sleepsonthefloo: So maybe there's just a file I need to rm? | 23:32 |
andrewbogott | actually, it looks like n-net has been stuck since startup | 23:32 |
sleepsonthefloo | andrewbogott - possibly. I'd say that an old iptables lock and misconfigured sudo are two common issues of n-net hangs | 23:32 |
spinningcog | I'm trying to issue 'keystone tenant-create --name=admin' like what is specified in the devstack keystone_data.sh script. However I get the error message: You must provide a username via either --username or env[OS_USERNAME] | 23:33 |
anotherjesse | spinningcog: are you using devstack? | 23:33 |
andrewbogott | sleepsonthefloo: How do I purge an old iptables lock? | 23:33 |
spinningcog | anotherjesse: no, I'm just trying to set up some user on a standalone keystone | 23:33 |
Vek | so are jeblair / mtaylor looking into the unit tests hosage? | 23:34 |
spinningcog | anotherjesse: Since the documentation is a bit sparese, I was using the keystone_data.sh script as a source for learning how to use it | 23:34 |
sleepsonthefloo | andrewbogott: I believe the old lock will be in /opt/stack/nova do you see anything there *.lock? | 23:34 |
spinningcog | anotherjesse: I don't see how I can add any users into keystone since it relies on having an admin token to use the 'keystone' command, and I'm not sure how to load one | 23:35 |
anotherjesse | spinningcog: so the way devstack works is that it uses an admin token to then run those commands, https://github.com/cloudbuilders/devstack/blob/master/stack.sh#L1323 | 23:35 |
andrewbogott | sleepsonthefloo: Yep! And it's 23 hours old, which seems suspicious. | 23:35 |
anotherjesse | it sets some env variables that keystone cli uses then | 23:35 |
andrewbogott | I will kill it and restart devstack... | 23:35 |
andrewbogott | ...or... maybe I don't need to restart anything | 23:36 |
andrewbogott | anotherjesse, sleepsonthefloo: Hey, now it's working! Thank you! | 23:36 |
anotherjesse | andrewbogott: it is a bug that horizon times out | 23:37 |
andrewbogott | vs. reporting an error you mean? | 23:37 |
anotherjesse | if something like: start devstack, kill nova-network, then horizon has a bad experience (no error/timeout) | 23:37 |
sleepsonthefloo | anotherjesse - there is also a bug that nova never times out rpc.calls | 23:37 |
andrewbogott | today I was trying to create a keypair, so having the ip lookup fail (rather than hang) would've been /way/ better. As it is I couldn't access the key gui due to an unrelated lockup. | 23:38 |
* anotherjesse isn't sure I like the way those GUIs are combines (access&security vs 3 different panels) - but I've not thought enough to argue either way | 23:40 | |
*** tomoe_ has joined #openstack-dev | 23:40 | |
andrewbogott | Hm... getting around that bug allowed me to create an instance which caused my entire node to crash. Big Points! | 23:41 |
bcwaldon | jeblair: can you look at why the unittest job failed for this review https://review.openstack.org/#change,4361 | 23:43 |
*** hashar has quit IRC | 23:43 | |
*** jog0 has quit IRC | 23:43 | |
*** jog0 has joined #openstack-dev | 23:43 | |
*** rkukura has joined #openstack-dev | 23:44 | |
jeblair | bcwaldon: looking | 23:45 |
*** rods has quit IRC | 23:45 | |
sleepsonthefloo | andrewbogott - the default rpc timeout is 3600 seconds. I'll propose dropping that to something that you would have noticed. | 23:46 |
andrewbogott | Like maybe 1 :) | 23:47 |
* andrewbogott has a short attention span | 23:47 | |
*** mattray has quit IRC | 23:48 | |
*** mikeyp has joined #openstack-dev | 23:48 | |
openstackgerrit | Verification of a change to openstack/nova failed: Clarify use of Use of deprecated md5 library https://review.openstack.org/4342 | 23:52 |
*** jdg has quit IRC | 23:54 | |
*** jdg has joined #openstack-dev | 23:54 | |
sleepsonthefloo | andrewbogott: https://review.openstack.org/#change,4376 I suggested 10 | 23:55 |
jeblair | bcwaldon: this commit broke it: https://github.com/openstack/nova/commit/13ebb49925c4081b01e1a11f3c3f02eac527d278 | 23:56 |
andrewbogott | That's more realistic. | 23:56 |
*** stuntmachine has joined #openstack-dev | 23:57 | |
bcwaldon | yay | 23:57 |
jeblair | bcwaldon: that patch removed "nose" from pip-requires | 23:57 |
jeblair | and added it to test-requires | 23:57 |
jeblair | but the current nova-venv build job doesn't know anything about test-requires | 23:57 |
jeblair | hrm, maybe it does... | 23:58 |
jeblair | it's in nova's build_venv script | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!