| *** valw has joined #craton | 00:25 | |
| *** Syed__ has quit IRC | 01:05 | |
| *** VW has joined #craton | 04:13 | |
| *** VW has quit IRC | 04:18 | |
| *** VW has joined #craton | 04:18 | |
| *** valw has quit IRC | 04:39 | |
| *** VW has quit IRC | 04:39 | |
| *** valw has joined #craton | 05:39 | |
| *** valw has quit IRC | 05:44 | |
| *** lcastell has quit IRC | 06:13 | |
| *** lcastell has joined #craton | 06:15 | |
| *** valw has joined #craton | 07:41 | |
| *** valw has quit IRC | 07:46 | |
| *** valw has joined #craton | 09:42 | |
| *** valw has quit IRC | 09:46 | |
| tojuvone | Proposed openstack/nova-specs master: Add Host Details https://review.openstack.org/428070 | 10:10 |
|---|---|---|
| tojuvone | Need to add better link there for the use case later. | 10:11 |
| tojuvone | Timing is still quite ok in history of Nova doing BP review. | 10:14 |
| sulo | o/ | 10:40 |
| sulo | jimbaker: thats fair comment on https://review.openstack.org/#/c/427717/ .. we need to circle back to that | 11:52 |
| sulo | jimbaker: actually, resolved vars in this case might not make sense | 11:54 |
| git-harry | I would have thought you'd want to be able to search both ways | 11:54 |
| sulo | jimbaker: resolved vars say in hosts = all hosts | 11:54 |
| sulo | since its coming from one step up | 11:54 |
| sulo | git-harry: how do you mean both ways ? | 11:57 |
| sulo | like --resolved=false | 11:57 |
| sulo | or --resolved=true we do for vars in general ? | 11:57 |
| git-harry | sulo: yeah, so you may want to know which devices have a particular value so see what their current config is, but if changing config it's possible that you may want to set something at a higher level and be sure it is going to be applied everywhere you expect. If the device and say cell both have the same value, when the cell is updated the device won't inherit the correct value. I think it would be preferable to | 12:00 |
| git-harry | know that ahead of time. | 12:00 |
| sulo | git-harry: rgr, yeah that sounds like the right use case to go for | 12:02 |
| sulo | going to create a bug for now | 12:02 |
| * sulo thinks we need to put a bit more thought and work into /networks /network-devices and /network-interfaces design | 12:35 | |
| *** VW has joined #craton | 12:37 | |
| *** VW has quit IRC | 12:45 | |
| sulo | now here is a question, re: https://github.com/openstack/craton/blob/master/craton/api/v1/schemas.py#L442 | 12:52 |
| sulo | do we need to require ip_address to make a network interface ? | 12:52 |
| *** valw has joined #craton | 13:43 | |
| *** VW has joined #craton | 13:47 | |
| *** valw has quit IRC | 13:48 | |
| jimbaker | sulo, re required ip_address, surely in some form, right? | 14:25 |
| jimbaker | the only counterexample i can think of is needing to create a placeholder before the ip address is specified | 14:26 |
| thomasem | Depends on the type of interface. That's L2, so IP address shouldn't be required if you're wanting to represent an actual network interface. | 14:36 |
| thomasem | Some types of interfaces have no IP address, only MAC. | 14:36 |
| thomasem | Think trunk ports and such | 14:36 |
| sulo | thomasem: exactly, its not that they dont need it ... you can have an interface without ip associated yet | 14:36 |
| thomasem | Absolutely | 14:36 |
| jimbaker | thomasem, sulo, got it | 14:37 |
| thomasem | The coupling of the two caused a HUGE problem in Neutron when trying to handle nested ports and there was a desire for "late-binding", though I can't remember the use-case. | 14:37 |
| thomasem | Shared IPs work was impacted pretty heavily by that limitation | 14:37 |
| thomasem | Since only one interface was supposed to have the allocated IP at a time. | 14:38 |
| thomasem | But N interfaces could potentially have it. | 14:38 |
| thomasem | :thumbsup: | 14:38 |
| jimbaker | so the intent here is simple for craton: we want to have a simple model of networks, which can then connect into the device tree (i would assume at the switch level, possibly we care about cabinet networking as well but i see that as unlikely, it's implied by the switch) | 14:39 |
| jimbaker | so the network interface shows that switch-1 is on the same network as switch-2, switch-3, ...; and it has some useful properties we want to break out as db columns | 14:40 |
| jimbaker | so basic topology | 14:41 |
| thomasem | Would we also be indicating which host is plugged into which switch? | 14:42 |
| jimbaker | more importantly, that we have enough info to go to a source of truth (an actual network manager tooling, something like neutron); and that as desired we could supplement with extra variables as a cmdb | 14:42 |
| jimbaker | thomasem, we could, but it seems to be implied by the device tree | 14:43 |
| thomasem | Oh, so you'd have region -> cabinet -> switch -> host | 14:43 |
| jimbaker | correct me if i'm wrong, but the typical cab is a top-of-rack switch + a bunch of physical hosts | 14:43 |
| thomasem | Might be a little more complicated with multiple switches for, like, HA. | 14:44 |
| thomasem | But, I'm not as familiar. I'd need to go bug the network architects. :P | 14:44 |
| jimbaker | thomasem, in that case, we could model the networks separately | 14:44 |
| thomasem | Yeah, I'm wondering if we need the ability to represent them as peers and parents to the same hosts. | 14:45 |
| *** VW has quit IRC | 14:45 | |
| thomasem | What do you mean by model networks separately? | 14:45 |
| thomasem | jimbaker: ^^ | 14:46 |
| jimbaker | thomasem, in general, we have resisted arbitrary graphs because they make queries more expensive; and you rapidly get into "multiple inheritance" like problems | 14:46 |
| thomasem | Because of the possibility of two TORs on a cab? | 14:46 |
| jimbaker | so the only true graph like structure we support is a network | 14:46 |
| jimbaker | but variable resolution is not available from a network to its interfaces to its devices... | 14:47 |
| *** VW has joined #craton | 14:48 | |
| jimbaker | thomasem, any host/device can connect to a network via a network interface in the model | 14:48 |
| jimbaker | i'm just asking if that's always desired, because the real intent is to look at this at the level where we really start to see a network emerging | 14:49 |
| thomasem | Hmmmm | 14:50 |
| jimbaker | that is, at the cab level | 14:50 |
| jimbaker | (assuming non redundancy in the cab) | 14:50 |
| thomasem | Well, I think the network a host can connect to depends on the cab its in by being limited to the TOR(s) in that cab. | 14:51 |
| thomasem | You wouldn't plug a host in cab a into a switch in cab b. | 14:51 |
| thomasem | At least, I don't imagine one would. | 14:52 |
| sulo | jimbaker: i suggest we change <>-get/set-vars to <>-vars-get/set | 14:52 |
| sulo | ill suggest that in your patch | 14:52 |
| jimbaker | sulo, to better reflect the hierarchy? yeah, that makes sense | 14:53 |
| sulo | its easier to type from one to the other :) | 14:53 |
| jimbaker | sulo, and similar with host-labels-set/host-labels-get; and <resource>-roles-set/resource-roles-get | 14:54 |
| sulo | yeah | 14:54 |
| jimbaker | next obvious things to add as we get to them | 14:54 |
| jimbaker | also presumably <resource>-vars-delete, although i was think that something like host-vars-delete x= y= could be a synonym, since it's unambiguous | 14:55 |
| jimbaker | sorry, i meant to sa | 14:56 |
| jimbaker | say | 14:56 |
| jimbaker | host-vars-set x= y= | 14:56 |
| jimbaker | although perhaps confusing for command line usage; export FOO= is not the same as unset FOO | 14:58 |
| jimbaker | so maybe host-vars-set x= y= is the same as saying x=null, y=null | 15:04 |
| jimbaker | sulo, thoughts? | 15:04 |
| sulo | i like -delete | 15:05 |
| sulo | like: host-vars-delete x | 15:06 |
| jimbaker | yeah, keep it simple | 15:06 |
| jimbaker | and there's no way to do delete using json from stdin, host-vars-set < cannot-delete-only-set-values.json | 15:08 |
| sulo | yeah | 15:08 |
| jimbaker | the only downside is there's no way to delete AND set in a single transaction. but i see that more interesting with respect to say multiple hosts. anyway, if we find grouping ops that make sense for single unit of work, we can expose at the rest api level, down to cli | 15:10 |
| jimbaker | by with respect to multiple hosts, i mean you might want to atomically set x=up for host1 AND set x=down for host2 to show that host1 is taking over for host2. something like that. anyway, that's highly speculative fornow | 15:12 |
| *** VW has quit IRC | 15:28 | |
| tojuvone | jimbaker, sulo I once had CLI with "start transaction" and "end transaction". Otherwise single CLI call was one transaction. | 15:29 |
| *** VW has joined #craton | 15:30 | |
| tojuvone | but that worked with cli commands read from a file, or when run under on shell, not bash | 15:32 |
| tojuvone | guess not openstackish way to use | 15:32 |
| sigmavirus | jimbaker: why wouldn't cannot-delete-only-set-values.json look like `["x", "y", ...]`? | 15:33 |
| *** valw has joined #craton | 15:44 | |
| jimbaker | sigmavirus, good point | 15:47 |
| jimbaker | a list could be used at the top level, since it's not legal otherwise | 15:48 |
| *** valw has quit IRC | 15:48 | |
| jimbaker | tojuvone, also not a good REST practice, in terms of the underlying API support | 15:55 |
| *** jovon has joined #craton | 16:14 | |
| *** VW has quit IRC | 16:18 | |
| *** VW has joined #craton | 16:18 | |
| *** VW has quit IRC | 16:18 | |
| *** VW has joined #craton | 16:19 | |
| *** Syed__ has joined #craton | 16:43 | |
| jimbaker | sulo and i may be joining a bit late the upcoming meeting in one min | 16:59 |
| sulo | i am going to miss it | 16:59 |
| jimbaker | ok, here | 17:08 |
| jimbaker | #startmeeting craton | 17:08 |
| openstack | Meeting started Thu Feb 2 17:08:20 2017 UTC and is due to finish in 60 minutes. The chair is jimbaker. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:08 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:08 |
| openstack | The meeting name has been set to 'craton' | 17:08 |
| sulo | i am going to have to miss the meeting today .. need to take care of something .. | 17:08 |
| sulo | will read the scrollback in an hour | 17:08 |
| jimbaker | #chair sigmavirus sulo jimbaker | 17:08 |
| openstack | Current chairs: jimbaker sigmavirus sulo | 17:08 |
| jimbaker | #link https://etherpad.openstack.org/p/craton-meetings | 17:09 |
| jimbaker | git-harry, jovon, sigmavirus, Syed__, thomasem, hi | 17:09 |
| git-harry | hi | 17:10 |
| jovon | hey | 17:10 |
| sigmavirus | hi there | 17:11 |
| Syed__ | O/ | 17:11 |
| jimbaker | so we just another demo, and we had some great questions from brian stein in particular | 17:11 |
| Syed__ | Did we prepare a document or something for that ? | 17:12 |
| jimbaker | the meeting? | 17:12 |
| Syed__ | Yeah or notes, will be handy to know | 17:12 |
| jimbaker | Syed__, we presented a few slides from our pres at openstack barcelona - architecture, some motivation from rackspace public cloud | 17:13 |
| Syed__ | Ohh i see | 17:13 |
| thomasem | o/ | 17:13 |
| jimbaker | we then went through a demo of current functionality available from the CLI, including how variables work | 17:13 |
| jimbaker | showing overrides. could have mentioned the motivation from the openstack ansible team, but we didn't | 17:14 |
| jimbaker | in terms of notes | 17:14 |
| jimbaker | first, we will continue our focus on the cmdb/inventory aspects. multitenancy is a key differentiator for this project; as well some specific knowledge of how clouds should be managed | 17:15 |
| jimbaker | thomasem, your work on project vars, and projects in general, will be helpful sooner than later | 17:16 |
| thomasem | +1 | 17:16 |
| jimbaker | so thanks for your first change, and we will work that through and get it in | 17:16 |
| thomasem | Yeah, I think I'm close to fixing that one problem, then it'll be writing tests (hopefully) | 17:16 |
| jimbaker | it would be helpful for future demos to show navigation through projects; and being able to search accordingly by vars | 17:17 |
| jimbaker | another thing that came up is being able to search via labels, and then make corresponding changes | 17:17 |
| jimbaker | but the key thing i heard is "how do we manage a lot of special snowflakes" | 17:18 |
| jimbaker | each project (= a customer cloud) has its own needs; but we need to manage efficiently | 17:18 |
| jimbaker | another key thing i heard is, what specifically are we doing to help in fact manage these snowflakes | 17:19 |
| Syed__ | jimbaker: sorry to interrupt, what do you mean by snowflakes ? | 17:19 |
| Syed__ | as in environment snowflakes ? | 17:20 |
| jimbaker | as in, each snowflake is different | 17:20 |
| Syed__ | ok | 17:21 |
| jimbaker | http://www.keplersdiscovery.com/SixCornered.html | 17:21 |
| Syed__ | cool, will go through it | 17:21 |
| jimbaker | which is one of the first works of mathematical physics | 17:21 |
| jimbaker | i don't want to elaborate too much on snowflakes, per se :) | 17:22 |
| Syed__ | +1 | 17:22 |
| thomasem | Lol | 17:22 |
| jimbaker | but snowflakes may all be different, but they share commonality | 17:22 |
| jimbaker | the point of craton is to manage the different snowflakes of how clouds are setup; but to know that they share certain features | 17:23 |
| jimbaker | and much of what drives stuff for us, like variables and how they resolve - that's commonality | 17:23 |
| jimbaker | same with having strong opinions on how to relationally look at the world - the project/region/cell hierarchy (and we forgot to mention, cells are optional and there can be just a single region) | 17:25 |
| jimbaker | etc etc | 17:25 |
| jimbaker | anyway, i expect further questions and demos to come up to address what was discussed today | 17:25 |
| jimbaker | farid, thomasem, anything else you want to add? | 17:26 |
| thomasem | Nothing else from me. :) | 17:27 |
| jimbaker | another ask from toan: we need to show the device tree with the CLI. hopefully by next week | 17:27 |
| jimbaker | basically "containers should be addressable" (i think that's close to what he said) | 17:28 |
| farid | jimbaker: not at the moment thanks | 17:28 |
| jimbaker | but i think the demo went reasonably well. tough questions, but people respected the work we put in | 17:30 |
| jimbaker | perhaps the biggest question is: are we effectively biting off more than we can chew, so to speak? | 17:30 |
| jimbaker | but again, that's why we are focusing on cmdb for the time being, and then expanding that out (so "inventory fabric" is still a next step for us) | 17:31 |
| Syed__ | hmm .. | 17:31 |
| jimbaker | ok, that's everything i got | 17:31 |
| jimbaker | anything else? i didn't prepare a specific agenda for today, because we were focused on this earlier meeting that i summarized | 17:33 |
| Syed__ | i am good right now | 17:34 |
| jimbaker | cool, please look at the outstanding reviews in https://review.openstack.org/#/q/status:open+craton | 17:35 |
| jimbaker | and we can all get back to work | 17:36 |
| jimbaker | #endmeeting | 17:36 |
| openstack | Meeting ended Thu Feb 2 17:36:23 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:36 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-02-02-17.08.html | 17:36 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-02-02-17.08.txt | 17:36 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-02-02-17.08.log.html | 17:36 |
| jimbaker | git-harry, thanks for putting together the var api spec. i will closely review. but i know after going through the round of working on the var setters/getters for resources in the client and CLI that this spec is something we certainly need! | 17:38 |
| jimbaker | also hopefully we can write some good general purpose code to simplify adding variable support to any resource in our api; we will want the same for rbac soon enough | 17:38 |
| jimbaker | in particular, this impacts work like thomasem's on https://review.openstack.org/#/c/427777/ | 17:39 |
| thomasem | Yeah. It's a whole lot of tracing around trying to figure out each piece that has to be added. | 17:40 |
| git-harry | jimbaker: yeah, it will be good to bounce some ideas around and see what we come up with. | 17:40 |
| jimbaker | thomasem, yeah, and we need to make that less the case. because as i noted in the bug, variables are sort of our default way to offer the flexibility that craton needs to support as a cmdb | 17:41 |
| jimbaker | https://bugs.launchpad.net/craton/+bug/1648626 | 17:41 |
| openstack | Launchpad bug 1648626 in craton "Projects should support variables, which other entities use in resolution" [Wishlist,In progress] - Assigned to Thomas Maddox (thomas-maddox) | 17:41 |
| jimbaker | it comes up with project because it's at the top of all the current and possible resolution hierarchies discussed there | 17:41 |
| thomasem | Yerp | 17:42 |
| thomasem | Well, what I'm noticing is when I create the project from the REST API, variables seems to work fine. | 17:42 |
| jimbaker | and it's absolutely essential to get the "different snowflake" work as expected | 17:42 |
| thomasem | So, it's the backchannel for this test data that seems to be causing some fuss here. | 17:42 |
| jimbaker | but not the starter project? | 17:42 |
| thomasem | Correct | 17:42 |
| jimbaker | got it | 17:42 |
| jimbaker | that is more reassuring | 17:42 |
| thomasem | Haha, yeah | 17:43 |
| thomasem | I was so confused, because I basically followed the other implementations | 17:43 |
| thomasem | So, getting there. :) | 17:43 |
| jimbaker | because the starter project is sort of a cheat, with respect to using the db to create | 17:43 |
| thomasem | Ahhhhhh | 17:44 |
| thomasem | That would definitely do it. | 17:44 |
| thomasem | Because it doesn't get the entry in variable_associations | 17:44 |
| thomasem | which breaks the relationship and causes project.variables to be None instead of {} | 17:44 |
| thomasem | from the DB | 17:44 |
| jimbaker | yes! | 17:44 |
| jimbaker | you are so right | 17:44 |
| thomasem | variable_association* | 17:44 |
| jimbaker | yep, that's absolutely necessary | 17:44 |
| jimbaker | normally sqlalchemy is doing this mgmt for us | 17:45 |
| thomasem | Yep | 17:45 |
| jimbaker | but we bypass by doing the raw sql | 17:45 |
| thomasem | That's what I wanted to exercise with the REST API create | 17:45 |
| *** valw has joined #craton | 17:45 | |
| jimbaker | so.... really good! | 17:45 |
| thomasem | Won't the project get created automatically via the call in validators.py? | 17:45 |
| jimbaker | as i said just now, when you noticed the diff, "that is more reassuring" | 17:45 |
| thomasem | Which did seem like an odd location to be doing DB CRUD. | 17:45 |
| thomasem | https://github.com/openstack/craton/blob/master/craton/api/v1/validators.py#L291 | 17:46 |
| jimbaker | thomasem, yeah, that's not good | 17:46 |
| thomasem | With that, what's the reason to bypassing and going with raw SQL? | 17:47 |
| jimbaker | automagically creating projects is just a little too special for these snowflakes | 17:47 |
| jimbaker | thomasem, purely historical | 17:47 |
| jimbaker | that usage needs to die | 17:47 |
| thomasem | Okay. I'll open a bug. | 17:47 |
| jimbaker | thomasem, cool | 17:48 |
| jimbaker | i do believe the root user needs to stay on a little longer | 17:48 |
| jimbaker | however, we shouldn't create the demo user that way | 17:48 |
| *** valw has quit IRC | 17:49 | |
| thomasem | Yeah... we could stand to move this all to the gen script. | 17:51 |
| thomasem | Problem is, I think there's a bug with the Projects REST API where if you try to provide an ID it's expecting an Integer, not UUID. | 17:51 |
| thomasem | So, that's two bugs, now | 17:52 |
| jimbaker | thomasem, so it should be something like mysql -ucraton -pcraton craton -e "INSERT into users (created_at, updated_at, project_id, username, api_key, is_root, is_admin) values (NOW(), NOW(), 1, 'root', 'root', true, true)" | 17:52 |
| thomasem | So we're wanting to give demo user root/admin | 17:52 |
| thomasem | for now | 17:52 |
| jimbaker | thomasem, i'm pretty sure it can take a uuid, but not one that has additional encoding in it | 17:52 |
| jimbaker | namely internal hyphens | 17:53 |
| jimbaker | but one or the other, it's a bug | 17:53 |
| jimbaker | thomasem, actually i don't want the demo user to have those privileges | 17:53 |
| jimbaker | we just need a root user | 17:53 |
| thomasem | jimbaker: {"errors": ["'f247fd60391b4c819726bf409f0885ca' is not of type 'integer'"], "message": "Unprocessable Entity"} | 17:53 |
| jimbaker | maybe call it the bootstrap user | 17:53 |
| thomasem | jimbaker: that's what I was thinking. I'll add a create for admin | 17:54 |
| jimbaker | thomasem, cool, so that's what we we fix | 17:54 |
| thomasem | Why not root? | 17:54 |
| jimbaker | i like "bootstrap" | 17:54 |
| jimbaker | because in the future, this whole root stuff, etc, goes away with actual rbac | 17:54 |
| thomasem | Eh, not the hill I'm going to die on. I'll make it so. | 17:54 |
| jimbaker | but we will still need a privileged user to start everything off, then it's effectively never used again | 17:55 |
| thomasem | Right | 17:55 |
| jimbaker | "bootstrap" sort of conveys that. maybe "bootstrap-user-do-not-use-if-you-are-not-bootstrapping-got-it" might be better | 17:55 |
| jimbaker | ;) | 17:56 |
| *** VW has quit IRC | 17:56 | |
| thomasem | bootstrap is fine ; | 17:57 |
| thomasem | ;) | 17:57 |
| jimbaker | yeah, i think so too | 17:57 |
| *** VW has joined #craton | 17:57 | |
| thomasem | XD I need to step away. I've been going too long and am making silly mistakes now. bbiab. | 18:25 |
| Syed__ | jimbaker: you around ? | 19:04 |
| jimbaker | in meeting | 19:05 |
| Syed__ | okay | 19:05 |
| jimbaker | Syed__, hi | 19:24 |
| *** valw has joined #craton | 19:46 | |
| *** valw has quit IRC | 19:50 | |
| Syed__ | sorry for delayed response jimbaker | 19:54 |
| Syed__ | i actually was looking into https://bugs.launchpad.net/craton/+bug/1659428 | 19:55 |
| openstack | Launchpad bug 1659428 in craton "CLI requires region id for commands" [Undecided,New] | 19:55 |
| sulo | back | 20:04 |
| sulo | thomasem: the find_or_crate_project is only for keystone context | 20:07 |
| jimbaker | Syed__, i fixed that in https://review.openstack.org/#/c/427032/ | 20:07 |
| jimbaker | may need to pull it out, but pretty minor change | 20:08 |
| jimbaker | pull it out into a separate change | 20:08 |
| jimbaker | (i was focused more on ensuring we had something that demoed as well as possible... so needed to compact some work i suppose) | 20:09 |
| Syed__ | Okay, should i pull that into a seperate change ? | 20:09 |
| Syed__ | Or should we just reference that into the same oncme | 20:10 |
| Syed__ | One^ | 20:10 |
| thomasem | sulo: Okay, so, I guess that's for if we're going through Keystone instead of the Users table in Craton? | 20:11 |
| thomasem | It'll then create said project in Craton | 20:11 |
| sulo | thomasem: yeah, but i do agree that its a bit odd to do that | 20:11 |
| sulo | i think there is a reason why sigmavirus had to do that .. cant remember now | 20:12 |
| thomasem | Feels prone to orphans, too. | 20:12 |
| sulo | yeah | 20:12 |
| sigmavirus | sulo: thomasem because we have tables with FK constraints iirc | 20:12 |
| sigmavirus | and they index on that constraint as well | 20:12 |
| *** VW has quit IRC | 20:13 | |
| sulo | ah yeah .. is that user check | 20:14 |
| thomasem | Gotcha | 20:15 |
| sulo | thomasem: https://github.com/openstack/craton/blob/master/craton/api/middleware.py#L91 .. so maybe we need to circle back to this | 20:15 |
| sulo | i think what we need is first to decide what root/admin/normal users mean | 20:16 |
| thomasem | ERROR 1452 (23000) at line 1: Cannot add or update a child row: a foreign key constraint fails (`craton`.`users`, CONSTRAINT `users_ibfk_1` FOREIGN KEY (`project_id`) REFERENCES `projects` (`id`)) | 20:16 |
| thomasem | Gotcha | 20:16 |
| thomasem | I'll take a closer look at that in a bit here. Under the hood on my patch. | 20:17 |
| sulo | so maybe with proper rbac we dont need this check | 20:17 |
| sulo | and that will take most of this crazy code out | 20:17 |
| sulo | rgr | 20:18 |
| jimbaker | Syed__, it's two line of changes or so. i don't think we will separately change | 20:25 |
| Syed__ | jimbaker: Roger that | 20:25 |
| jimbaker | more important is getting column order sorted properly in say region-list or host-list | 20:26 |
| sulo | yeah that needs to be fixed in all | 20:27 |
| jimbaker | https://bugs.launchpad.net/craton/+bug/1659427 | 20:27 |
| openstack | Launchpad bug 1659427 in craton "CLI is inconsistent in ordering columns" [Undecided,New] | 20:27 |
| jimbaker | related high priority item is json support | 20:27 |
| jimbaker | https://bugs.launchpad.net/craton/+bug/1659438 | 20:28 |
| openstack | Launchpad bug 1659438 in craton "CLI does not support formatting options" [Undecided,New] | 20:28 |
| jimbaker | sulo, so getting the device tree exposed down to the CLI was a high priority item for tuan | 20:29 |
| jimbaker | it is in dbapi; https://github.com/openstack/craton/blob/master/craton/db/sqlalchemy/models.py#L348 and related ancestors | 20:30 |
| jimbaker | the following property after that line | 20:30 |
| sulo | yeah so there is quite a bit of work on that front | 20:30 |
| jimbaker | yeah | 20:30 |
| sulo | we need to maybe rework network/-x related functions too | 20:30 |
| jimbaker | i don't think it's so much, just a question of doing the navigation | 20:30 |
| jimbaker | in the python client | 20:30 |
| sulo | so i guess first we need to decide if we need to expose any more data on api side | 20:31 |
| sulo | i dont think we are even sending out parent_id right now | 20:32 |
| jimbaker | a related question is the CLI should take a hostname, etc instead of the id as its arg. this will improve ergonomics, as i mentioned in the WIP branch on var getter/setters | 20:32 |
| sulo | and even if we did .. is that sufficient .. do we need to expore more than that and actually make a parent-child tree and send that out | 20:32 |
| jimbaker | sulo, if we just expose to REST API thast would suffice | 20:32 |
| jimbaker | client can take care of navigation from there | 20:32 |
| sulo | but that would be multiple calls vs one if api did that | 20:33 |
| jimbaker | we could provide some API helpers to get trees, but parent/child suffices for now | 20:33 |
| sulo | sine some folks are already talking about hammering the api to test etc .. might be better to have db do this redily | 20:33 |
| sulo | readily even | 20:34 |
| sulo | the other thing is the "cab" view | 20:34 |
| jimbaker | i'm not too concerned about these types of links | 20:34 |
| jimbaker | sulo, ahh, yes, so this is interesting, and there could be a valid helper for this | 20:35 |
| jimbaker | any such "cab view" should use existing resources in the python client | 20:35 |
| jimbaker | as it walks the returned result | 20:36 |
| jimbaker | but i see this view as particularly important; and ideally would be efficient | 20:36 |
| jimbaker | vs just arbitrary trees being returned | 20:36 |
| jimbaker | that could capture other combo queries | 20:36 |
| sulo | jimbaker: so i think we have a few really important buch of work that needs completion asap in my view | 20:39 |
| sulo | 1) rabc | 20:40 |
| sulo | 2) this parent/child tree, cab view | 20:40 |
| sulo | 3) cleaning up the project/user stuff | 20:40 |
| jimbaker | so in order of effort and also priority (fortunately they the same here as i see it): #2, #3, #1 | 20:41 |
| jimbaker | cleaning up user would also be helpful so we can get the principal stuff implemented as part of the work for #1 - it would be nice to be prepped for that | 20:42 |
| sulo | 3 cant be done without 1 | 20:42 |
| jimbaker | #3 is extremely important to the multitenant concerns; #1 is the completion | 20:43 |
| jimbaker | to the full extent yes. i guess it depends on what is meant by "cleaning up" | 20:43 |
| sulo | its not possible to really clenup projec and especially user without rbac | 20:43 |
| jimbaker | sulo, i understand where you are coming from. we just need to finish up that work i started with that blueprint | 20:44 |
| jimbaker | https://blueprints.launchpad.net/craton/+spec/craton-rbac-support | 20:44 |
| jimbaker | the scoped role assignments work well, i just need to update that patch and put it in WIP | 20:45 |
| sulo | yeah push it out as WIP .. more ideas can flow then | 20:45 |
| jimbaker | yep | 20:45 |
| sulo | ill start looking at 2 | 20:45 |
| jimbaker | cool, that will free me up, since i was planning to look at it :) | 20:45 |
| sulo | i want to look at this network - cab view anyway so it will be same type work | 20:46 |
| jimbaker | and i will let you take back that fake data generation stuff for network interfaces | 20:46 |
| sulo | jimbaker: yeah no worries, you should finish up the rbac stuff .. that will open a whole new set of bp's | 20:46 |
| jimbaker | thomasem should have some good ideas here too | 20:46 |
| jimbaker | yes, i just need to focus on it | 20:46 |
| jimbaker | there is a bunch of other cool stuff to do | 20:47 |
| jimbaker | (secrets, auditing/notification, virtualized variables... but need to focus right now on rbac) | 20:47 |
| jimbaker | ok, that's a good high level description of what we need to do next. i like it | 20:48 |
| *** valw has joined #craton | 20:55 | |
| sulo | palendae: https://github.com/openstack/craton/blob/master/doc/source/dev/install.rst | 20:56 |
| palendae | sulo: Nice! Could a link/ref to that go in the readme? | 20:58 |
| sulo | yeah i think its not clear, so we could add links there | 20:58 |
| palendae | Sweet, thanks! | 20:59 |
| palendae | I didn't look close enough, didn't realize there was a docs dir | 20:59 |
| *** valw has quit IRC | 21:00 | |
| *** harlowja has quit IRC | 21:00 | |
| thomasem | Ahhh, man... we also generate the same test data in the functional test setup | 21:19 |
| thomasem | That confused me. I was trying to use the bootstrap user from docker_run.sh that I created, but I guess that doesn't happen for the functional tests? | 21:20 |
| thomasem | So, had to also add it to the test setup. | 21:20 |
| thomasem | I'm not sure I understand why the Docker container setup in the tests don't cause docker_run.sh to run and set things up for us? | 21:23 |
| jimbaker | thomasem, actually recent change sulo made to make things more isolated | 21:23 |
| jimbaker | in those functional tests | 21:23 |
| thomasem | Goootcha | 21:23 |
| jimbaker | i could see having an initial data set could be a good idea for those tests, such as what's in fake data | 21:24 |
| sulo | jimbaker: thomasem:we were doing fake data run .. but i took that off | 21:24 |
| jimbaker | but most importantly, we need them isolated | 21:24 |
| thomasem | Oh, yes. We need users and such set up. I was just more wondering why I was having to add things in so many places. :) | 21:24 |
| sulo | didnt make sense to test create ... by external script creating sutff etc .. also needed to make each test isolated | 21:25 |
| thomasem | Riiight | 21:25 |
| thomasem | Agreed | 21:25 |
| thomasem | But why doesn't docker_run.sh run when you create the container in the functional tests? | 21:25 |
| thomasem | I'm clearly missing something. | 21:25 |
| jimbaker | but a better fixture setup that would be nice | 21:25 |
| sulo | it does | 21:25 |
| sulo | thomasem: it does | 21:26 |
| sulo | thomasem: if you looking for project to exist .. then i took that off too :) | 21:26 |
| thomasem | sulo: OH I see | 21:26 |
| thomasem | it runs, THEN we delete it in the tests and bootstrap ourselves. | 21:26 |
| thomasem | https://github.com/openstack/craton/blob/master/craton/tests/functional/__init__.py#L145 | 21:27 |
| thomasem | Should have eyeballed that note a bit closer. | 21:27 |
| thomasem | Nah, I need a root user | 21:27 |
| thomasem | To do /projects stuff for functional tests | 21:27 |
| jimbaker | sulo, so this is the "bootstrap" user we were discussing earlier on the log | 21:27 |
| thomasem | Yeah, I didn't want to impact the existing demo user with new privileges | 21:27 |
| thomasem | in case we want to test specifically that - privileges. | 21:28 |
| sulo | thomasem: so i suggest you do that as part of test setup | 21:28 |
| thomasem | I am | 21:28 |
| jimbaker | presumably it's only needed to get us to real users once we have rbac | 21:28 |
| thomasem | Just added that | 21:28 |
| sulo | gotcha | 21:28 |
| thomasem | And my functional test passed from doing so | 21:28 |
| thomasem | Soooo, now for the rest | 21:28 |
| thomasem | :) | 21:28 |
| sulo | sorry .. otherwise the docker_run.sh user/project would be problem .. because to cleanup db i would have to leave those two tables | 21:28 |
| sulo | it was cleaner to just nuke all table and do each test isolated | 21:29 |
| thomasem | Nah, I hear ya. We'll iterate on it. No problemo. | 21:29 |
| sulo | so user/project test had one extra bit to bootstrap them as part of the setup | 21:29 |
| thomasem | As we get RBAC and such added, we'll have to re-imagine some of this and I think it'll get easier to work with in the long-run. | 21:30 |
| sulo | yeah agreed | 21:30 |
| thomasem | Still, my hat's off for how easy it was for me to get started. Probably the quickest start to bug fix in history for me. | 21:31 |
| thomasem | And that was even with my own dev environment shenanigans getting in my way. | 21:31 |
| sulo | cool :) | 21:32 |
| jimbaker | thomasem, really appreciate the feedback. let's keep it this way, it took us a while to get here! | 21:37 |
| *** VW has joined #craton | 21:38 | |
| jimbaker | next step is to add something like `tox -e integration` to python-cratonclient which runs integration tests from the client to the craton service. or a project that pulls from both, doesn't matter to me | 21:38 |
| *** harlowja has joined #craton | 22:25 | |
| *** harlowja has quit IRC | 22:32 | |
| *** harlowja has joined #craton | 22:33 | |
| -openstackstatus- NOTICE: Restarting gerrit due to performance problems | 22:50 | |
| *** VW has quit IRC | 22:52 | |
| *** VW has joined #craton | 23:07 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!