| *** VW has joined #craton | 01:06 | |
| *** VW has quit IRC | 01:11 | |
| *** VW has joined #craton | 03:07 | |
| *** VW has quit IRC | 03:14 | |
| *** valw has joined #craton | 03:25 | |
| *** valw has quit IRC | 03:30 | |
| *** toan has quit IRC | 03:33 | |
| *** mhayden has quit IRC | 03:34 | |
| *** hughsaunders has quit IRC | 03:34 | |
| *** toan has joined #craton | 03:36 | |
| *** hughsaunders has joined #craton | 03:36 | |
| *** mhayden has joined #craton | 03:38 | |
| *** VW has joined #craton | 03:48 | |
| *** david-lyle has joined #craton | 04:46 | |
| *** david-lyle has quit IRC | 04:50 | |
| *** david-lyle_ has joined #craton | 04:50 | |
| *** david-lyle_ is now known as david-lyle | 04:52 | |
| *** david-lyle has quit IRC | 05:21 | |
| *** VW has quit IRC | 05:52 | |
| *** valw has joined #craton | 07:27 | |
| *** valw has quit IRC | 07:31 | |
| *** VW has joined #craton | 07:52 | |
| *** VW has quit IRC | 07:56 | |
| sulo | o/ | 08:31 |
|---|---|---|
| sulo | git-harry: btw, blame is not who set it, its just what vars are set at each level. i guess name suggests more, like git blame. | 11:15 |
| sulo | the idea was to add who part as well later ... so we can keep kind of a git like blame history | 11:16 |
| sulo | i dont know if this is the right way to do that though | 11:17 |
| git-harry | sulo: ah okay. Well if blame is just intended to be the var hierarchy then I think it would make sense to use that spec to define how it should be used. | 11:23 |
| git-harry | To me it seems pretty vital for anyone wanted to set/update vars to know what is set at each level. | 11:24 |
| sulo | git-harry: yeah i agree. Take a look at that, since we've never used it, we might find that its not doing what we are expecting. I think more than changin that spec drastically | 11:26 |
| sulo | it might complement what you are proposing | 11:26 |
| sulo | i think the db impl of your spec is partly done by that func | 11:27 |
| *** valw has joined #craton | 11:28 | |
| *** valw has quit IRC | 11:33 | |
| git-harry | Yes, it would probably make sense to use/modify it as part of implementing this spec | 11:41 |
| tojuvone | Hi there | 12:37 |
| tojuvone | I would need advice to update spec I have on Nova. How to link to Craton | 12:40 |
| thomasem | o/ | 13:50 |
| sulo | tojuvone: can you link the spec pls ? | 13:54 |
| tojuvone | https://review.openstack.org/428070/ | 14:03 |
| tojuvone | I was wondering if not to play with the url there, but keep both with url something like: http://${CRATON_IP}:8080/v1/hosts/{id}/host_details | 14:04 |
| tojuvone | Then have problems in Craton side. Need to have rights to user for admin and any user having VMs on the host | 14:06 |
| tojuvone | And one day when having notifications in Craton, updating host_details should have notification with the "host" that is actually in parent namespece | 14:07 |
| thomasem | sulo: I'd personally prefer be consistent with the existing implementation in my patch, regarding project admin being able to modify variables and such. The original bug suggests we may not all be on the same page there? | 14:51 |
| thomasem | And then I could follow-up with a patch fixing all of them to be how we actually want it. | 14:52 |
| thomasem | That will facilitate communication and afford us a forum for discussion for any folks that disagree with expanding the scope of privileges for project admin. | 14:52 |
| sulo | thomasem: sounds good to me. just pointing out that there is existing logic thats a bit mixed up. | 14:53 |
| jimbaker | git-harry, blame is intended to address history, not just inheritance | 14:53 |
| jimbaker | (or technically, overrides. or whatever) | 14:53 |
| thomasem | sulo: okay, cool! Yeah, I appreciate it. That was a bit confusing. | 14:53 |
| thomasem | :) | 14:53 |
| thomasem | Also, while looking at it, I found this tiny thing and threw up a quick patch: https://review.openstack.org/#/c/429725/2 | 14:54 |
| jimbaker | as for usage: blame doesn't change setting variables. it's a separate view on the variables | 14:55 |
| git-harry | jimbaker: okay. It would be good if you could add your comments to the spec so we can capture all this in one place. | 15:00 |
| jimbaker | git-harry, for sure | 15:00 |
| jimbaker | everyone, meeting over in #openstack-meeting-4 | 15:00 |
| *** VW has joined #craton | 15:04 | |
| *** VW has quit IRC | 15:24 | |
| *** valw has joined #craton | 15:30 | |
| *** VW has joined #craton | 15:33 | |
| *** valw has quit IRC | 15:35 | |
| *** klindgren has joined #craton | 15:35 | |
| *** klindgren__ has quit IRC | 15:37 | |
| *** VW has quit IRC | 15:38 | |
| *** VW has joined #craton | 15:48 | |
| thomasem | o/ | 16:00 |
| * sigmavirus will be out for a dental appointment towards the end of the hour | 16:01 | |
| thomasem | Ohhhh good luck | 16:01 |
| sigmavirus | thomasem: it's not bad | 16:02 |
| sigmavirus | I just think a crown I had installed is a bit loose | 16:02 |
| * thomasem cringes | 16:02 | |
| jimbaker | so an easier appointment | 16:02 |
| thomasem | That's good. | 16:02 |
| *** Syed__ has joined #craton | 16:10 | |
| tojuvone | jimbaker, Hi | 16:21 |
| jimbaker | hi | 16:21 |
| *** klindgren_ has joined #craton | 16:29 | |
| *** klindgren has quit IRC | 16:32 | |
| thomasem | Can we get another +2 on this? I'd like to get it in and update my variables patch for /projects. :) https://review.openstack.org/#/c/426918/ | 16:38 |
| thomasem | And this has a +2 also, so needs another +2, I think? https://review.openstack.org/#/c/428996/ | 16:39 |
| tojuvone | jimbaker, I posted earlier link to my Nova spec. Liked to have opinion how should I link to Craton | 16:40 |
| thomasem | Same with this guy https://review.openstack.org/#/c/428195 | 16:40 |
| tojuvone | jimbaker, Has to go right. | 16:41 |
| jimbaker | tojuvone, ok, i will take a look, thanks! | 16:42 |
| jimbaker | thomasem, same with those reviews for you | 16:42 |
| tojuvone | jimbaker, thanks, didn't like to rush this, but to get Pike... | 16:42 |
| tojuvone | Oh, Nova has policy.json. Could something like that be used in Craton namespace to have "admin_or_owner" | 16:45 |
| tojuvone | Just thinking if can use just single link for admin and owner: http://${CRATON_IP}:8080/v1/hosts/{id}/host_details | 16:46 |
| thomasem | jimbaker: much appreciated!! | 16:47 |
| jimbaker | tojuvone, interesting. i have been looking at similar details with respect to our rbac implementation | 16:48 |
| tojuvone | jimbaker, sulo, also as posted before, there would be perhaps problem with namespace related notification | 16:50 |
| tojuvone | it needs "host" (hostname), from parent namespace | 16:50 |
| tojuvone | otherwise would be easy to have notification content limited to namespace changed | 16:51 |
| *** jovon has joined #craton | 17:06 | |
| *** klindgren has joined #craton | 17:14 | |
| *** klindgren_ has quit IRC | 17:15 | |
| *** harlowja has joined #craton | 17:20 | |
| *** harlowja has quit IRC | 17:49 | |
| *** VW has quit IRC | 17:54 | |
| *** VW has joined #craton | 18:02 | |
| *** VW has quit IRC | 18:08 | |
| *** VW has joined #craton | 18:09 | |
| *** harlowja has joined #craton | 18:44 | |
| sulo | thomasem: https://review.openstack.org/#/c/429725 i am not sure if i am reading this right | 18:48 |
| sulo | but they are differnt arent they ? | 18:48 |
| thomasem | sulo: they are different, but is_project_admin_context will return True always if is_admin_context returns True also, and they're OR'ed here. | 18:51 |
| thomasem | So, it should short-circuit, but the additional check that ANDs context.is_admin and context.is_admin_project is unnecessary. The condition is already satisfied if context.is_admin returns True. | 18:52 |
| thomasem | Since we're OR'ing them. | 18:52 |
| thomasem | Basically, the call to is_admin_context should never have to run, because it's irrelevant. | 18:53 |
| thomasem | Since the first half of the AND being True will satisfy the OR returning True. | 18:53 |
| thomasem | Does that make sense? | 18:53 |
| thomasem | sulo: ^^ | 18:53 |
| sulo | thomasem: ah i see what you are saying .. yes totally makes sense | 18:54 |
| thomasem | Sweet. Yeah, just a little ditty I noticed while putzing around fixing up the projects patch. | 18:54 |
| thomasem | Figured it wouldn't hurt to delete some code. I love deleting code. | 18:55 |
| jimbaker | thomasem, makes sense, and probably survives in some form when we get the rbac stuff implemented | 19:04 |
| jimbaker | i see this as important for implementing that bootstrap approach we discussed earlier | 19:04 |
| *** klindgren has quit IRC | 19:09 | |
| thomasem | jimbaker: yep! | 19:10 |
| *** klindgren has joined #craton | 19:10 | |
| Syed__ | sulo: you around ? | 19:30 |
| *** valw has joined #craton | 19:32 | |
| *** valw has quit IRC | 19:36 | |
| *** jovon has quit IRC | 19:50 | |
| *** VW has quit IRC | 19:56 | |
| *** VW has joined #craton | 20:08 | |
| *** klindgren_ has joined #craton | 20:12 | |
| *** klindgren has quit IRC | 20:13 | |
| *** VW has quit IRC | 20:13 | |
| *** VW has joined #craton | 20:25 | |
| *** VW_ has joined #craton | 20:27 | |
| *** VW has quit IRC | 20:28 | |
| *** VW_ has quit IRC | 20:50 | |
| *** VW has joined #craton | 21:00 | |
| *** VW has quit IRC | 21:05 | |
| *** VW has joined #craton | 21:11 | |
| *** jovon has joined #craton | 21:14 | |
| jimbaker | thomasem, thanks for some great comments on https://bugs.launchpad.net/craton/+bug/1661714 | 22:31 |
| openstack | Launchpad bug 1661714 in craton "Bulk endpoint for working with resources" [High,New] | 22:31 |
| jimbaker | thomasem, given other priorities for the rest of us, let me suggest that we assign this bug to you, and you can bring sigmavirus and others as it makes sense | 22:33 |
| antonym | is there a way to query by variable without having the host id? | 22:33 |
| antonym | like if i was doing a look up of the mac address that i had set as a variable | 22:34 |
| jimbaker | antonym, so you can query the corresponding hosts that have that mac address | 22:34 |
| jimbaker | no id necessary to start | 22:35 |
| jimbaker | the query | 22:35 |
| jimbaker | brb | 22:35 |
| antonym | yeah, so i can pull up the record by doing a query like this: hosts?region_id=1&ip_address=10.127.5.110 but if i wanted to query by the variables to narrow it down, does that exist yet? | 22:40 |
| jimbaker | antonym, so you should be able to do ?vars=some-var:some-value&another-var:another-value | 22:52 |
| jimbaker | arbitrarily combined with the query above of course | 22:52 |
| antonym | so like this? v1/hosts?vars=os:debian in this case i've only set one host with the variables, but it returns all of them | 22:59 |
| jimbaker | antonym, that should work. i did notice a problem in how we parse args if numbers (and presumably boolean or null) for the search params - this is not well specified, it currently only matches on strings | 23:09 |
| jimbaker | so v1/hosts?vars=foo:47 will not match a number that's stored in the foo variable | 23:10 |
| antonym | yeah, it doesn't seem to be matching on that, seems like it's just returning all records under hosts | 23:13 |
| *** VW_ has joined #craton | 23:14 | |
| jimbaker | antonym, you are running a recent build, right? | 23:16 |
| jimbaker | sulo fixed a bug in vars filters very recently (feb 1) | 23:16 |
| antonym | yeah, latest master | 23:16 |
| jimbaker | ok | 23:16 |
| antonym | https://gist.github.com/antonym/ebfa6f2eef738855a147158afb2d7ba7 | 23:17 |
| *** VW has quit IRC | 23:17 | |
| antonym | first one is the only one with vars set | 23:17 |
| jimbaker | right | 23:18 |
| *** VW_ has quit IRC | 23:18 | |
| antonym | are you supposed to be able to mix say a region in the query too? so if i only wanted to look for os:debian in my dfw region | 23:20 |
| jimbaker | antonym, region is optional | 23:21 |
| jimbaker | just another part of a query filter | 23:21 |
| jimbaker | antonym, still trying to reproduce your problem | 23:22 |
| jimbaker | can you give me a gist of the script that's generating your data? | 23:22 |
| *** VW has joined #craton | 23:25 | |
| antonym | oh, i just manually tossed a few in | 23:25 |
| antonym | i just created a region, cell, made 6 host records and then attached that os:debian var on host 1 | 23:26 |
| jimbaker | yeah, just wonder what is different here. maybe empty variables? | 23:28 |
| *** sulo_ has joined #craton | 23:28 | |
| jimbaker | no, doesn't seem to be the case | 23:29 |
| jimbaker | sulo, antonym is having a problem with the vars query | 23:29 |
| jimbaker | i've been unable to reproduce his problem | 23:29 |
| *** VW has quit IRC | 23:29 | |
| jimbaker | in a nutshell, doing something like ?vars=os:debian in the REST API is returning the full set of hosts, not just the ones that match the vars query filter | 23:31 |
| *** sballe__ has joined #craton | 23:31 | |
| jimbaker | antonym, i think we really need that little script of yours, just to figure out what is different here | 23:32 |
| *** valw has joined #craton | 23:33 | |
| *** sballe_ has quit IRC | 23:34 | |
| *** sulo has quit IRC | 23:34 | |
| *** sballe__ is now known as sballe_ | 23:36 | |
| thomasem | jimbaker: excellent. Sounds good to me! | 23:37 |
| jimbaker | thomasem, cool, i just assigned you that bug | 23:38 |
| jimbaker | please go ahead and start detailing out that blueprint | 23:38 |
| *** valw has quit IRC | 23:38 | |
| antonym | jimbaker: don't have a script since i tossed them in manually, i added the var with this: "http://ip:8080/v1/hosts/1/variables" -XPUT -d '{"os": "debian"}' | 23:40 |
| *** VW has joined #craton | 23:46 | |
| jimbaker | antonym, this is the same curl invocation i made to make the settings. the the corresponding query is returning the desired subset | 23:50 |
| jimbaker | i will prepare a script on my end that we can both run | 23:50 |
| *** VW has quit IRC | 23:50 | |
| jimbaker | and hopefully see the same results | 23:50 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!