| *** jovon has quit IRC | 00:11 | |
| *** valw has joined #craton | 00:56 | |
| *** valw has quit IRC | 01:02 | |
| *** VW has quit IRC | 01:59 | |
| *** VW has joined #craton | 02:32 | |
| *** Syed__ has quit IRC | 02:35 | |
| *** VW has quit IRC | 02:56 | |
| *** VW has joined #craton | 03:33 | |
| *** VW has quit IRC | 03:55 | |
| *** VW has joined #craton | 03:56 | |
| *** VW has quit IRC | 04:01 | |
| *** jcannava has quit IRC | 04:23 | |
| *** jcannava has joined #craton | 04:25 | |
| *** VW has joined #craton | 04:47 | |
| *** VW has quit IRC | 04:53 | |
| *** valw has joined #craton | 04:58 | |
| *** valw has quit IRC | 05:03 | |
| *** VW has joined #craton | 07:13 | |
| *** VW has quit IRC | 07:18 | |
| *** VW has joined #craton | 08:28 | |
| *** VW has quit IRC | 08:33 | |
| *** valw has joined #craton | 08:59 | |
| *** valw has quit IRC | 09:04 | |
| *** VW has joined #craton | 09:59 | |
| *** VW has quit IRC | 10:04 | |
| *** VW has joined #craton | 11:17 | |
| *** VW has quit IRC | 11:21 | |
| *** tojuvone has quit IRC | 11:26 | |
| thomasem | o/ | 11:33 |
|---|---|---|
| *** tojuvone has joined #craton | 11:56 | |
| sulo | o/ | 12:19 |
| thomasem | Alright, I think this guy's out of WIP and ready for final review: https://review.openstack.org/#/c/427777/15 | 12:25 |
| thomasem | Oop, lemme give better link https://review.openstack.org/#/c/427777 | 12:25 |
| thomasem | Don't like it referencing the patch set #. | 12:25 |
| *** VW has joined #craton | 12:32 | |
| *** VW has quit IRC | 12:37 | |
| *** VW has joined #craton | 13:40 | |
| *** VW has quit IRC | 13:41 | |
| *** VW has joined #craton | 13:41 | |
| *** VW has quit IRC | 13:45 | |
| *** Syed__ has joined #craton | 15:56 | |
| thomasem | Hmmm... I think we might be getting back inconsistent data types for project ID from the db api. | 16:00 |
| thomasem | sometimes it's UUID type, other times it's str | 16:00 |
| sigmavirus | thomasem: oh? | 16:01 |
| sigmavirus | It should always be UUID type | 16:01 |
| thomasem | Okay, lemme confirm. Could be something I did wrong. | 16:01 |
| thomasem | Thanks for the clarification. | 16:01 |
| *** VW has joined #craton | 16:03 | |
| thomasem | TEM create: <class 'str'> | 16:05 |
| thomasem | TEM by_id: <class 'uuid.UUID'> | 16:05 |
| thomasem | Yeah, on create it returns a Project object with an str ID attribute, and on get it returns a Project with a UUID type id. | 16:05 |
| jimbaker | right, we like to keep it in the abstract type to the extent possible | 16:06 |
| thomasem | sigmavirus: ^^ | 16:06 |
| jimbaker | same with ip addresses, etc | 16:06 |
| jimbaker | or ints for that matter :) | 16:06 |
| thomasem | So.. you're saying that we want that behavior? | 16:06 |
| thomasem | Even though it's inconsistent Project objects from the dbapi | 16:06 |
| jimbaker | thomasem, we want consistent behavior | 16:06 |
| thomasem | Okay, so then this is a bug. :) | 16:06 |
| jimbaker | and we want to keep it in the closest possible type | 16:06 |
| jimbaker | so that gives you the acceptance criteria :) | 16:07 |
| jimbaker | fortunately, we are not writing this code in tcl | 16:07 |
| thomasem | Cool. Thanks. I'll write up the bug and work around it in the tests with notes. | 16:07 |
| thomasem | Oh? | 16:07 |
| thomasem | Thanks, btw sigmavirus, jimbaker | 16:09 |
| sigmavirus | thomasem: you're always welcome =) | 16:09 |
| thomasem | jimbaker: Speaking of acceptance criteria, did I adequately lay out what needs to be done for the project vars bug? https://bugs.launchpad.net/craton/+bug/1648626 | 16:10 |
| 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) | 16:10 |
| thomasem | Almost done with 1-4, and then going to do the CLI work | 16:10 |
| thomasem | Ran into some extra fun adding project to the resolution order when it came to fixing the tests, which is how I found the UUID/str bug above. | 16:11 |
| jimbaker | tcl is a formerly popular scripting language for writing web sites. but tcl treats everything as string | 16:11 |
| jimbaker | strings | 16:11 |
| thomasem | Ohhhh | 16:11 |
| thomasem | Hahahaha | 16:11 |
| jimbaker | it results in even more fun coercions than javascript ;) | 16:11 |
| thomasem | Yeah, no thank you. | 16:11 |
| thomasem | That sounds like a headache | 16:11 |
| jimbaker | very much so | 16:11 |
| jimbaker | dynamic typing, good. loose typing, no | 16:12 |
| thomasem | Haha, yeah. Well, I'm gaining new respect for strong typing nowadays. | 16:12 |
| jimbaker | maybe this is no typing for tcl? i have never thought about, or properly investigated. but i'm not going to | 16:12 |
| sigmavirus | "strongly typed" isn't a real thing | 16:12 |
| * sigmavirus puts on pedant hat | 16:12 | |
| thomasem | I went from Java/C++ to Javascript to Python to Golang. | 16:12 |
| sigmavirus | thomasem: oh you mean you like highly intelligent compilers that take advantage of static typing | 16:13 |
| sigmavirus | ;) | 16:13 |
| jimbaker | one could always write in pascal... | 16:13 |
| sigmavirus | Java -> C -> {Python,Perl} -> Clojure -> Python -> Rust for me | 16:13 |
| sigmavirus | (There were others along the way) | 16:13 |
| jimbaker | i'm not certain if any coercions were available. that goes way back | 16:14 |
| thomasem | sigmavirus: That's what I mean, yes. What did you think I meant? :) | 16:14 |
| sigmavirus | thomasem: I'm mostly teasing over the use of "strong" or "loose" w/r/t to typing | 16:14 |
| jimbaker | anyway, typing discussions involves lots of typing | 16:14 |
| sigmavirus | jimbaker: I wonder if we should add mypy to craton eventually and use typing | 16:15 |
| jimbaker | but the usual distinction i would make is between static and dynamic; as further refined by gradual typing systems | 16:15 |
| jimbaker | such as mypy | 16:15 |
| thomasem | jimbaker: I see what you did there. | 16:15 |
| sigmavirus | That wouldn't have caught this for thomasem but | 16:15 |
| thomasem | Haha, I | 16:15 |
| sigmavirus | for those of you using operating system editors (*cough* emacs) and IDEs, that would be useful ;) | 16:15 |
| thomasem | I'm sure we could go round-and-round on opinions of how different languages and compilers handle types. | 16:16 |
| jimbaker | sigmavirus, i certainly would approve for us adopting mypy as a type checker for our code | 16:16 |
| thomasem | Alright, folks. Going back under water. Want to fix these tests. If I can get this finished before the end of the week I'll feel productive. | 16:17 |
| jimbaker | that this can be done incrementally (gradual typing ftw!) is a huge plus | 16:17 |
| jimbaker | thomasem, +1 | 16:17 |
| sigmavirus | jimbaker: agreed. I've not had a project to really test out mypy on | 16:18 |
| sigmavirus | figured we'd use craton as the guinea | 16:18 |
| jimbaker | yep, and if i have a chance to get back into jython (specifically 3.x), it will be useful background as well | 16:20 |
| thomasem | Alright, would really appreciate eyes on https://review.openstack.org/#/c/427777 | 16:38 |
| thomasem | Oh, project isn't added to the CLI yet. | 17:14 |
| thomasem | Hmmm, so that'll block the project variables bug for a time until we shave that yak. | 17:14 |
| sigmavirus | heh | 17:17 |
| thomasem | https://bugs.launchpad.net/python-cratonclient/+bug/1659237 | 17:18 |
| openstack | Launchpad bug 1659237 in Craton's Python Client "Client is missing Project commands" [Undecided,New] | 17:18 |
| thomasem | Shall I pick that one up next, then? | 17:19 |
| thomasem | Then it'll probably follow https://review.openstack.org/#/c/427032/ | 17:20 |
| jimbaker | thomasem, yes, that would be a natural fit | 17:25 |
| jimbaker | i still need to finish up https://review.openstack.org/#/c/427032/ | 17:25 |
| jimbaker | although we got a lot of demo points out of it :) | 17:25 |
| thomasem | LOL yeah, I was wondering about that. | 17:25 |
| thomasem | But, now I remember we were demo'ing in-review stuff | 17:25 |
| thomasem | It's all good. I'll pick up adding project CLI commands, and then when that patch is done for cell/host/region vars, I'll follow-up with project vars support | 17:26 |
| jimbaker | thomasem, sounds like the right timing to me | 17:44 |
| antonym | hey guys, few questions when you have some time... have you thought about doing tenant -> *cloud* -> region -> cell -> host -> *container*? are you going to support loading multiple vars at once? and have you pieced together anything for like importing all variables from like ansible facts to import them as variables on a host so that i have a full picture of that inventory? | 17:50 |
| *** cloudnull has joined #craton | 17:51 | |
| *** thomasem has quit IRC | 17:56 | |
| *** empanada has quit IRC | 17:56 | |
| *** d34dh0r53 has quit IRC | 17:56 | |
| *** d34dh0r53 has joined #craton | 17:56 | |
| *** anonymike has joined #craton | 17:57 | |
| *** thomasem has joined #craton | 17:59 | |
| jimbaker | antonym, so we have discussed bulk import - sort of the opposite of the ansible inventory endpoint | 18:06 |
| jimbaker | right now our assumption has been that the client probably is fine, with whatever corner cases removed. but if we find otherwise, we can definitely do a bulk endpoint | 18:07 |
| antonym | i guess there's a few ways, the initial load of the environment to populate the db, and then the ongoing passes to collect and update data i guess | 18:07 |
| jimbaker | antonym, so for multiple vars, do you mean for different resources at the same time? or for the same resource. (if for multiple, that would be the bulk above... which probably could be done in a reasonable fashion) | 18:08 |
| antonym | you probably have your openstack configs you want to track that configure the environment but also have a way to query information about the host itself, like bios revs, network configs, etc | 18:08 |
| antonym | so for instance i had a tool that worked with our galaxy that could grab all of the info of the server and in one call to galaxy update those attributes | 18:09 |
| jimbaker | antonym, it would be very straightforward to do. ideally it would not be ansible specific, but that massaging can be done in the tool calling the client | 18:09 |
| jimbaker | antonym, got it | 18:09 |
| antonym | i think i was just using the ansible uri method to push those values in | 18:10 |
| jimbaker | so let's say we had the following tool: it grabbed the various facts from one or more ansible files. it then produced a json that reversed the whole override stuff. then we feed that into a bulk endpoint | 18:11 |
| antonym | yeah, i think that would be useful for the configuration part | 18:11 |
| jimbaker | so the good thing would be, it wasn't dependent on ansible's rules | 18:11 |
| jimbaker | and could also work for importing in say puppet hiera files, etc | 18:12 |
| antonym | are openstack configuration variables essentially the same as server/container attributes? | 18:12 |
| antonym | or is the goal to keep those seperate | 18:12 |
| jimbaker | you mean for OSA? | 18:12 |
| antonym | just in general i guess... if i wanted to regeneate my configs from the stuff in inventory i probably wouldn't want the server attribute variables bundled in there | 18:13 |
| jimbaker | right now, we are assuming just a bag of attributes. but see this blueprint for possible implementation: https://blueprints.launchpad.net/craton/+spec/craton-namespaces | 18:13 |
| jimbaker | yeah, so i think the namespace stuff is exactly what we need here :) | 18:14 |
| antonym | yeah, kinda sounds like it | 18:14 |
| jimbaker | fwiw, i like the / because i don't think this is used in any key structure i'm aware of | 18:15 |
| jimbaker | so it will be easy to just do now as a convention, then start adding support | 18:15 |
| jimbaker | just revisited https://docs.puppet.com/hiera/3.2/configuring.html#example-config-file to jog my memory on hiera files | 18:20 |
| jimbaker | ansible restricts keys to being valid python identifiers from what i recall | 18:20 |
| jimbaker | yaml has no restriction other than being valid unicode, so that's effectively what our variables support for key/values now, http://yaml.org/spec/1.2/spec.html#id2764044 | 18:24 |
| jimbaker | antonym, anyway, i think it's pretty clear that we want namespace support to support your needs, plus others that come up. hopefully we don't have to spend much time on a separator character | 18:25 |
| jimbaker | i just don't want it to be backslash, like it is in php. that's just wrong | 18:25 |
| antonym | yeah, think we just want to be able to do a full collection of the hosts outside of the openstack configuration and store them so that they are easy to query | 18:27 |
| jimbaker | and that can be readily done with a namespace filter | 18:27 |
| antonym | so that we can build tools on top of it to drill down to things we're looking for | 18:27 |
| jimbaker | for bulk, maybe something simple like | 18:27 |
| *** jovon has joined #craton | 18:28 | |
| jimbaker | this payload [{resource_type: <type>, resource_id: <id>, [attribute: value]*, variables: <json>}, ...] | 18:29 |
| jimbaker | on the server side, this would build up the corresponding obj graph, which we would then serialize. usual concerns would presumably apply about maybe chunking into pieces for actual commits | 18:31 |
| antonym | yeah | 18:32 |
| jimbaker | the ansible data collection script would use the grouping structure to put in at the appropriate level. maybe it could infer some additional grouping? as far as the bulk endpoint is concerned, it doesn't matter | 18:33 |
| jimbaker | antonym, back to the original point. i think the idea is that keystone domain like concepts would let us combine multiple projects for a given customer | 18:35 |
| jimbaker | and that can be part of how the rbac role assignments work. the specific integration with keystone (if desired) would still have be worked out | 18:36 |
| jimbaker | as for the other part | 18:36 |
| jimbaker | host -> *container* | 18:36 |
| jimbaker | this is implemented, but not yet in the client/CLI | 18:36 |
| jimbaker | sulo will be working on this | 18:36 |
| jimbaker | so project effectively equals cloud from our perspective | 18:37 |
| antonym | so your project is essentially the cloud level with a tenant id then? | 18:37 |
| jimbaker | yeah | 18:37 |
| jimbaker | the assumption is that the project equals the level of isolation that we see in clouds | 18:37 |
| antonym | makes sense | 18:38 |
| jimbaker | so if there are project vars, or workflows that are "shared" across projects, they do have to be copied | 18:38 |
| jimbaker | but we will feel this is sort of why one isolates into a cloud to begin with | 18:38 |
| jimbaker | so yeah, sounds like we agree on this decision | 18:39 |
| antonym | good to know about the containers too | 18:39 |
| jimbaker | yeah, this is super important for us | 18:39 |
| jimbaker | i usually call this when talking about it the "device tree" | 18:40 |
| antonym | one more question i guess... i think i saw a blueprint about this too, but being able to query for servers with specific attributes... like ?datacenter=dfw&os=redhat&rack=d12.dfw is that still in the works? | 18:40 |
| jimbaker | so that works today at the REST level. WIP for the CLI | 18:41 |
| antonym | one thing i was using for discovery of the server was using lldp to pick up the switch name and port on the network and using that to determine the node i was looking for | 18:41 |
| jimbaker | the one thing it's broken on is that the var search does not support resolution | 18:42 |
| jimbaker | https://bugs.launchpad.net/craton/+bug/1661226 | 18:42 |
| openstack | Launchpad bug 1661226 in craton "Filter by variables lacks resolved variables" [Medium,Confirmed] | 18:42 |
| antonym | ok, i'll poke around at the rest level to see how that works | 18:42 |
| antonym | got a dev env set up so was going to start trying to load it with data to see how it works | 18:43 |
| jimbaker | antonym, i suggest you look at this https://review.openstack.org/#/c/427717/ | 18:44 |
| jimbaker | i should add this info to the bug that sulo posted in response to my review | 18:44 |
| jimbaker | :) | 18:44 |
| antonym | ah, cool | 18:45 |
| jimbaker | thomasem, you mentioned acceptance criteria earlier | 18:45 |
| jimbaker | the other thing i go for is reproducibility of bugs | 18:45 |
| jimbaker | so explicit code that i can use, always awesome | 18:45 |
| jimbaker | jovon, also highly handy for our docs | 18:45 |
| jimbaker | antonym, anyway, it can be a bit painful to figure out the exact REST incantation | 18:46 |
| jovon | +1 | 18:46 |
| jimbaker | we will hopefully get better in documenting this | 18:46 |
| jimbaker | antonym, in the meantime, i will add the discussion of a bulk endpoint as a feature request, and we will go from there | 18:47 |
| antonym | yeah, sounds good, just thinking doing one var per call might be a bit much for the amount of data we'd probably want to pull in | 18:48 |
| jimbaker | antonym, https://bugs.launchpad.net/craton/+bug/1661714 | 18:58 |
| openstack | Launchpad bug 1661714 in craton "Bulk endpoint for working with resources" [Undecided,New] | 18:58 |
| antonym | nice, thanks | 18:59 |
| jimbaker | np | 19:00 |
| *** VW has quit IRC | 19:42 | |
| thomasem | jimbaker: agreed. I will start adding that to my bug reports. Apologies. | 19:43 |
| thomasem | jimbaker: is there a particular one you're looking at that I could help by getting some reproducing code for? | 19:44 |
| cloudnull | hey all, look to see if craton can do something like so http://cdn.pasteraw.com/90abpeqkkw8sa0zxaa1vj3jm03ld5rl ? | 20:02 |
| cloudnull | 's/look/looking/g' | 20:04 |
| sulo | cloudnull: most of it yes, except there is no specific type for container, we just separate by "device_type" | 20:08 |
| sulo | but would like to know if thats something thats needed | 20:08 |
| sulo | i've had a few request on container type .. just not sure what properties we want to track | 20:08 |
| cloudnull | its a crufty drawing but mocks out some of the env types I've run up against. | 20:09 |
| cloudnull | esentially a single environment owner w/ many disconnected clouds under it | 20:10 |
| cloudnull | looking into the API is it possible for a host to exist in >1 cell/region ? | 20:10 |
| sulo | no | 20:10 |
| cloudnull | thinking of regions as different isles in the same DC | 20:10 |
| sulo | everythin is assumed to be under one region | 20:10 |
| cloudnull | with an interconnect | 20:10 |
| cloudnull | ok | 20:11 |
| sulo | is that a real use case though ? | 20:11 |
| cloudnull | cells? | 20:11 |
| cloudnull | we have that in the osic today w/ ironic in one region and vms in the other | 20:11 |
| cloudnull | both within the same dc | 20:11 |
| cloudnull | sharing parts of the control plane | 20:11 |
| sulo | thats really good to know .. all our assumptions so far has been customer(tenant) -> n x region -> each region -> n x cells and so on | 20:13 |
| cloudnull | which also covers networking gear | 20:13 |
| cloudnull | though I've not dug into that part of the craton scheme | 20:13 |
| cloudnull | ok | 20:13 |
| cloudnull | idk if tracking the containers specifically will be of benifit, i wrote it down because we have in OSA. we might be able to achieve the same thing by simply allowing unstructured and nested data to be added to a specific host. | 20:15 |
| cloudnull | though the containers are consumers of IP space so idk if craton wants to track that ? | 20:16 |
| sulo | yeah, right now, we just allow creating generic hosts with "device-type" field | 20:16 |
| sulo | so device type could be server or container | 20:16 |
| antonym | yeah, i was kinda on the fence with containers, but it might be nice to store all of that ip data... yes | 20:16 |
| sulo | assuming they have the same properties | 20:16 |
| sulo | but if we need differnt things then its fairly easy to add it | 20:16 |
| cloudnull | within osa the containers will assume the properties of the host and then allow specifics vars to be added to a given container as needed. | 20:17 |
| sulo | so that use case is covered as each device can have its own vars | 20:17 |
| cloudnull | so in the craton scheme it'd be similar to the profile of a host. however containers are considered ephemera | 20:17 |
| cloudnull | ok. | 20:18 |
| cloudnull | and a device can be nested under a host? | 20:18 |
| sulo | cloudnull: yes, parent -> child | 20:18 |
| cloudnull | ok | 20:18 |
| sulo | we are in the process of exposing the tree from the api .. but we can get th parent_id right anow and draw it out on client side if needed | 20:19 |
| cloudnull | and can a device exist in two regions ? or is that bound to the constraint mentioned before? | 20:19 |
| sulo | antonym: so did the current structure not work for you ? | 20:20 |
| cloudnull | IE a switch in two cells, regions ? | 20:20 |
| sulo | cloudnull: right now it cant, unless the same device is done twice | 20:20 |
| cloudnull | ok | 20:20 |
| sulo | cloudnull: we can work on this use case | 20:20 |
| cloudnull | ok | 20:20 |
| sulo | cloudnull: so you'd need both cells and devices to be in more than one region ? | 20:21 |
| sulo | i guess just devices | 20:21 |
| cloudnull | devices and hosts. | 20:22 |
| sulo | ok | 20:22 |
| sulo | antonym: if you'd need something specific on containers tracked that is not currently there do let know | 20:23 |
| sulo | toan has asked more than once that we support continers specifically | 20:23 |
| sulo | i dont have the exact req's though .. as to what to track vs whats available in hosts right now | 20:24 |
| antonym | i could see it'd be nice to have the container generated name and ips that were being used tracked in the db | 20:24 |
| antonym | mainly for querying which container is on what host if there was an issue from the logs | 20:24 |
| sulo | ah gotcha | 20:25 |
| sulo | so we can do that now in a way .. cratea host with device_type ="container" .. it can have ips etc .. then partent_id = the host where it resides | 20:25 |
| sulo | so when we draw out the tree .. we will see that host x has containers a b c etc | 20:26 |
| antonym | yeah, that seems like that would track it well | 20:26 |
| sulo | antonym: do you think we'd need a separate containers specific endpoint | 20:26 |
| sulo | just thinking if that makes things more easy to use | 20:27 |
| antonym | endpoint? | 20:28 |
| antonym | oh for querying? | 20:28 |
| sulo | i mean rather than doing host GET type=container .. just doing GET container | 20:28 |
| sulo | yeah for query | 20:28 |
| sulo | i guess it only makes sense if there were container specific things to track | 20:29 |
| sulo | that different from what we have in hosts | 20:29 |
| antonym | yeah, it might, i'm just wondering if there's any attributes more that we'd need | 20:29 |
| sulo | yeah same | 20:30 |
| antonym | wonder if we'd get to the point where we capture processes running in the container | 20:30 |
| antonym | or maybe define the roles of the container | 20:30 |
| *** VW has joined #craton | 20:41 | |
| Syed__ | sulo: uploaded the patch for project and user update, kindly look | 20:49 |
| *** toan has joined #craton | 21:04 | |
| *** valw has joined #craton | 21:05 | |
| *** valw has quit IRC | 21:09 | |
| *** VW has quit IRC | 21:32 | |
| *** VW has joined #craton | 21:32 | |
| jimbaker | thomasem, i was mentioning this with respect to https://bugs.launchpad.net/craton/+bug/1661226 - not specifically one of your bugs you filed recently | 21:35 |
| openstack | Launchpad bug 1661226 in craton "Filter by variables lacks resolved variables" [Medium,Confirmed] | 21:35 |
| thomasem | jimbaker: ohh gotcha, okay. Good to know! | 21:36 |
| jimbaker | but in general, if we have a bug that shows the failing REST API call, this is very good. so this would ideally be: 1) specific request; 2) response; 3) relevant traceback in the log file of the API serfver | 21:36 |
| thomasem | got https://review.openstack.org/#/c/428996 up and working now | 21:36 |
| jimbaker | similar specificity in bug reporting for say using the python client, CLI, etc | 21:37 |
| thomasem | Agreed. | 21:37 |
| thomasem | That review is for basic Project support in the CLI ^^ | 21:37 |
| jimbaker | thomasem, nice | 21:38 |
| thomasem | Hoping we can dry out a lot of that in the future. | 21:39 |
| thomasem | Since all of the *_shell.py have a lot of repeated stuff | 21:40 |
| thomasem | But, not a big deal... it's really not much code. | 21:40 |
| thomasem | But code that doesn't exist need not be debugged. | 21:40 |
| thomasem | Gonna test that patch against a master craton-api | 21:47 |
| thomasem | realized I was testing against my patch. Want to be sure it works that way, too. | 21:48 |
| thomasem | Yep, works. | 21:51 |
| jimbaker | so cloudnull, sulo - our assumption is that a project = cloud | 22:00 |
| jimbaker | a device can be in only one region, and optionally a cell. this is based on our understanding of standard DC layout | 22:01 |
| jimbaker | but a device can have any number of labels; which can overlap with other devices as desired. so n-to-m relationship between a device and a label | 22:02 |
| jimbaker | this allows for logical grouping | 22:02 |
| jimbaker | thomasem, lots of repeated code in the CLI | 22:03 |
| jimbaker | take a look at some stuff i did to address this in my WIP branch | 22:03 |
| jimbaker | https://review.openstack.org/#/c/427032/3/cratonclient/shell/v1/hosts_shell.py | 22:04 |
| jimbaker | can be further improved, and i'm sure i will when i get that fixed up | 22:04 |
| jimbaker | but just as a general implementation principle | 22:05 |
| jimbaker | when i see the same error handling code again and again - well, it's just a bit much for me | 22:05 |
| jimbaker | fortunately, decorators | 22:05 |
| jimbaker | :) | 22:05 |
| thomasem | Haha, agreed | 22:06 |
| thomasem | Thanks for sharing. | 22:06 |
| thomasem | So, in past projects I've been on there's been sort of a standard of trying to keep changes relevant to the referenced bug/task, where refactorings midway through can tend to derail or bloat code reviews a bit. In those projects we would set up a separate task to specifically attack refactorings separately. I'm assuming that's not a thing on this project? | 22:08 |
| thomasem | Ultimately I want to avoid derailing code reviews with unrelated changes, so want to know what's generally accepted behavior on that front. | 22:10 |
| thomasem | Anywho, I need to get running to prepare for tonight. Hope everyone has a lovely weekend! Thanks for being so welcoming and helping me get started, everyone. | 22:11 |
| cloudnull | jimbaker: how fesable would it be to get it so that a single project could have many clouds? | 22:17 |
| cloudnull | I updated my crufty drawing but this is more what my enviornments looks like http://cdn.pasteraw.com/mclm54g53jmi3k4w56ucgcplbocd2q3 | 22:17 |
| cloudnull | primary concerns for me would be a host in >1 cell/region and a "device" (network or otherwise) in >1 cell/regio n | 22:19 |
| cloudnull | when we say standard dc layout are we talking about rax public cloud? asking because standard dc layouts in ! rax public cloud would be flat and outside of openstack there's not concept of cells (maybe we mean cabinets?) | 22:22 |
| cloudnull | **there's no | 22:25 |
| *** VW_ has joined #craton | 22:35 | |
| *** VW_ has quit IRC | 22:35 | |
| *** VW has quit IRC | 22:38 | |
| jimbaker | thomasem, generally best to do refactorings separately | 23:00 |
| jimbaker | occasionally i will do what is going to be a refactoring in a bug fix, with the intent of doing it later more pervasively | 23:00 |
| jimbaker | cloudnull, it would require some work to had this additional layer. but again the whole intent in our design was that a project = a cloud | 23:00 |
| jimbaker | cloudnull, for cells: they are optional in our model | 23:01 |
| jimbaker | outside of openstack, one example that is reasonably close is an availability zone in AWS | 23:02 |
| jimbaker | as for cabinets, we capture this with the idea of a general device tree | 23:03 |
| jimbaker | one priority change we agreed on yesterday, based on toan's request: sulo is adding support for the device tree, which is generally a cabinet with everything in it, down to any containers | 23:04 |
| jimbaker | this is supported in the dbapi, but needs support pushed out to the client/CLI | 23:04 |
| jimbaker | the specific thing we agreed on is to make it to get all the info about a cabinet, without requiring additional navigation. mostly because this seems like such a common thing to do | 23:05 |
| jimbaker | hope this makes sense! | 23:05 |
| *** VW has joined #craton | 23:10 | |
| *** VW has quit IRC | 23:15 | |
| cloudnull | makes sense. if there's a meeting that I can attend and/or a spec that you think I should write to see about getting another layer in between there for a single project w/ many sub clouds I'd be happy to try and get that submitted. | 23:31 |
| cloudnull | most of my environments(projects) have several disconnected clouds. | 23:31 |
| cloudnull | and i'd love to see about trying to use this in a more meaningful way if at all possible | 23:32 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!