| *** VW has quit IRC | 01:41 | |
| *** VW has joined #craton | 01:42 | |
| *** VW_ has joined #craton | 02:18 | |
| *** VW has quit IRC | 02:21 | |
| anonymike | jimbaker: thanks for that feedback, exactly what I was looking for | 05:16 |
|---|---|---|
| *** tojuvone has quit IRC | 08:06 | |
| *** tojuvone has joined #craton | 08:18 | |
| sulo | o/ | 10:27 |
| thomasem | o/ | 10:46 |
| sulo | thomasem: woah you up really early | 11:58 |
| thomasem | Lol, yeah. I'm watching my brother's dog for the weekend, so two dogs in the house now. They thought it'd be a great idea to start whining at me to let them out of the room to play around the house. Well, now I can't fall back asleep, but I'm glad they could... jerks. | 12:01 |
| thomasem | So, figured I'd go put my mind to use. :P | 12:02 |
| thomasem | Then again, I'm usually awake by now, so it wasn't too bad. I usually wake up at 6:30 AM, so if I get woken up at, say, 5:30 AM, there's no point in going back to bed because that's not long enough for a full sleep cycle. I'll just feel worse if I try to. | 12:05 |
| sigmavirus | morning | 12:12 |
| sigmavirus | thomasem: I agree | 12:12 |
| sigmavirus | I'm often in the same situation | 12:12 |
| sigmavirus | thomasem: btw, you've been added to the necessary core-reviewer groups | 12:24 |
| sigmavirus | you can +2/+A anything at this point | 12:24 |
| thomasem | sigmavirus: Excellent. Thank you!! Does that include python-cratonclient? | 12:50 |
| sigmavirus | craton-core covers openstack/craton and openstack/python-cratonclient | 12:50 |
| sigmavirus | I updated the core team for craton-ui-core | 12:50 |
| thomasem | Awesome. Thanks a 'mil! | 12:52 |
| sigmavirus | That gives you and sulo and jim access to the UI thing that intel started | 12:52 |
| sigmavirus | I think I added harry to it too | 12:52 |
| sigmavirus | I'll nix my access to those groups today around 3pm | 12:52 |
| thomasem | Got a link to it? | 12:53 |
| sigmavirus | link to? | 12:53 |
| sigmavirus | https://github.com/openstack/craton-dashboard ? | 12:53 |
| sigmavirus | It's kind of dead at this point | 12:53 |
| thomasem | Ahhh, that one. | 12:53 |
| thomasem | I see | 12:53 |
| sigmavirus | It's meant to be a horizon plugin (and that's why craton/cratonclient support keystone authentication) | 12:53 |
| thomasem | Right, I remember discussing that | 12:54 |
| sigmavirus | yeah | 12:54 |
| sigmavirus | That said, craton will need a UI/dashboard but it shouldn't be built into horizon | 12:55 |
| sigmavirus | (in my humble opinion) | 12:55 |
| thomasem | Yeah, we have many better alternatives for this use-case. | 12:55 |
| sigmavirus | Someone could slapdash an angularjs app that would work well enough | 12:58 |
| thomasem | Yeppers | 13:20 |
| fsaad | morning all | 13:54 |
| fsaad | afternoon to those across the pond | 13:55 |
| *** VW_ has quit IRC | 13:57 | |
| sulo | hi fsaad | 14:14 |
| fsaad | hi sulo happy Friday | 14:14 |
| sulo | happy Friday indeed :) | 14:15 |
| sigmavirus | :D | 14:23 |
| *** VW has joined #craton | 14:25 | |
| openstackgerrit | Merged openstack/python-cratonclient master: Add user documentation for the Python API https://review.openstack.org/447084 | 14:43 |
| openstackgerrit | Merged openstack/python-cratonclient master: Add basic shell documentation for cratonclient https://review.openstack.org/447103 | 14:43 |
| openstackgerrit | Merged openstack/python-cratonclient master: Add Python API Reference documentation https://review.openstack.org/447110 | 14:43 |
| thomasem | Yay! | 14:45 |
| sigmavirus | woah | 14:46 |
| anonymike | woo those docs will certainly come in handy | 14:59 |
| jimbaker | thomasem, can you go back through your +1 reviews (namely on betamax work) and rescore as +2 ? | 15:02 |
| thomasem | jimbaker: I tried and it seems I can't? Looks like a bug. | 15:02 |
| jimbaker | thomasem, ack. ok, we can assume you did a +2... | 15:03 |
| thomasem | jimbaker: got it, had to zero out first... or at least comment again, then I could. | 15:03 |
| jimbaker | even better | 15:03 |
| thomasem | jimbaker: done! | 15:04 |
| jimbaker | thomasem, ok, workflowed in the betamax stuff | 15:05 |
| thomasem | jimbaker: excellent! | 15:06 |
| jimbaker | working great, so time to get in. we can figure out my osx issues in the future, but i'm satisfied with ubuntu | 15:06 |
| * sigmavirus is very confused by your osx issues =( | 15:06 | |
| jimbaker | sigmavirus, yeah. i'm sure it is a setup issue. so i don't see a reason why to delay here | 15:07 |
| openstackgerrit | Merged openstack/python-cratonclient master: Add Betamax for testing https://review.openstack.org/442165 | 15:10 |
| jimbaker | fwiw, we seem to be running into similar issues as https://bugs.launchpad.net/testrepository/+bug/1229445 on client side - i would like to run these envs separately, in any order - but a clean env does the job | 15:10 |
| openstack | Launchpad bug 1229445 in Testrepository "db type could not be determined" [High,Triaged] | 15:10 |
| openstackgerrit | Merged openstack/python-cratonclient master: Add tests for our cells integration https://review.openstack.org/445515 | 15:10 |
| openstackgerrit | Merged openstack/python-cratonclient master: Add integration tests for clouds client https://review.openstack.org/445909 | 15:10 |
| jimbaker | a clean checkout perhaps more precisely | 15:10 |
| openstackgerrit | Merged openstack/python-cratonclient master: Add integration tests for regions https://review.openstack.org/446134 | 15:10 |
| openstackgerrit | Merged openstack/python-cratonclient master: Add convenience environment to re-record tests https://review.openstack.org/448646 | 15:10 |
| jimbaker | nits | 15:11 |
| openstackgerrit | Thomas Maddox proposed openstack/craton master: JSON Path-like querying for variables https://review.openstack.org/443941 | 15:12 |
| jimbaker | sigmavirus, thanks for all that good hard work. everything is now in! | 15:17 |
| thomasem | Alright, I'm at a good break point and want to step away for JSON path for a bit here. Which tests weren't working on OS X? | 15:17 |
| thomasem | +1 to that | 15:17 |
| jimbaker | thomasem, for me - i cannot run the betamax stuff for some run on osx | 15:17 |
| jimbaker | some *reason* | 15:18 |
| thomasem | Gotcha, lemme try. | 15:18 |
| thomasem | Lol | 15:18 |
| jimbaker | now we only CI against ubuntu anyway. and we don't even support tox -e functional on osx | 15:18 |
| jimbaker | for craton api | 15:19 |
| thomasem | Yeah, and we don't intend to support it because we have no gate for it. | 15:19 |
| sigmavirus | jimbaker: it's been a pleasure to work with y'all | 15:19 |
| thomasem | sigmavirus: always feel free to drop by and poke fun. :P | 15:20 |
| jimbaker | sigmavirus, very much so here as well. and i'm sure we will continue to work together on stuff that intersects at the jython level, especially pypi ecosystem | 15:20 |
| thomasem | jimbaker: how're you invoking? | 15:20 |
| thomasem | Mine just passed fine. | 15:20 |
| jimbaker | (as i have time) | 15:20 |
| jimbaker | thomasem, yeah, that's why i'm not terribly worried | 15:20 |
| jimbaker | it's just me | 15:21 |
| * thomasem snickers | 15:21 | |
| jimbaker | sigmavirus mentioned it worked for him | 15:21 |
| thomasem | Gotcha | 15:21 |
| jimbaker | and i certainly don't have a "clean" setup for my python setup at this point | 15:21 |
| jimbaker | on osx | 15:21 |
| jimbaker | just the usual mishmash of dev stuff | 15:22 |
| thomasem | pyenv is your friend | 15:22 |
| jimbaker | so probably some random conflict. likely i can confine to a virtualenv, from a fresh python install | 15:22 |
| jimbaker | indeed, that's how it will be solved | 15:23 |
| thomasem | I don't ever use system python anymore. | 15:23 |
| jimbaker | so i suspect anaconda python... | 15:23 |
| jimbaker | as i said, mishmash | 15:23 |
| thomasem | pyenv + pyenv-virtualenv keep everything neatly separated. | 15:24 |
| thomasem | Haha, gotcha | 15:24 |
| jimbaker | and a good python base... | 15:24 |
| jimbaker | anyway, it's all my problem. so we are good | 15:25 |
| jimbaker | in other news, OPNFV deadline was pushed back two weeks | 15:25 |
| * anonymike looks at pyenv | 15:25 | |
| thomasem | anonymike: https://github.com/pyenv/pyenv-installer | 15:25 |
| jimbaker | so tojuvone and i have a bit more time to put together a proposal | 15:25 |
| thomasem | Oh that's really good | 15:25 |
| jimbaker | yeah, i really wanted to think through the ideas we have had around maintenance, and its integration with craton; and how it integrates with other tooling | 15:26 |
| anonymike | I had a real hard time getting the python craton client working last night | 15:26 |
| anonymike | I think it was due to messy envs | 15:26 |
| jimbaker | too much juggling on my part recently to do this right | 15:26 |
| anonymike | i eventually got it, and sent a few things to elastic search | 15:27 |
| jimbaker | anonymike, yeah, that makes sense. you really want to do a virtualenv | 15:27 |
| thomasem | anonymike: Abandon your system python... come to pyenv... | 15:27 |
| anonymike | gonna pick that up again after some coffee | 15:27 |
| jimbaker | start with something clean | 15:27 |
| thomasem | I also use it for my bash prompt: | 15:27 |
| jimbaker | nice | 15:27 |
| thomasem | (py:3.5.0 | venv:default-3.5.0 | docker:1.13.0) | 15:27 |
| thomasem | 15:12:45(+0000) thomasem@chickenwegs ~/workspace/craton ((3f09846...)) $ | 15:27 |
| jimbaker | i believe tim was running into a similar problem | 15:27 |
| jimbaker | thomasem, but also why we need to cut a client package soon | 15:28 |
| jimbaker | on pypi | 15:28 |
| anonymike | +1 | 15:28 |
| thomasem | Oh yeah | 15:28 |
| thomasem | Also need to regenerate the docs, if that job didn't already do it. | 15:28 |
| jimbaker | i believe the docs got re-generated | 15:29 |
| jimbaker | for client | 15:29 |
| jimbaker | but should doublecheck | 15:29 |
| thomasem | Said 2 days | 15:29 |
| thomasem | I just hit Build | 15:29 |
| jimbaker | ok | 15:30 |
| jimbaker | the other thing - we need to get these patches updated | 15:30 |
| jimbaker | https://review.openstack.org/#/c/427249/ | 15:30 |
| jimbaker | https://review.openstack.org/#/c/427245/ | 15:31 |
| jimbaker | https://review.openstack.org/#/c/427237/ | 15:31 |
| jimbaker | sulo, ^^^ | 15:31 |
| jimbaker | they are all pretty minor changes; i suspect we can do a better job of parameterizing so there's less actual code to write | 15:33 |
| jimbaker | i guess if we add 'user' to the mix, we are done with everything being exposed to the client | 15:35 |
| sigmavirus | hm, so the infra stuff that merged the other day should be triggering docs jobs for craton & cratonclient | 15:35 |
| sigmavirus | I wonder if there's something we need to do | 15:35 |
| thomasem | zz_pwnall138: antonym: My latest patch changes all vars queries to require valid JSON in the value, as well. So, where you previously did foo:bar, you'd need to do foo:"bar", but you can also specify booleans, ints, floats, and null like foo:true, foo:1, foo:3.14, foo:null. | 15:54 |
| thomasem | It's not merged yet, but this is a good opportunity to discuss the implications for UX there. | 15:54 |
| thomasem | So, for a typical nested search for a string it'd be key1.key2:"string" | 15:55 |
| thomasem | or digging through arrays | 15:55 |
| thomasem | key1[*]:"string" | 15:55 |
| thomasem | key1.key2[*]:"string" | 15:55 |
| thomasem | key1."hyphenated-key":"string" | 15:55 |
| thomasem | This all needs some accompanying documentation. | 15:56 |
| thomasem | Naturally. | 15:56 |
| jimbaker | thomasem, i think this makes a lot of sense | 15:56 |
| jimbaker | attempting to do magic quoting is just problematic | 15:56 |
| thomasem | Yeah, git-harry had some beef with it, too, and I have to agree that it can get confusing if you're not careful. | 15:57 |
| antonym | yeah, that'll lead to some fun quoting exercises heh | 15:57 |
| thomasem | foo:"true" meant something different from foo:true | 15:57 |
| thomasem | It's the reliable way... since things like '-' are special characters in JSON, but totally valid in JSON strings. | 15:58 |
| jimbaker | the only option is to have a special form, similar to httpie, that just knows about strings | 15:58 |
| jimbaker | but maybe we don't worry about that option unless we get user feedback | 15:58 |
| jimbaker | meeting... | 15:59 |
| jimbaker | (for me) | 15:59 |
| thomasem | What I've done here is said: If the path works in MySQL, it'll work here. All of these things get errors in the DB unless you do magic. | 15:59 |
| thomasem | So, according to this: https://dev.mysql.com/doc/refman/5.7/en/json-path-syntax.html | 16:00 |
| thomasem | Anything outside of that is supposed to give you a 400 with a message about either bad path or bad value. | 16:00 |
| jimbaker | +1 | 16:06 |
| *** Syed__ has joined #craton | 16:07 | |
| sigmavirus | heh | 16:33 |
| sigmavirus | so | 16:33 |
| sigmavirus | https://python-cratonclient.readthedocs.io/en/latest/ | 16:33 |
| sigmavirus | that is being updated by the infra docs job | 16:33 |
| sigmavirus | Syed__: can you get chrisspencer to transfer that project to jimbaker ? | 16:34 |
| sigmavirus | or to thomasem? | 16:34 |
| sigmavirus | Also anonymike you were asking about where to document the shell tooling, I'd put it in https://craton.readthedocs.io/en/latest/#developer-guide | 16:35 |
| anonymike | has that always been up? | 16:35 |
| anonymike | oh woops I was looking at the link above lol | 16:36 |
| anonymike | thanks sigmavirus | 16:36 |
| openstackgerrit | Ian Cordasco proposed openstack/python-cratonclient master: Update link to documentation and bug tracker https://review.openstack.org/449725 | 16:44 |
| sigmavirus | happy to help anonymike | 16:44 |
| * sigmavirus performs last bit of tidying | 16:44 | |
| anonymike | :( | 16:44 |
| openstackgerrit | Merged openstack/python-cratonclient master: Updated from global requirements https://review.openstack.org/449717 | 17:07 |
| thomasem | Llllllunch. | 17:15 |
| openstackgerrit | Merged openstack/craton master: Update the link to Craton's documentation https://review.openstack.org/449718 | 17:26 |
| jimbaker | thomasem, i notice the sqlite stuff does not play nicely with tox -e cover | 18:43 |
| jimbaker | just more reason to forklift | 18:44 |
| jimbaker | anonymike, all set with using python client for craton? | 18:47 |
| jimbaker | (just want to make sure you are unblocked) | 18:47 |
| anonymike | I am :) | 18:47 |
| jimbaker | awesome | 18:47 |
| anonymike | gonna circle back and update the wrapper function stuff after our meeting | 18:47 |
| jimbaker | anonymike, re https://review.openstack.org/#/c/449230/ - just wanted consistency in the naming | 18:48 |
| anonymike | and then populate elastic for the rest of the day | 18:48 |
| anonymike | completely understand | 18:48 |
| jimbaker | so we have been doing stuff like craton-<noun>-op | 18:48 |
| jimbaker | in the craton CLI | 18:48 |
| jimbaker | hence mu suggestions there on that review | 18:48 |
| jimbaker | my | 18:48 |
| anonymike | are people notified of changes? is there anyway I can ping sulo on that review or should I ping him on IRC | 18:49 |
| jimbaker | anonymike, it gets buries | 18:49 |
| anonymike | people who have commented* | 18:49 |
| jimbaker | buried | 18:49 |
| jimbaker | irc is best if you want to get attention i think | 18:49 |
| jimbaker | certainly for me! | 18:49 |
| jimbaker | as i like to say: i'm a very bad implementation of a select loop | 18:49 |
| anonymike | cool. I'll continue to leave comments on the review and bring em into IRC | 18:50 |
| anonymike | lol | 18:50 |
| jimbaker | yep, that's the best way | 18:50 |
| jimbaker | we capture the comments in the right place - although good to get realtime when possible | 18:50 |
| jimbaker | good here | 18:51 |
| jimbaker | but ping on irc | 18:51 |
| jimbaker | and again - no expectation that people are always on irc | 18:51 |
| anonymike | right | 18:51 |
| jimbaker | because work, lunch, sleep, life | 18:51 |
| jimbaker | we are on different time zone | 18:51 |
| jimbaker | and even i'm working, if i'm in flow - i ignore irc. very simple | 18:52 |
| jimbaker | so just setting common expectations for the team - i expect everyone to do what works for them | 18:52 |
| jimbaker | so far, this seems to be a good working arrangement! | 18:53 |
| anonymike | I agree | 18:54 |
| thomasem | Looking at Bjoern's request here: https://bugs.launchpad.net/python-cratonclient/+bug/1675410, thinking about how we can improve the UX around relating hosts to their network interfaces' information via the client... | 19:03 |
| openstack | Launchpad bug 1675410 in Craton's Python Client "Add fields selector to <resource>-show commands" [Undecided,New] | 19:03 |
| thomasem | A lot of that stuff we can get from variables, but to get network interfaces on the host and display the assigned IP, netmask, etc... | 19:04 |
| jimbaker | thomasem, yeah, so this gets into better links i believe | 19:08 |
| jimbaker | you want to search + navigate | 19:09 |
| jimbaker | so we currently have search for parent | 19:09 |
| jimbaker | and we can follow the up links | 19:09 |
| jimbaker | similar considerations for how networking should be done | 19:09 |
| jimbaker | or how to work with such networking info | 19:09 |
| jimbaker | thomasem, getting back to the specific point here | 19:10 |
| jimbaker | i see this as - what do we mean by details=all | 19:10 |
| jimbaker | and what subset of info to show | 19:11 |
| sigmavirus | so here's a question I have, now that I'm no longer a craton core and my time left here is very little, is there any sense in requiring a network device to exist prior to creating a host? | 19:11 |
| sigmavirus | we could allow hosts to be created with an ip address that then maps to a net device that has the same ip in the same project | 19:11 |
| jimbaker | sigmavirus, yeah, that makes sense to me. basically what do we to support linkage | 19:12 |
| sigmavirus | Because then we can store the linkage in the database | 19:12 |
| sigmavirus | And return more info about it if we want to join the tables for details=all | 19:13 |
| jimbaker | in other conversations, people want to be able to store incomplete inventory data | 19:13 |
| sigmavirus | jimbaker: including not knowing/having a network device? | 19:13 |
| jimbaker | and then as they have more info, be able to fill it in | 19:13 |
| sigmavirus | Currently we require an ip-address, don't we? | 19:13 |
| jimbaker | sigmavirus, yeah, i believe this is the case | 19:13 |
| jimbaker | it makes sense from where we started | 19:13 |
| jimbaker | but it seems best to relax | 19:13 |
| * sigmavirus nods | 19:14 | |
| jimbaker | no specific technical reason we need | 19:14 |
| sigmavirus | I wonder if craton might want to support command linking in the shell in a similar notion to how one creates an instance in nova and then attaches the FIP/neutron network to it | 19:14 |
| jimbaker | sigmavirus, +1 | 19:15 |
| thomasem | sigmavirus: how does that look? | 19:15 |
| sigmavirus | nova boot ... ; neturon floating-ip-create ... ; blah attach instanceid fipid | 19:15 |
| sigmavirus | it's not convenient | 19:15 |
| sigmavirus | but you could have a short cut like | 19:15 |
| sigmavirus | craton network-device-create ... --attach-to host-id | 19:15 |
| sigmavirus | really I think craton should feel free to do the convenient things for antonym et. all | 19:16 |
| thomasem | Hmmmm | 19:17 |
| jimbaker | sigmavirus, almost like git checkout -b ... | 19:17 |
| jimbaker | so the key thing is, antonym just needs to give us what he wants here, and we can make it so | 19:18 |
| jimbaker | but definitely NOT fixed in stone | 19:18 |
| * sigmavirus nods | 19:18 | |
| thomasem | Yeah... I don't get why ip_address is a field on Device, really. It makes more sense to derive that from NetworkInterface, no? | 19:19 |
| * sigmavirus shrugs | 19:19 | |
| jimbaker | thomasem, so the thought here is that this is the management ip address | 19:20 |
| thomasem | Maybe "primary_ip_address", if that's what it's going for, but otherwise... yeah. | 19:20 |
| thomasem | Right, s/primary/management/ | 19:20 |
| jimbaker | in many cases, it might have multiple ip addresses, which is the idea being captured by network interfaces | 19:20 |
| thomasem | But, that could also be data on the NetworkInterface model | 19:21 |
| thomasem | Or a separate relationship mapping each host to its management interface if available. | 19:21 |
| jimbaker | so i hope that's what the NetworkInterface model is doing for us | 19:21 |
| jimbaker | also the other implicit assumption here is that in a cab setting, it might suffice to just have this done at the top-of-rack switch level | 19:22 |
| thomasem | Yeah, I think it'd be a rare case that it only has one IP. | 19:22 |
| * sigmavirus nods | 19:22 | |
| thomasem | Have what done at the TOR level? | 19:22 |
| antonym | i'd kinda like to set some cidr ranges on the cell and then let it increment the next available ip from the pool so that i can autopopulate the database if i'm starting from scratch | 19:22 |
| jimbaker | thomasem, in terms of looking at multiple network connectivity | 19:22 |
| sigmavirus | antonym: yeah that sounds like what OSA does with container IPs too | 19:23 |
| antonym | so if i started with nothing in a cell, and then booted up everything, the servers themselves would create records and get a new static ip automatically | 19:23 |
| jimbaker | antonym, yep, we are going to provide that for you | 19:23 |
| sigmavirus | so that would be usable in many cases | 19:23 |
| jimbaker | we can robustly do interesting counters. thanks to strong consistency | 19:23 |
| jimbaker | thomasem, ^^^ | 19:24 |
| thomasem | Shots fired. | 19:24 |
| antonym | i got provisioning working btw with craton as the backend, i can control the server booting into a discovery image, running a discover playbook into craton, reboot into the operating system install, and then flip the status to localboot for the server to come up after the install | 19:24 |
| thomasem | Oh very nice! | 19:24 |
| antonym | still have some work to do in the discovery part to get the data i need though | 19:24 |
| antonym | but if i register the values i want, the install_os and everything else seems to work well | 19:25 |
| jimbaker | antonym, and hopefully using scoped variables to control anything in that server (namely containers)? | 19:25 |
| thomasem | Well, that's worthy of at least one scotch this evening, so. | 19:26 |
| sigmavirus | lol | 19:26 |
| thomasem | Now how many spawn from the first, I can't speak to. | 19:26 |
| antonym | yeah, those will be the next steps... i have a usb key that'll kick off the install of the provisioning server and set that up, so then if craton is populated, you should be able to kick off the next step of booting the servers to register and install | 19:27 |
| jimbaker | thomasem, http://www.spirithounds.com/the-spirits/ - near my house | 19:27 |
| antonym | after that, we should be able to automate the osa install | 19:27 |
| jimbaker | great whiskeys | 19:27 |
| thomasem | Oh man... I'm thirsty now. | 19:27 |
| antonym | whiskey sounds good | 19:27 |
| antonym | think it would be useful to have templates that are generated maybe off the cell configuration, defaults that each host would get assigned when created | 19:28 |
| antonym | so say i want all servers in that cell to get ubuntu installs and start at the firmware provisioning stage, when the records created, they'd have those variables by default | 19:28 |
| antonym | anyways, just friday rambling lol | 19:29 |
| thomasem | It's useful. | 19:29 |
| jimbaker | antonym, yeah, let me think about what that means in terms of implementation. but in general, my thinking is that we can put these sorts of semantics in a namespace | 19:29 |
| jimbaker | so a single ip address counter, or multiple variables, it doesn't really matter | 19:30 |
| antonym | yeah, then you just set up the cell and boot things up into it and the cell variables just waterfall down | 19:30 |
| jimbaker | yep | 19:31 |
| antonym | i'll have to see if i can put together some sort of demo webcast or something | 19:31 |
| jimbaker | the good thing, nothing else in craton would change | 19:31 |
| jimbaker | which is part of the design goals here :) | 19:31 |
| thomasem | We need a spec for these changes... With these more nuanced use-cases, we're going to want to revise our data model / API a bit here. | 19:32 |
| thomasem | or specs | 19:32 |
| jimbaker | thomasem, sure. but it will just be in variables. the use of variables would not change, nor notification, blame, overrides | 19:33 |
| antonym | yeah, i probably still need to think through this too, i've been getting more ideas as i plow through this | 19:33 |
| jimbaker | sounds good | 19:33 |
| jimbaker | thomasem, so really the way i think about it is like fuse filesystems on linux | 19:34 |
| antonym | the json searching will help quite a bit, i'm injecting the first mac for now, but it'd be useful to have them all | 19:34 |
| antonym | looking forward to that | 19:34 |
| jimbaker | there's some extra logic that's pluggable, but everything else remains the same | 19:34 |
| jimbaker | this spec then is the namespace spec :) | 19:35 |
| thomasem | What is the use of Network then? | 19:35 |
| jimbaker | thomasem, networks represent a general nondirected topology for craton | 19:36 |
| jimbaker | nondirected graph | 19:36 |
| jimbaker | so we have very much a *typed* approach to our modeling | 19:37 |
| thomasem | Well, you can relate a network to a Cell, so why not use that for the CIDRs we're allocating from? | 19:37 |
| jimbaker | rather than a general, one size fits all model, where any component can be in an arbitrary relationship with any other component | 19:37 |
| thomasem | Lol, but all of these can be in any arbitrary relationship with any other component... | 19:38 |
| thomasem | It's denormalized. :P | 19:38 |
| jimbaker | well, not quite | 19:38 |
| jimbaker | but we do need to a better job on the denormalization, and avoid exposing to the client, yes | 19:38 |
| jimbaker | that is a *mistake* | 19:38 |
| thomasem | I was kidding around | 19:39 |
| thomasem | btw | 19:39 |
| thomasem | being pedantic | 19:39 |
| thomasem | But, still... why not use Network for the network information for a cell? | 19:39 |
| thomasem | rather than variables + namespaces? | 19:39 |
| jimbaker | thomasem, it might be the place to store it | 19:39 |
| jimbaker | but it would be a variable on the network - or a group of variables (call it generally a "state") | 19:40 |
| thomasem | I mean, it's there already and represents the data about a network, such as CIDR. Seems like exactly what we're wanting to use for allocating things. | 19:40 |
| thomasem | What would be a variable on the network? | 19:40 |
| jimbaker | the specific next allocation | 19:40 |
| thomasem | Ah | 19:41 |
| jimbaker | this is what i mean by a "smart counter" | 19:41 |
| thomasem | I see what you're getting at now. | 19:41 |
| jimbaker | https://docs.python.org/3.5/library/ipaddress.html#arithmetic-operators | 19:41 |
| thomasem | But, if that's going to be a guaranteed thing on Network, why not make that an attribute on the Network model? Network.next_allocatable_ip | 19:41 |
| jimbaker | because we can never figure out everything someone might do | 19:42 |
| jimbaker | but we can build a plugin | 19:42 |
| jimbaker | system | 19:42 |
| thomasem | So, this would be highly specific to how the client is using Craton, not something we expect in Craton. | 19:42 |
| jimbaker | namespaces are plugins that introduce additional semantics onto variables. that's the idea i'm going after, at least | 19:42 |
| jimbaker | it would be baked into the craton api service, by loading in the plugin | 19:43 |
| thomasem | Like the client would set the next allocatable on the Network | 19:43 |
| jimbaker | and since it's at the service level, it gets strong consistency | 19:43 |
| thomasem | ? | 19:43 |
| jimbaker | so when you say ip + 1 | 19:43 |
| jimbaker | you get the next ip :) | 19:43 |
| thomasem | Right... is this all captured on the BP? (looking) | 19:43 |
| jimbaker | really? you expect that in a conversation is being recorded into the BP as we speak? | 19:44 |
| jimbaker | ;) | 19:44 |
| jimbaker | there's some of that there | 19:44 |
| jimbaker | but we get to figure out what a namespace is supposed to mean. right here, right now, with a real customer :) | 19:44 |
| thomasem | Oh, no, just you said that was your idea for namespaces, so i wanted to be sure we're getting the things in your head down on paper. | 19:44 |
| jimbaker | in the log at least... | 19:45 |
| thomasem | or in the BP, as the case may be. | 19:45 |
| jimbaker | and will be transcribed over time as we work it out | 19:45 |
| jimbaker | so the relevant BP is this one: https://blueprints.launchpad.net/craton/+spec/craton-namespaces | 19:46 |
| jimbaker | my thought here is to give some of the same versatility as in a python package - including renaming | 19:46 |
| jimbaker | and reuse | 19:46 |
| jimbaker | what it looks like - still figuring it out :) | 19:47 |
| thomasem | Right | 19:47 |
| jimbaker | but here are the main use cases | 19:47 |
| jimbaker | so far. 1) tojuvone needs some sort of maintenance support. we could just use convention, and use strings, and that's fine for a prototype, but what if we could restrict state transitions; possibly even add some additional support such as notifications on such transitions? i'm just asking questions, i do not know answers | 19:48 |
| jimbaker | 2) antonym needs a flexible scheme for ip address allocations. by locating in the database, we can ensure that we allocate every ip address in a block, without conflicts | 19:49 |
| jimbaker | 3) secret storage | 19:49 |
| thomasem | And all of these would necessitate reserved <namespace>/ convention in the key name? | 19:49 |
| jimbaker | well, it would certainly be a nice place to do it | 19:50 |
| jimbaker | hence the fuse filesystem metaphor | 19:50 |
| jimbaker | you mount a filesystem, it gets all sorts of cool properties | 19:50 |
| jimbaker | into the filesystem namespace | 19:50 |
| jimbaker | now if i were being pedantic about this, the mount point can occur in any directory | 19:51 |
| jimbaker | there's no Z: drive here :) | 19:51 |
| jimbaker | in linux | 19:51 |
| jimbaker | or unix more generally | 19:51 |
| thomasem | Sure | 19:51 |
| jimbaker | so we could say - mount this for any key, however it's laid out | 19:51 |
| jimbaker | i think the approach i'm suggesting here is closer to how it's done in python | 19:52 |
| jimbaker | but same degree of versatility | 19:53 |
| jimbaker | https://docs.python.org/3/library/importlib.html#module-importlib | 19:54 |
| jimbaker | and specifically the plugin functionality provided by pep 302 | 19:55 |
| jimbaker | anyway... good stuff. we will figure it out. after hashing it through some more! | 19:55 |
| thomasem | Yeah, I'll want to think a bit about this. It's described in pretty abstract terms right now, it feels like. I want to go through a real scenario that grounds the idea a bit. | 19:56 |
| jimbaker | exactly | 19:57 |
| jimbaker | right now it's malleable mindstuff | 19:57 |
| jimbaker | it can do everyhting | 19:57 |
| jimbaker | :) | 19:57 |
| thomasem | Yea, and 3pm on a Friday and I've been up since 5. | 19:57 |
| thomasem | :P | 19:57 |
| thomasem | Meaning I'm fading fast at this point. | 19:58 |
| jimbaker | the important point is, we want to implement something like this | 19:58 |
| jimbaker | the need is there | 19:58 |
| thomasem | Yeah | 19:58 |
| jimbaker | and the variables model allows us to do this without inventing new things | 19:58 |
| thomasem | Maybe we'll Vidyo about it and hash out a concrete "how this might look" thing next week. | 19:58 |
| thomasem | Assuming we don't get bogged down with our priorities. | 19:58 |
| thomasem | s/our/other/ | 19:58 |
| jimbaker | well it's a perfect topic for our meeting | 19:59 |
| jimbaker | but i don't think it's a priority item for next wek | 19:59 |
| jimbaker | week | 19:59 |
| jimbaker | first, rbac... etc | 19:59 |
| jimbaker | so a future meeting | 19:59 |
| thomasem | Sounds good to me. | 20:00 |
| jimbaker | in the meantime: tojuvone and i work through the maintenance use case | 20:00 |
| jimbaker | antonym will give us more concrete feedback | 20:00 |
| jimbaker | we will figure out secrets and its needs | 20:00 |
| thomasem | And we'll figure out how to make the client do the things Bjoern wants. :P | 20:00 |
| jimbaker | and from that we will derive the concrete namespace functionality we will need | 20:00 |
| thomasem | Which might necessitate some API changes. | 20:01 |
| tojuvone | jimbaker, roger. Went quite a rollacoaster with nova upon the topic today, but have to look better on monday | 20:01 |
| jimbaker | clearly that one first | 20:01 |
| jimbaker | :) | 20:01 |
| jimbaker | brb, meeting | 20:01 |
| thomasem | Wells, I've been on since ~5:30, so it's time for me to hit the road for the week. Have a lovely weekend, everyone! | 20:01 |
| tojuvone | thomasem, have a nice weekend. Also time for bed over here | 20:02 |
| tojuvone | started ~5am | 20:02 |
| thomasem | Have a good night, then! | 20:02 |
| thomasem | lol | 20:02 |
| tojuvone | indeed | 20:02 |
| anonymike | have a good weekend! | 20:03 |
| sigmavirus | Have a good one everyone. I'm out =) | 20:08 |
| sigmavirus | It's been great working with y'all | 20:08 |
| anonymike | Later sigmavirus. Good Luck | 20:09 |
| antonym | sigmavirus: o/ good luck! | 20:12 |
| jimbaker | sigmavirus, thanks so much, and good luck in your new endeavors! | 20:59 |
| fsaad | sigmavirus: good luck , hasta luego! | 21:07 |
| *** VW_ has joined #craton | 23:11 | |
| *** VW has quit IRC | 23:14 | |
| *** VW_ has quit IRC | 23:15 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!