*** VW has joined #craton | 01:51 | |
*** VW has quit IRC | 01:59 | |
*** VW has joined #craton | 02:10 | |
*** VW has quit IRC | 02:19 | |
*** VW has joined #craton | 02:30 | |
*** VW has quit IRC | 02:33 | |
*** VW has joined #craton | 02:45 | |
*** VW_ has joined #craton | 02:47 | |
*** VW has quit IRC | 02:47 | |
*** VW_ has quit IRC | 03:06 | |
*** VW has joined #craton | 03:06 | |
*** VW has quit IRC | 03:10 | |
openstackgerrit | Jim Baker proposed openstack/craton master: Updates Alembic migration to better match SQLAlchemy models https://review.openstack.org/441644 | 03:33 |
---|---|---|
*** tojuvone has quit IRC | 05:26 | |
*** tojuvone has joined #craton | 05:27 | |
*** klindgren_ has joined #craton | 09:32 | |
*** klindgren has quit IRC | 09:35 | |
*** klindgren__ has joined #craton | 10:43 | |
*** klindgren_ has quit IRC | 10:45 | |
thomasem | o/ | 13:10 |
thomasem | Wow.. Gerrit's sluggish again. | 13:27 |
thomasem | It's like molasses. | 13:27 |
tojuvone | You write code too fast, cannot keep up | 13:34 |
-openstackstatus- NOTICE: Gerrit is going to be restarted due to performance problems | 13:36 | |
*** ChanServ changes topic to "Gerrit is going to be restarted due to performance problems" | 13:36 | |
thomasem | Lol! | 13:37 |
thomasem | If only | 13:37 |
-openstackstatus- NOTICE: Gerrit has been successfully restarted | 13:43 | |
*** ChanServ changes topic to "Gerrit has been successfully restarted" | 13:43 | |
*** ChanServ changes topic to "Summit talk: https://www.youtube.com/watch?v=Q-sf12SDR3M || Logs: http://eavesdrop.openstack.org/irclogs/%23craton/latest.log.html || Mon 1500 UTC in #openstack-meeting-4 || Client/ecosystem Tues 1700 UTC || Core Thur 1700 UTC || Resources: https://etherpad.openstack.org/p/Fleet_Management" | 13:49 | |
-openstackstatus- NOTICE: Gerrit has been successfully restarted | 13:49 | |
*** IRCFrEAK has joined #craton | 13:53 | |
*** IRCFrEAK has quit IRC | 13:55 | |
*** lamer14894991848 has joined #craton | 13:56 | |
sigmavirus | thomasem: what do you want from a giant java application written by google | 13:57 |
*** lamer14894991848 has quit IRC | 13:57 | |
*** IRCFrEAK has joined #craton | 13:58 | |
*** IRCFrEAK has quit IRC | 13:59 | |
thomasem | sigmavirus: Lol, too much, I guess? | 14:01 |
sigmavirus | ¯\_(ツ)_/¯ | 14:02 |
thomasem | I'd really like to know "why" more than anything. | 14:02 |
thomasem | But, I also don't know what all goes on infra-wise. I just hope nobody is restarting it and calling it a day. | 14:03 |
sigmavirus | thomasem: why gerrit? or why does gerrit leak so much memory? or ?? | 14:03 |
sigmavirus | our infra team interfaces a lot with the gerrit developers, but none of them are gerrit developers iirc and none quite have time to become gerrit developers | 14:03 |
thomasem | Gotcha | 14:04 |
sigmavirus | so we report things but dont' fix them ourselves | 14:04 |
thomasem | I guess all of the above? | 14:04 |
sigmavirus | https://gerrit-review.googlesource.com/#/q/status:open+project:gerrit | 14:04 |
sigmavirus | So comparing Gerrit to GitLab merge reviews and GitHub merge reviews is unfair | 14:04 |
sigmavirus | Because someone let their new born child design GitHub's review system, and GitLab's is the result of being an Open Source project aimed at "The Enterprise" | 14:05 |
sigmavirus | Gerrit's review system makes sense when you consider that some project's style guides (for example, Linux) include commit message styling and content requirements | 14:06 |
sigmavirus | Basically, Gerrit is designed to work for most work large-scale review system workflows | 14:06 |
sigmavirus | OpenStack does code review at a very large scale but in a far less 'lieutenant based' way than Linux | 14:07 |
sigmavirus | Linux could, if Linus weren't a stick in the mud, begin using Gerrit today to do code review in a slightly more user-accessible way than the email system they use today | 14:07 |
sigmavirus | Gerrit is obviously harder to justify for smaller projects that exist entirely on their own | 14:08 |
sigmavirus | And Gerrit is harder to adopt for teams used to GitHub's workflow | 14:08 |
sigmavirus | And yes, feature branches, etc. make perfect sense (from GitHub's workflow) | 14:08 |
thomasem | Feels like you've had this chat quite a few times. | 14:09 |
sigmavirus | What sucks about it is that individual commits might be totally busted (per CI) and all GitHub cares about is the overall branch status | 14:09 |
sigmavirus | I actually quite like gerrit but recognize that (like many tools) it's value comes from context, not absolutism | 14:09 |
thomasem | I gotcha | 14:09 |
thomasem | It's all good points and definitely right tool for the right job. | 14:09 |
sigmavirus | Small teams that move fast and don't care about the project's git history, should absolutely use GitHub PRs | 14:10 |
thomasem | I do like the kind of global integration and such that's present with the Gerrit setup. | 14:10 |
sigmavirus | Yeah, Gerrit's value in OpenStack comes from the cross-project integratio | 14:10 |
thomasem | Yep | 14:10 |
sigmavirus | And that's something I've not seen in any other project | 14:10 |
sigmavirus | Also Gerrit's design makes maintaining stable branches so much nicer | 14:10 |
thomasem | Also, though cumbersome to some, I do appreciate that it enforces each commit to be an atomic piece of working software (assuming your tests are in order). | 14:11 |
sigmavirus | Maintaining stable branches on GitHub using PRs and code review makes one's head spin | 14:11 |
thomasem | Or, at least it tries to do that. | 14:11 |
sigmavirus | thomasem: right, that was my point versus GitHub's whole branch view | 14:11 |
thomasem | Yeah. That always annoyed the crap out of me when people abused it. | 14:11 |
sigmavirus | "working order" is only as good as your test suite =P | 14:11 |
sigmavirus | so in fairness, I tend to pull branches down now on other projects and rebase the branch prior to merging it manually | 14:11 |
thomasem | Lol, yes | 14:12 |
sigmavirus | And I do it such that stupid commits like "Fix flake8" or "Fix tests" are gone and each commit does work correctly | 14:12 |
sigmavirus | GitHub and its existing integrations provide no way to guide someone (via automated tooling) on hwo to make sure each commit is good | 14:12 |
sigmavirus | Also reviewing commit messages on GitHub is worse than going to the dentist with a mouthful of cavities | 14:13 |
thomasem | Whoa, I'm not sure I'd go that far. | 14:13 |
sigmavirus | I do it anyway, but that's besides the point =P | 14:13 |
thomasem | LOL | 14:13 |
sigmavirus | Hey, GitHub's awfulness has made me somewhat popular: https://github.com/sigmavirus24/github3.py | 14:14 |
sigmavirus | I thrive on their half-assed attempts to not lose open source developers on their platform | 14:14 |
sigmavirus | I can make a direct connection from that to the reason I have this job =P | 14:16 |
sigmavirus | And of course there's GerritHub.io too | 14:17 |
thomasem | Hahaha, that's awesome. | 14:18 |
thomasem | TIL | 14:20 |
thomasem | Thanks, sigmavirus | 14:20 |
sigmavirus | Sadly GerritHub as all the same UI flaws as Gerrit though =P | 14:21 |
thomasem | I believe that's substance over flash? | 14:24 |
thomasem | Yeah, the UI could use some work. :) | 14:24 |
thomasem | sulo: What about actually using ?vars=...&resolved-values=[true|false]? | 14:26 |
thomasem | Instead of adding yet another flag | 14:26 |
sulo | thomasem: ? | 14:26 |
thomasem | Re: https://review.openstack.org/#/c/440929/7//COMMIT_MSG | 14:26 |
sigmavirus | thomasem: Google is constantly working on the UI | 14:27 |
sulo | thomasem: ah yes perfect, ressolved-values=T/F is used in other palaces alow | 14:27 |
sulo | *also | 14:27 |
sigmavirus | probably stupid question | 14:27 |
sigmavirus | why do cells return variables by default and hosts don't? | 14:27 |
sigmavirus | is it because resolving a cells vars is easier/cheaper/there is no resolution? | 14:28 |
sulo | sigmavirus: on list ? | 14:28 |
sigmavirus | sulo: I didn't check list, but when I create a host with variables, the vars aren't returned, but they are for cells on create/update | 14:28 |
sulo | ah gotcha, sounds like a bug | 14:29 |
sigmavirus | although you can't update vars on a cell in a manner similar to create | 14:29 |
* sigmavirus shrugs | 14:29 | |
sigmavirus | I just noticed it in the integration test patch I threw up | 14:29 |
openstackgerrit | Ian Cordasco proposed openstack/python-cratonclient master: Add tests for our cells integration https://review.openstack.org/445515 | 14:29 |
sigmavirus | er rather, am throwing up | 14:29 |
thomasem | I think any inconsistencies there are bugs. | 14:29 |
sigmavirus | L106 in https://review.openstack.org/#/c/445515/1/cratonclient/tests/cassettes/TestCells-test_create.yaml | 14:29 |
sulo | yeah sounds like a bug | 14:30 |
sulo | it should be consistent in terms of create/list/get etc | 14:30 |
sigmavirus | list doesn't return vars | 14:30 |
sulo | yeah its not supposed to unless done with --details | 14:31 |
sigmavirus | oh poop | 14:31 |
sigmavirus | I've not tested cells.get | 14:31 |
sigmavirus | heh | 14:31 |
sulo | get should | 14:31 |
sulo | create shouuld if you created it with vars | 14:31 |
sulo | update should too | 14:31 |
sigmavirus | oh thomasem - question | 14:32 |
sigmavirus | How did we decide to expose the returned variables to users on things like cell objects etc? | 14:32 |
sigmavirus | cell.variables is the manager | 14:32 |
thomasem | cell.variables.get(), iirc | 14:33 |
thomasem | And that'd return your Variables MutableMapping | 14:34 |
thomasem | sigmavirus: ^^ | 14:34 |
sigmavirus | Will that return what was returned in the cell response, for example, or does that make a new request? | 14:34 |
thomasem | Makes a new request | 14:34 |
* sigmavirus thought so | 14:34 | |
sigmavirus | This means people will start using cell.to_dict()['variables'] to get at it | 14:35 |
thomasem | If only we did Variable update/delete via PUT or PATCH on the resource itself. | 14:36 |
thomasem | That doesn't jive well with variable resolution and such, though. It's all a bit confusing, if you ask me. | 14:37 |
thomasem | But, I don't have a great answer to the problem. | 14:38 |
thomasem | At least not yet. :P | 14:38 |
thomasem | At one time, I did have resource.variables point at the returned variables in the original call, but then we didn't have a good handle on updating/deleting them. | 14:39 |
thomasem | 'update' could be a very legitimate variable name. | 14:40 |
thomasem | so could 'delete' | 14:40 |
thomasem | Then again, it's the difference between a functional call and an attribute lookup... but I dunno. Maybe we could rework it to afford for using resource.variables? | 14:41 |
thomasem | Boy, that whole set of patches have already left my mental queue, lol. I'd need to go back and look at what we did to see what we might do alternatively. | 14:42 |
thomasem | sigmavirus: totally down for considering alternatives to the implemented solution and helping implement. I suspect we could figure something out to make that UX better. | 14:44 |
thomasem | I don't like it making a separate call for information it already has, too. | 14:44 |
thomasem | Especially if they're getting variables for a group of resources. | 14:45 |
thomasem | That's just plain wasteful | 14:45 |
jimbaker | thomasem, sounds good for revisiting this scheme. also how it works within the context of pruning queries (so we don't necessarily do more work than asked for) | 14:48 |
jimbaker | fsaad, did we post a etherpad for today's planning meeting? | 14:49 |
fsaad | yeah, sent email | 14:50 |
fsaad | lemme get url | 14:50 |
fsaad | https://etherpad.rax.io/p/craton-sprint-planning | 14:50 |
fsaad | at least I think I did send that in an email :) | 14:51 |
fsaad | noticed my 'etherpad' completion pushed me to internal etherpad though, doesn't matter to me as I'm always vpn'd but if it's a problem I can move it | 14:51 |
*** Syed__ has joined #craton | 14:52 | |
jimbaker | fsaad, so we need to put that doc here: https://etherpad.openstack.org/p/craton-SOME-DOC-HERE | 14:53 |
jimbaker | we have at least tojuvone planning to join us today | 14:53 |
jimbaker | and just need to make sure we keep this upstream in general | 14:54 |
fsaad | I'll call it sprint planning and we can just keep updating to the top, pushing down the older stuff so we always have same URL does that work for all ? | 14:55 |
sulo | fsaad: i still dont have the invite, the meeting is i 30 mins from now yes ? | 14:56 |
fsaad | https://etherpad.openstack.org/p/craton-sprint-planning | 14:56 |
fsaad | sulo: no | 14:56 |
jimbaker | fsaad, thanks! | 14:56 |
sulo | no ? | 14:56 |
sulo | i thought we were starting 30 mins early ? | 14:56 |
fsaad | do you not have the craton meeting / community specifics one either sulo ? | 14:56 |
fsaad | it's from 11:30-1:00PM CDT | 14:57 |
fsaad | I can do in 30 minutes if y'all want to and are available though | 14:57 |
fsaad | we need to figure out the calendar piece too, once and for all. | 14:57 |
sulo | fsaad: our regular meeting start in 1 hour | 14:57 |
fsaad | weird I guess I have an incorrect invite then. I only have a copy of one that thomasem sent my way at some point. | 14:58 |
fsaad | I can do in 30 mins if all are available, thomasem / jimbaker / sulo / sigmavirus / git-harry all good to go ? | 14:59 |
fsaad | tojuvone as well, who else plans to join ? | 15:00 |
tojuvone | yes | 15:00 |
git-harry | 30 minutes from now if fine by me. | 15:00 |
sulo | fsaad: works for me | 15:01 |
fsaad | good, getting close... sigmavirus ? | 15:01 |
sigmavirus | sorry, wfm too | 15:05 |
sigmavirus | thomasem: so I'm thinking that if /v1/cells doesn't return variables in those calls, then this becomes moot | 15:05 |
*** jovon has joined #craton | 15:05 | |
sigmavirus | that said | 15:06 |
sigmavirus | detailed=True would then still cause an issue | 15:06 |
sigmavirus | hm | 15:06 |
* sigmavirus wonders if supporting __getitem__ on a generic resource would be bad | 15:06 | |
sigmavirus | e.g., then instead of doing attribute magic, you do: `cell['variables'] | 15:07 |
sigmavirus | or `cell['id']` | 15:07 |
sigmavirus | and we proxy that through to _info | 15:07 |
sigmavirus | But I don't quite like that | 15:07 |
thomasem | I don't think there's going to be a perfect solution, just the better of the bad ones. :P | 15:08 |
sigmavirus | so that's a solution | 15:08 |
sigmavirus | Another is supporting a method like `get_original` that takes a string to retrieve the "original" value from _info | 15:09 |
thomasem | Instead of the Variable wrapped one? | 15:09 |
sigmavirus | thomasem: so right now cell.variables returns a VariableManager | 15:17 |
openstackgerrit | Thomas Maddox proposed openstack/craton master: Variable search for resources now uses resolved variables. https://review.openstack.org/440929 | 15:17 |
* sigmavirus is starting to second guess this API design | 15:17 | |
thomasem | The REST API or Python client? | 15:17 |
* sigmavirus wonders if cell.variables should return a Variable instance and if client.cells.variables.get(cell.id) is the right way | 15:18 | |
sigmavirus | ugh | 15:18 |
* sigmavirus has to go ponder for a while | 15:18 | |
thomasem | Gotcha | 15:18 |
fsaad | thanks sigmavirus , jimbaker you around for then ? | 15:19 |
fsaad | thomasem: assuming it works for you ? | 15:20 |
openstackgerrit | Thomas Maddox proposed openstack/craton master: Variable search for resources now uses resolved variables. https://review.openstack.org/440929 | 15:20 |
thomasem | fsaad: in 10 minutes? | 15:21 |
thomasem | Didn't see the scrollback until now. | 15:21 |
thomasem | It's DST that messed this up, I bet. | 15:21 |
thomasem | Rather, me not using the exactly correct timezone in the invite. | 15:21 |
thomasem | I'm cool w/ in 9 min. | 15:21 |
sigmavirus | thomasem: no, I blame jimbaker for not insisting things be scheduled in UTC =P | 15:22 |
fsaad | yeah 10mins | 15:22 |
fsaad | thomasem: and to be frank, I don't even know which invite we're using now | 15:22 |
fsaad | so doing ad-hoc for all I can tell, and wantt o fix this in the conversation today once and for all | 15:22 |
thomasem | Yes, please | 15:23 |
thomasem | Hmmm, so my invite was in UTC (Coordinate Universal Time) | 15:27 |
thomasem | Coordinated* | 15:28 |
jimbaker | hmmm | 15:28 |
jimbaker | i don't even have an invite. it's ok | 15:28 |
sigmavirus | what room are we doing? | 15:29 |
tojuvone | I also do not know | 15:29 |
thomasem | Craton-recordable | 15:29 |
sigmavirus | tojuvone: are you okay using Vidyo? | 15:34 |
tojuvone | yes, if it works ok from this hotel | 15:35 |
sigmavirus | tojuvone: https://vc.rackspace.com/flex.html?roomdirect.html&key=OpmgbcmKWcXB31Tbl7VHgTrytb0 | 15:35 |
tojuvone | sigmavirus, thanks, it just keep on joining in the screen | 15:36 |
sigmavirus | hm | 15:36 |
sigmavirus | what OS? | 15:37 |
tojuvone | Windows + Crome | 15:37 |
tojuvone | It worked before | 15:37 |
tojuvone | Firefox or IE better? | 15:37 |
sigmavirus | thomasem: and me rocking gunnars =P | 15:41 |
thomasem | YEAH! | 15:42 |
thomasem | They look nice. :) | 15:42 |
sigmavirus | I quite like mine | 15:46 |
sigmavirus | Mid-sprint retros/meditations make sense given we're in the midst of it and can course correct/test easier than otherwise | 15:50 |
sigmavirus | So who's done remote retros before and who has suggestions for remote retro tooling? | 15:55 |
jimbaker | sigmavirus, notes + possibly storyboard to track | 15:56 |
jimbaker | notes on this etherpad: https://etherpad.openstack.org/p/craton-sprint-planning | 15:56 |
* sigmavirus waves to jovon | 16:05 | |
jovon | hey there | 16:06 |
sigmavirus | pwnall138: threading | 16:07 |
sigmavirus | pwnall138: https://toolbelt.readthedocs.io/en/latest/threading.html | 16:08 |
sigmavirus | so my back-of-the-envelope guesses were correct | 16:08 |
* sigmavirus feels like Nostradomus | 16:08 | |
jimbaker | nice | 16:10 |
sigmavirus | thomasem: will you supply the fireplace? | 16:39 |
sigmavirus | We could all hop on http://conferencecall.biz/ for road-map planning though | 16:39 |
sigmavirus | jimbaker: we're over time | 16:59 |
thomasem | sigmavirus: of course | 17:03 |
fsaad | missed the last conversation piece, re: https://etherpad.openstack.org/p/craton-sprint-planning -L35-47, do we get names tacked on each task before we create the LP's for them ? | 17:12 |
jimbaker | fsaad, we let people pick up these items from LP | 17:17 |
jimbaker | by virtue of proposing a change into gerrit, they get the formal assignment | 17:17 |
fsaad | cool so just create new milestone and drop those there, then each picks their own. o/ | 17:18 |
jimbaker | everything else is done informally - i know that you're working on X, so may want to coordinate with you. but hopefully to prevent sitting on X | 17:18 |
jimbaker | hope that makes sense! | 17:18 |
fsaad | cool thanks jimbaker ! | 17:18 |
jimbaker | (i was one of the big violators of this approach btw - i knew X is something i could really help out on, but given i was working on Y and Z as well... X wasn't getting done by me, nor anyone else) | 17:19 |
fsaad | gotcha, yeah squatting a ticket ;) | 17:20 |
jimbaker | exactly | 17:20 |
jimbaker | also this gets into a different approach, which thomasem does a great job of, which is to push up changes early into gerrit | 17:21 |
jimbaker | just mark as WIP, but now there's something - and now we actually a real WIP recorded in the bug system | 17:22 |
jimbaker | so all good stuff! | 17:22 |
jimbaker | updated the discussion of resolution ordering on how we treat device sharing. hopefully this is rare, and vars don't conflict, but we can come up with a scheme that is robust if they do | 18:02 |
tojuvone | jimbaker, I updated something on the ops etherpad. Otherwise there is not much than now or tomorrow for me to catch up what to talk/present | 18:08 |
jimbaker | tojuvone, ok, i must update | 18:09 |
tojuvone | I think it is less about the entherpad, but more about the things to go trough | 18:10 |
tojuvone | 35-40mins, if people do not have things to ask/talk straight, it would be more presenting where we are and what is coming | 18:12 |
tojuvone | and if to demo, would be nice to have that fluent sulo presentation to show / or do the same in live. | 18:16 |
*** jovon has quit IRC | 18:22 | |
jimbaker | thomasem, i worked through shared devices some more, and it's interesting. conclusion: i think there's no "right" solution, so it's likely we are going to have to punt to the client/richer variables model | 18:30 |
jimbaker | see the updates in https://etherpad.openstack.org/p/craton-sprint-planning | 18:30 |
jimbaker | ok, next up, the etherpad/demo planning for milan. then i will get back to dev work | 18:40 |
tojuvone | cool, although it is out the dev work | 18:42 |
jimbaker | the dev work will take care of itself! just need to do the juggling | 18:44 |
tojuvone | Please be free to update, just made it something more than template | 19:26 |
thomasem | jimbaker: looking | 20:40 |
jimbaker | tojuvone, thanks! | 20:53 |
jimbaker | thomasem, feel free to pepper me with questions | 20:53 |
jimbaker | it occurs to me that it might be a whole lot better to implement the functionality of https://bugs.launchpad.net/craton/+bug/1665050 in the client | 20:53 |
openstack | Launchpad bug 1665050 in craton "Support alternative variable overrides" [Undecided,New] | 20:53 |
jimbaker | given that, we probably will never get it right for some need | 20:54 |
jimbaker | so might as well provide all the info that alternative strategies need | 20:54 |
thomasem | Well, I am wondering how we're going to represent multiple values since a value can actually be a list. | 20:54 |
jimbaker | or a dict | 20:55 |
thomasem | right | 20:55 |
thomasem | It can be a string, list, or dict. | 20:55 |
thomasem | or bool | 20:55 |
thomasem | or int | 20:55 |
thomasem | or float | 20:55 |
jimbaker | :) | 20:55 |
jimbaker | or None | 20:55 |
thomasem | Yep | 20:55 |
jimbaker | don't forget it. it always gets forgotten :) | 20:55 |
thomasem | Haha, right | 20:55 |
thomasem | Point being... how do we represent multiple values for a variable if the value of a variable can be a list? | 20:56 |
thomasem | Unless values is always a list of possible values | 20:56 |
jimbaker | yeah, so clearly there's extra content that can be associated with a given key | 20:56 |
jimbaker | blame info, audit history, etc | 20:56 |
thomasem | Yeah | 20:56 |
jimbaker | and now we want to extend this further and say, what about your multiple parents? | 20:57 |
jimbaker | so step back | 20:57 |
jimbaker | why sharing | 20:57 |
jimbaker | ? | 20:57 |
thomasem | I still don't quite get that anyway... | 20:57 |
jimbaker | i don't think it's so something complicated var resolution strategy can apply... ;) | 20:57 |
jimbaker | instead, it's in this cloud context: this device does such-and-such | 20:58 |
thomasem | Are you positing that we don't allow resolution on shared devices? | 20:58 |
jimbaker | and in some other cloud usage: it's doing something different | 20:58 |
jimbaker | i'm thinking it's really contextual | 20:58 |
thomasem | So, how would you expect a shared device to be used? | 20:59 |
jimbaker | so because i'm considering this device is used in some cloud, i care about the vars for that cloud | 20:59 |
thomasem | Oh, right, yes. | 20:59 |
jimbaker | with cloud: do something? | 21:00 |
jimbaker | i don't know | 21:00 |
thomasem | But, what if a root level is querying? | 21:00 |
thomasem | s/root level/root user/ | 21:00 |
jimbaker | then it sees everything | 21:00 |
jimbaker | and has to deal accordingly | 21:00 |
jimbaker | i mean it's not a simple picture | 21:00 |
thomasem | Right, but how does it see everything when we can't properly represent resolved variables for shared devices? At that point we still have to solve for this, and it's not able to easily be scoped contextually. | 21:01 |
jimbaker | i didn't say i was solving anything in a nice easy way with alternative #1 | 21:01 |
jimbaker | it just seemed that other, nicer solutions like #3 (use C3) might be solving a different problem | 21:01 |
thomasem | Yeah | 21:02 |
thomasem | Regarding MRO, that only works out alright because the developer specifies the primary parent to inherit from, regarding multiple inheritance. It's far more ambiguous with stored data without a guaranteed order. | 21:02 |
jimbaker | so sharing is actually messy | 21:02 |
thomasem | Very | 21:02 |
thomasem | Because it fundamentally undermines the way resolution is supposed to... well, resolve. :) | 21:03 |
jimbaker | :) | 21:03 |
jimbaker | yeah, it was such a beautiful fairy tale | 21:03 |
thomasem | We could merge values... but that gets hairy, too, since they may not be the same data type. | 21:03 |
thomasem | Rather, lemme revise that, the merging may not be viable period | 21:04 |
thomasem | due to the data type | 21:04 |
thomasem | If it's dictionaries, sure. | 21:04 |
jimbaker | indeed. that's why punt to the client seems like such a viable answer | 21:04 |
thomasem | lists, maybe | 21:04 |
jimbaker | "lists as sets" | 21:04 |
jimbaker | so i don't know | 21:04 |
thomasem | Same | 21:05 |
thomasem | The only thing that seems to work for all cases that I can think of so far, I don't like. And that'd be making it so value is always a list of values | 21:05 |
jimbaker | you mean, like a join? | 21:05 |
thomasem | But, then you have the attribution problem, which I suppose one would need to go to the blame API for? | 21:06 |
jimbaker | so that's why i think the blame interface is the only real solution | 21:06 |
thomasem | Frankly, I feel like the shared device use-case isn't understood all that way, but that could just be me. | 21:06 |
thomasem | all that well* | 21:06 |
thomasem | s/all that way/all that well/ | 21:06 |
thomasem | Sorry | 21:07 |
jimbaker | clearly we need to bring in domain users here | 21:07 |
thomasem | I think it'd be helpful. I want to know what they'd expect to see. | 21:07 |
thomasem | I wonder if Ansible has any solution? | 21:07 |
thomasem | with group_vars and such... like how do they deal with that? | 21:07 |
thomasem | Seems like they'd have to scope to something. | 21:07 |
jimbaker | iirc ansible's model is too simple | 21:07 |
thomasem | Which goes back to your comment about it being contextual | 21:07 |
jimbaker | but puppet hiera is ambitious enough to possibly include | 21:08 |
thomasem | meaning we wouldn't have to worry if we could derive from the context which value to favor, as it'd be a part of the query already. | 21:08 |
jimbaker | yes | 21:08 |
thomasem | is only ever shared between clouds? | 21:08 |
thomasem | Or can it also be shared between, say, cells... regions? | 21:08 |
jimbaker | possibly regions or cells | 21:08 |
jimbaker | only happens with smaller envs | 21:09 |
jimbaker | but test cloud vs dev cloud | 21:09 |
jimbaker | that sort of thing | 21:09 |
thomasem | Yeah, so that makes it _really_ difficult to scope. Because now it would require the root user to have prior knowledge in order to scope it... kind of undermines this whole thing. | 21:09 |
thomasem | At multiple levels of the cloud | 21:09 |
thomasem | not just the cloud itself | 21:09 |
jimbaker | again the whole point of the vars model is to provide a loophole of, we don't know what you want to do with your cloud(s), but we will provide some supporting infra | 21:10 |
thomasem | So... what do we do? I think we ought to go to the users and ask how they plan to use shared devices and this time dig in more. | 21:11 |
jimbaker | anyway.... i raise this so we can start thinking about approaches. but my preferred alternative this moment is #1 and somehow let the client handle, with the api server providing a blame api | 21:11 |
jimbaker | thomasem, agreed | 21:12 |
thomasem | Let me see if I understand approach #1 | 21:12 |
thomasem | Mmmm, actually, I'm not sure I have an understanding yet. So... you're suggesting that we some how attribute the ambiguity to the parent it belongs to. Say, some how attribute the variable(s | 21:14 |
thomasem | ) | 21:14 |
thomasem | that are shared to the differing parent | 21:14 |
thomasem | (side note: why did we go with resolved-values instead of resolved_values?) | 21:15 |
jimbaker | thomasem, small stuff like that slips through reviews, and it does feel inconsistent | 21:19 |
thomasem | Well, also can't pass it as **params to self.get :) | 21:19 |
thomasem | Because... yeah, python identifier | 21:19 |
jimbaker | yeah | 21:19 |
jimbaker | so we should fix | 21:19 |
thomasem | Mmmkay. Will file a bug. | 21:19 |
jimbaker | now is not the time to say we are stuck with v1 of our API | 21:20 |
jimbaker | we are trying to stabilize the db... that's our level of maturity | 21:20 |
thomasem | cool | 21:22 |
thomasem | https://bugs.launchpad.net/craton/+bug/1672880 | 21:22 |
openstack | Launchpad bug 1672880 in craton "inconsistent URL param name, "resolved-values"" [Undecided,New] | 21:22 |
jimbaker | thomasem, thanks | 21:22 |
thomasem | you betcha | 21:22 |
jimbaker | ok, so let's table this conversation on shared devices until tomorrow if that's ok | 21:23 |
thomasem | Sure | 21:23 |
jimbaker | need some rumination i think... | 21:23 |
thomasem | No worries. I have to entertain this evening, so will need to step away shortly to get some cleaning done. | 21:24 |
thomasem | Wow that sounded bad. I'm going to entertain and want to. Nothing about it is an obligation. :P | 21:24 |
jimbaker | thomasem, no full confession required ;) | 21:29 |
thomasem | Lol | 21:29 |
thomasem | Elsa is chasing her tail so enthusiastically. | 21:35 |
thomasem | She used to be able to catch it, poor thing. | 21:35 |
antonym | is there a hidden --verbose flag for the cratonclient by chance? | 21:43 |
antonym | novaclient had one which was useful for seeing the url being called on the request | 21:44 |
thomasem | antonym: not yet: https://bugs.launchpad.net/python-cratonclient/+bug/1666734 | 21:44 |
openstack | Launchpad bug 1666734 in Craton's Python Client "Support debug logging for client/CLI" [High,New] | 21:44 |
antonym | ah, sweet | 21:44 |
thomasem | Yeah, I can certainly agree it's annoying right now not having that. | 21:45 |
antonym | yeah, luckily the debug on the server output is useful | 21:45 |
thomasem | :) good! | 21:45 |
antonym | btw, dropped a bug for the client, seems to let host-deletes work all day even if the id doesn't exist | 21:46 |
antonym | https://bugs.launchpad.net/python-cratonclient/+bug/1672570 | 21:46 |
openstack | Launchpad bug 1672570 in Craton's Python Client "craton host-delete shows succesfully deleted if item does not exist." [Undecided,New] | 21:46 |
thomasem | Yeah. I remember during some dev I quickly threw a traceback formatter here: https://github.com/openstack/python-cratonclient/blob/master/cratonclient/shell/main.py#L200 | 21:46 |
thomasem | to help some | 21:46 |
antonym | ah, cool, maybe i'll give that a whirl | 21:47 |
thomasem | antonym: https://review.openstack.org/#/c/427032/39/cratonclient/shell/main.py | 21:48 |
thomasem | Helped me at least get the traceback when things went wrong. But, yeah, we really need verbose logging for http, etc. | 21:49 |
thomasem | Allllrighty. Have a lovely evening, y'all! | 21:55 |
jimbaker | yeah, let's get this done in this bug in the upcoming cycle. along with other fit & finish bugs that are out there | 22:02 |
jimbaker | as we have time | 22:02 |
jimbaker | thomasem, have a good one! | 22:02 |
antonym | hmm, get this trace on a host show after resetting the db and using the bootstrap command: https://gist.github.com/antonym/d23c766d6673e6873335ae76ed57e94e | 22:55 |
jimbaker | antonym, that means that the variable association table is missing an entry | 22:55 |
jimbaker | of course the whole point of using the bootstrap command is to provide said entries | 22:56 |
jimbaker | by avoiding direct mysql | 22:56 |
antonym | https://gist.github.com/antonym/7e7b40b264c5e159f4f482affc7e1bce ? | 22:56 |
antonym | that one? | 22:56 |
jimbaker | antonym, that's the one | 22:57 |
jimbaker | looks like it's making one for each entry | 22:57 |
jimbaker | really need to get my alembic script merged in | 22:57 |
antonym | yeah, so i pulled latest master, and ran the upgrade and bootstrap | 22:57 |
jimbaker | antonym, you want to try that out | 22:57 |
jimbaker | it should prevent errors at least | 22:57 |
antonym | sure | 22:57 |
jimbaker | https://review.openstack.org/#/c/441644/ | 22:58 |
antonym | same | 22:59 |
antonym | still tossed the exception with that patch | 22:59 |
jimbaker | ok, it didn't reject that constraint | 23:00 |
jimbaker | ok, at this point we need to try to reproduce exactly your build script | 23:00 |
jimbaker | sorry, meant to say, new constraints didn't reject whatever would cause that problem. or something like that :) | 23:00 |
antonym | https://gist.github.com/antonym/12611a83d10e199f2458229890ae4362 | 23:02 |
antonym | that's pretty much it | 23:02 |
jimbaker | antonym, ok, i see what's going on | 23:03 |
antonym | did i goof? | 23:03 |
jimbaker | we don't want you creating anything with mysql :) | 23:03 |
jimbaker | so, yes | 23:03 |
antonym | ah, ok | 23:03 |
antonym | that was left over from the previous build script | 23:03 |
jimbaker | technically you could but you need to obey all the constraints | 23:03 |
jimbaker | in the modeling code | 23:03 |
antonym | ok, so let me retry and use the client to make the users | 23:04 |
jimbaker | yeah, that's the way to do it. thanks! | 23:04 |
jimbaker | v1/users and v1/projects. should give you all the functionality | 23:04 |
antonym | k | 23:04 |
antonym | ah, so it's not creating the variable assoication ids | 23:05 |
jimbaker | exactly | 23:05 |
antonym | gotcha | 23:05 |
jimbaker | and without those, you are violating the model | 23:05 |
antonym | yeah | 23:05 |
jimbaker | since we are about to enhance the model further with rbac... really need to go through the api to build stuff | 23:06 |
antonym | yeah, agree | 23:06 |
jimbaker | (it will have similar assoc tables. nothing so complex mind you.) | 23:06 |
antonym | i think this was a copy pasta thing i did a while ago | 23:07 |
jimbaker | no worries, glad we could quickly debug | 23:07 |
antonym | yep, thanks! | 23:07 |
antonym | so i guess creating a user puts them in the default project currently? can you specify the project you want to create the user in? | 23:26 |
antonym | https://gist.github.com/antonym/13b16c4673e9056c8f6792420b2764ef so i'm guessing you post project_id along with user? it still seems to want to throw it in the default bootstrap project | 23:44 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!