| *** VW has joined #craton | 00:47 | |
| *** VW has quit IRC | 00:52 | |
| *** VW has joined #craton | 02:38 | |
| *** VW has quit IRC | 02:43 | |
| *** VW has joined #craton | 03:16 | |
| *** valw has joined #craton | 03:35 | |
| *** valw has quit IRC | 03:39 | |
| *** VW has quit IRC | 04:03 | |
| *** VW has joined #craton | 04:04 | |
| *** VW has quit IRC | 05:01 | |
| jimbaker | antonym, please try this setup. i tried to reproduce your setup, but i'm still only getting one host when i query for the hosts matching os:debian | 05:10 |
|---|---|---|
| jimbaker | https://gist.github.com/jimbaker/fda7b48c925e2c568781bf272a6fc99b | 05:10 |
| *** valw has joined #craton | 05:16 | |
| *** valw_ has joined #craton | 05:18 | |
| *** valw has quit IRC | 05:21 | |
| *** valw_ has quit IRC | 05:45 | |
| *** Syed__ has quit IRC | 06:35 | |
| *** jovon has quit IRC | 09:40 | |
| *** jcannava has quit IRC | 10:34 | |
| sulo_ | jimbaker: i see that its working for you ? | 10:39 |
| *** sulo_ is now known as sulo | 10:39 | |
| *** ChanServ sets mode: +o sulo | 10:40 | |
| *** VW has joined #craton | 13:07 | |
| *** klindgren__ has joined #craton | 13:17 | |
| *** klindgren_ has quit IRC | 13:20 | |
| *** VW has quit IRC | 13:20 | |
| *** VW has joined #craton | 13:47 | |
| *** VW has quit IRC | 13:48 | |
| *** VW has joined #craton | 13:49 | |
| *** valw has joined #craton | 14:53 | |
| *** b3rn-n00dl3s has quit IRC | 14:53 | |
| *** valw has quit IRC | 15:15 | |
| sulo | http://cdn.pasteraw.com/90abpeqkkw8sa0zxaa1vj3jm03ld5rl | 15:43 |
| sulo | is what cloudnull is talking about | 15:43 |
| cloudnull | do we have a specs repo you want me to put thing in ? | 15:57 |
| sulo | cloudnull: https://github.com/openstack/craton/tree/master/doc/source/specs | 15:58 |
| jimbaker | sulo, cloudnull - so i see in this picture the potential for a given device to be shared by cloud; region; cell | 15:59 |
| cloudnull | would you want the top level environment db model added there ? | 15:59 |
| jimbaker | from a model refactoring aspect, this should be straightforward | 15:59 |
| jimbaker | and similar to how we earlier modeled labels before we made them much simpler | 15:59 |
| jimbaker | including possible variable overrides; and how they can disambiguate if there is a conflict | 16:00 |
| jimbaker | cloudnull, so what's the difference between environment and project? | 16:00 |
| sulo | jimbaker: it seems like env=project as long as we can support multiple cloud ? | 16:01 |
| jimbaker | that would be my assumption | 16:01 |
| sulo | jimbaker: cloudnull: i think that is fairly simple modification on our part .. | 16:02 |
| jimbaker | sulo, basically we would like something that doesn't share anything | 16:02 |
| jimbaker | and that's what we have been modeling as project | 16:03 |
| sulo | right, the shared resouce thing is differnt | 16:03 |
| cloudnull | jimbaker: essentially: customer>cloud>... | 16:03 |
| cloudnull | i used the word environment | 16:03 |
| jimbaker | ok, so if we can agree that it's project :) | 16:03 |
| *** VW has quit IRC | 16:03 | |
| jimbaker | we are good | 16:03 |
| cloudnull | sure. | 16:04 |
| cloudnull | project > cloud > ... | 16:04 |
| jimbaker | and make project be what is necessary. but again, no cross project sharing | 16:04 |
| jimbaker | got to dupe at that point | 16:04 |
| *** VW has joined #craton | 16:04 | |
| sulo | jimbaker: its the same, we need cloud to be the top level rather than region | 16:04 |
| cloudnull | sharing between regions within a given cloud would be nice to have. | 16:04 |
| jimbaker | cloudnull, and that's what we will work out | 16:05 |
| jimbaker | fortunately the REST API, and out doesn't care about sharing | 16:05 |
| jimbaker | sulo, glad we stuck with that design decision of staying flat! | 16:06 |
| cloudnull | jimbaker: if we are implementing a HATEOS rest api then links and forward documents shouldn't be too much of a ask . | 16:07 |
| jimbaker | from a GET perspective. POST/PUT will likely need some minor adjustment | 16:07 |
| cloudnull | most of that can happen in the app. | 16:07 |
| cloudnull | it doesn't need to be part of the model | 16:07 |
| cloudnull | besides the foreign key that is , | 16:08 |
| cloudnull | assuming we stay with normalized data in sql | 16:08 |
| jimbaker | cloudnull, it is normalized, and will stay that way (with some minor duplication to simplify hierarchy lookups) | 16:09 |
| cloudnull | cool. so then assuming you can work out the ORM, creating a relation between objects should be fairly straight forward. | 16:10 |
| jimbaker | so in particular, the relevant change here will be that we will have an association table to link regions to devices, vs a simple parent -> child relationship in a single ID as it is today | 16:10 |
| jimbaker | cloudnull, yep | 16:10 |
| jimbaker | sqlalchemy is pretty good here | 16:10 |
| jimbaker | and i know it composes with the other aspects, namely variables, because the old label system had a similar schema | 16:11 |
| jimbaker | before we simplified it | 16:11 |
| cloudnull | great, sounds like a start. | 16:11 |
| jimbaker | definitely. and i'm glad we had this discussion, because this relaxation is a valid use case, and not just in rackspace | 16:12 |
| jimbaker | ok, i will add a bug, and we will expand that out accordingly | 16:13 |
| *** jovon has joined #craton | 16:13 | |
| *** valw has joined #craton | 16:16 | |
| jimbaker | https://bugs.launchpad.net/craton/+bug/1662574 | 16:20 |
| openstack | Launchpad bug 1662574 in craton "Support device sharing between clouds, regions, and cells" [Undecided,New] | 16:20 |
| *** valw has quit IRC | 16:20 | |
| sulo | jimbaker: we should separete out the "adding cloud as top level resource" to a separete bug and this can follow that | 16:21 |
| jimbaker | sulo, yep, adding that bug this moment... | 16:22 |
| sulo | rgr | 16:22 |
| *** valw has joined #craton | 16:22 | |
| jimbaker | sulo, my assumption is that workflows can be shared across a project | 16:23 |
| jimbaker | same with users | 16:23 |
| jimbaker | so a workflow could apply to multiple clouds | 16:24 |
| jimbaker | but that's something we will work out more as we get back to workflows | 16:24 |
| jimbaker | https://bugs.launchpad.net/craton/+bug/1662576 | 16:24 |
| openstack | Launchpad bug 1662576 in craton "Support multiple clouds in a given project" [Undecided,New] | 16:24 |
| thomasem | Any particular reason we're using bugs over BPs for this? | 16:33 |
| jimbaker | thomasem, I expect to use BPs to actually address solutions here | 16:34 |
| thomasem | Oh, gotcha | 16:34 |
| thomasem | And are we actually going for HATEOAS? | 16:35 |
| thomasem | Saw cloudnull's comment | 16:35 |
| jimbaker | bug (or feature req) -> blueprint -> spec -> code | 16:35 |
| thomasem | jimbaker: ahhhhh, okay. I see. I thought BP was for feature request. | 16:36 |
| jimbaker | HATEOAS? i don't know... i'm vaguely aware of this architectural pattern, but i don't know implications for craton | 16:37 |
| thomasem | cloudnull: mind elaborating on that ask? | 16:37 |
| cloudnull | we're building a rest api right ? | 16:37 |
| cloudnull | https://en.wikipedia.org/wiki/HATEOAS | 16:37 |
| cloudnull | from the Roy Fielding spec | 16:38 |
| jimbaker | sure, but HATEOAS is about discoverability | 16:38 |
| cloudnull | and? | 16:38 |
| jimbaker | interestingly, the python client does bring this into play | 16:39 |
| cloudnull | device is plugged into host it'd be nice if that link was discoverable | 16:39 |
| cloudnull | not to say that we have to do this | 16:39 |
| jimbaker | cloudnull, sure, that richness is provided | 16:40 |
| cloudnull | by what? | 16:40 |
| jimbaker | or will be when sulo finishes up the container support | 16:40 |
| jimbaker | device parent_id, and corresponding links | 16:40 |
| sulo | we are (review pending) doing this already for pagination, and i am more to it for parent/child relation | 16:40 |
| jimbaker | but HATEOAS goes a few steps further | 16:40 |
| cloudnull | it does | 16:41 |
| thomasem | Yeah | 16:41 |
| thomasem | You'd hit root and get machine-friendly navigation and discoverability for the rest of the API, and so on | 16:41 |
| cloudnull | ++ | 16:41 |
| jimbaker | anyway, it's worth discussing further | 16:41 |
| jimbaker | given the client is going this direction, maybe it should be further supported in the REST API. certainly can be composed in | 16:42 |
| jimbaker | by adding to response bodies | 16:42 |
| cloudnull | link formats in json are a point of contention | 16:42 |
| cloudnull | but it could be done | 16:42 |
| sulo | jimbaker: cloudnull: we are already adding suport for it for pagination and i am adding to it for parent child relation | 16:43 |
| sulo | talking purely about links | 16:43 |
| jimbaker | the other question is, should this be added in for openstack more generally | 16:43 |
| thomasem | So, we probably want a bug to assess the extent to which we implement HATEOAS (or will) already, and generating work to shore up the rest, if we decide in the course of that that it's something we want in Craton. | 16:43 |
| sulo | not sure what else HATEOAS constitutes | 16:43 |
| thomasem | As a part of the API WG? | 16:43 |
| jimbaker | yes, such as https://review.openstack.org/#/c/390973/ | 16:43 |
| jimbaker | where we look at pagination specifically and try to help API WG standardize | 16:44 |
| thomasem | I could ask Everett and others about what discussions they may have had around it. | 16:44 |
| jimbaker | thomasem, +1 | 16:44 |
| sulo | its already defined here: https://specs.openstack.org/openstack/api-wg/guidelines/links.html | 16:45 |
| thomasem | I suggested HATEOAS for Carina when we were first developing it, but it turned out to be overkill. | 16:45 |
| sulo | and http://json-schema.org/latest/json-schema-hypermedia.html | 16:45 |
| jimbaker | two different approaches | 16:46 |
| jimbaker | one to documentation, the other machine readable | 16:46 |
| jimbaker | although possibly the docs are machine readable too | 16:46 |
| jimbaker | but the swagger efforts that the API WG did, didn't work out | 16:46 |
| thomasem | Heh, don't get me started on Swagger. :( | 16:47 |
| thomasem | I used to have a full head of hair. | 16:47 |
| jimbaker | anyway, i would like to suggest that HATEOAS could be worthwhile for us to do; but it's not an immediate priority | 16:48 |
| thomasem | Cool. For context, I brought it up because I didn't want to lose the ask in the flurry of other issues going around. :P | 16:52 |
| *** valw has quit IRC | 16:56 | |
| thomasem | This one's cleaned up and ready to go: https://review.openstack.org/#/c/427777 | 16:58 |
| jimbaker | thomasem, vidyo meeting in craton room | 17:02 |
| thomasem | omw Vidyo troubles :\ | 17:02 |
| antonym | jimbaker: yeah, your repro works as expected... guess i'll poke around some more, thanks for looking at it | 17:06 |
| antonym | could that vars query show the available variables on the return so you don't have to make another call to the host to get those variables? | 17:15 |
| *** valw has joined #craton | 17:19 | |
| sulo | antonym: you mean on ?vars=a:b return host with its vars ? | 17:22 |
| sulo | ah i thought it was alreday that but looks like not | 17:22 |
| antonym | yeah | 17:22 |
| antonym | just so i don't have to make a double call | 17:22 |
| antonym | right now it just returns without vars | 17:23 |
| antonym | i need to go figure out why vars wasn't working in my env, it's clearly working on that repro | 17:23 |
| antonym | i also set it all up manually outside of docker too | 17:23 |
| sulo | antonym: ill create a bug for it | 17:24 |
| sulo | that should be hopefully quick fix | 17:24 |
| antonym | cool, thanks | 17:24 |
| *** VW has quit IRC | 17:25 | |
| *** VW has joined #craton | 17:33 | |
| *** valw has quit IRC | 17:39 | |
| *** Syed__ has joined #craton | 17:55 | |
| jimbaker | got it, good to clarify what the vars search query does | 17:55 |
| jimbaker | so antonym, if you use the python client, it does this automatically for you | 17:56 |
| jimbaker | the assumption had been that variables could be expensive to return as details for a large host collection, so were doing this on demand | 17:56 |
| jimbaker | but a natural thing that can be done is to add a query param on v1/hosts for the details (so something like ?...&details=true or whatever) | 17:57 |
| jimbaker | sulo, ^^^ | 17:57 |
| jimbaker | basically treat in a similar fashion as say ?...&resolved=true | 17:58 |
| sulo | jimbaker: +1 | 18:23 |
| jimbaker | sulo, when we add namespace support, we can also push the namespace filtering into this query as well. natural extension | 18:24 |
| jimbaker | maybe it would be a specification of details? TBD | 18:25 |
| jimbaker | sulo, what if we say ?...&details=all | 18:25 |
| sulo | vs details= ?? | 18:25 |
| jimbaker | vs details=true | 18:26 |
| sulo | you thinking ther can be other params to details | 18:26 |
| jimbaker | exactly, such as the specific namespaces to be imported | 18:26 |
| sulo | yeah i mean its the same as saying details=true | 18:26 |
| sulo | gotcha | 18:26 |
| sulo | sounds good to me | 18:26 |
| sulo | Priority issues: | 18:27 |
| sulo | =========== | 18:27 |
| sulo | https://bugs.launchpad.net/craton/+bug/1662496 | 18:27 |
| sulo | https://bugs.launchpad.net/craton/+bug/1662574 | 18:27 |
| sulo | https://bugs.launchpad.net/craton/+bug/1662576 | 18:27 |
| openstack | Launchpad bug 1662496 in craton "Host response is missing parent_id property" [High,New] - Assigned to Sulochan Acharya (sulochan-acharya) | 18:27 |
| sulo | https://bugs.launchpad.net/craton/+bug/1662614 | 18:27 |
| sulo | https://bugs.launchpad.net/craton/+bug/1662618 | 18:27 |
| openstack | Launchpad bug 1662574 in craton "Support device sharing between clouds, regions, and cells" [Undecided,New] | 18:27 |
| openstack | Launchpad bug 1662576 in craton "Support multiple clouds in a given project" [Undecided,New] | 18:27 |
| openstack | Launchpad bug 1662614 in craton "Allow search by parent_id filter to retrieve all child devices" [Undecided,New] | 18:27 |
| openstack | Launchpad bug 1662618 in craton "Allow getting vars in list query result with details=true" [Undecided,New] | 18:27 |
| sulo | afk for now .. will create more issue later | 18:28 |
| jimbaker | and the various CLI issues | 18:29 |
| sulo | yeah | 18:29 |
| jimbaker | but those are easy | 18:29 |
| *** valw has joined #craton | 18:39 | |
| *** valw has quit IRC | 18:44 | |
| *** valw has joined #craton | 18:48 | |
| *** VW has quit IRC | 18:55 | |
| *** VW has joined #craton | 19:02 | |
| *** valw has quit IRC | 19:25 | |
| thomasem | Assigned myself to https://bugs.launchpad.net/craton/+bug/1662576 | 19:40 |
| openstack | Launchpad bug 1662576 in craton "Support multiple clouds in a given project" [Undecided,New] - Assigned to Thomas Maddox (thomas-maddox) | 19:40 |
| *** jovon has quit IRC | 19:50 | |
| *** klindgren_ has joined #craton | 20:12 | |
| *** klindgren__ has quit IRC | 20:14 | |
| *** klindgren has joined #craton | 20:14 | |
| *** klindgren_ has quit IRC | 20:17 | |
| Syed__ | jimbaker: hi | 20:17 |
| Syed__ | if you get some time kindly look some of the patches i put into review | 20:17 |
| *** valw has joined #craton | 20:25 | |
| *** valw has quit IRC | 20:30 | |
| *** klindgren_ has joined #craton | 20:30 | |
| *** klindgren has quit IRC | 20:33 | |
| *** harlowja has quit IRC | 21:09 | |
| *** klindgren has joined #craton | 21:10 | |
| *** klindgren_ has quit IRC | 21:12 | |
| *** harlowja has joined #craton | 21:35 | |
| *** valw has joined #craton | 21:41 | |
| *** valw has quit IRC | 21:45 | |
| *** klindgren_ has joined #craton | 21:52 | |
| *** klindgren has quit IRC | 21:53 | |
| *** klindgren__ has joined #craton | 22:22 | |
| *** klindgren_ has quit IRC | 22:24 | |
| *** klindgren_ has joined #craton | 23:13 | |
| *** klindgren__ has quit IRC | 23:15 | |
| *** valw has joined #craton | 23:29 | |
| *** valw has quit IRC | 23:52 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!