| *** VW has joined #craton | 00:25 | |
| *** VW has quit IRC | 00:29 | |
| *** VW has joined #craton | 01:27 | |
| *** VW has quit IRC | 01:31 | |
| *** VW has joined #craton | 02:29 | |
| *** VW has quit IRC | 02:33 | |
| *** VW has joined #craton | 03:44 | |
| *** VW has quit IRC | 03:50 | |
| *** VW has joined #craton | 04:47 | |
| *** wdfwefewvfgew has joined #craton | 04:51 | |
| *** wdfwefewvfgew has left #craton | 04:51 | |
| *** VW has quit IRC | 04:52 | |
| *** valw has joined #craton | 05:52 | |
| *** valw has quit IRC | 05:53 | |
| *** VW has joined #craton | 06:24 | |
| *** VW has quit IRC | 06:30 | |
| *** VW has joined #craton | 08:06 | |
| *** VW has quit IRC | 08:11 | |
| *** VW has joined #craton | 09:09 | |
| *** VW has quit IRC | 09:14 | |
| *** acabot has joined #craton | 09:16 | |
| *** git-harry has quit IRC | 10:47 | |
| *** git-harry has joined #craton | 10:48 | |
| *** git-harry has quit IRC | 11:07 | |
| *** git-harry has joined #craton | 11:08 | |
| *** git-harry has quit IRC | 11:23 | |
| *** git-harry has joined #craton | 11:24 | |
| *** git-harry has quit IRC | 11:31 | |
| *** git-harry has joined #craton | 11:32 | |
| *** VW has joined #craton | 12:14 | |
| sulo | thomasem: the way i am used to it, and have seen in openstack (nova mostly) is whoever gets the review in first should not have to worry about this ... but since we are not doing consistent reviews this dont work in this project and a patch that happened weeks after yours gets in the way | 12:15 |
|---|---|---|
| sulo | not saying its always a problem .. but sometime its frustrating. | 12:15 |
| *** VW has quit IRC | 12:20 | |
| git-harry | sulo: I thought you were off this week? | 12:20 |
| sulo | git-harry: i am :) | 12:20 |
| git-harry | sulo: is there anything you need me to pick up while you're off? | 12:21 |
| sulo | git-harry: thanks, yeah if you dont mind ? its a very simple bug. | 12:21 |
| sulo | https://bugs.launchpad.net/craton/+bug/1662496 | 12:22 |
| openstack | Launchpad bug 1662496 in craton "Host response is missing parent_id property" [High,New] - Assigned to Sulochan Acharya (sulochan-acharya) | 12:22 |
| git-harry | sure, I can do that. Anything else? | 12:23 |
| sulo | thats the main one .. its missing the parent_id and need to add links pointing to the parent | 12:24 |
| git-harry | sounds good. | 12:25 |
| *** VW has joined #craton | 12:32 | |
| git-harry | sulo: is there a separate bug tracking adding the parent links? | 12:37 |
| *** VW has quit IRC | 12:37 | |
| sulo | git-harry: i havent made one sperate for that .. i suppose this bug is slightly incomplete | 12:41 |
| sulo | in the sense that we need to add parent_id to response so parent-child can be tracked | 12:41 |
| sulo | so links could be a part of that. | 12:41 |
| git-harry | sulo: that's fine, I just want to be clear. | 12:42 |
| *** VW has joined #craton | 13:42 | |
| *** VW has quit IRC | 13:47 | |
| thomasem | sulo: Thanks for the explanation and your thoughts. That makes sense. | 14:29 |
| *** VW has joined #craton | 14:34 | |
| jimbaker | thomasem, sorry about your project vars work. we have had two things: 1. git-harry's approach of doing this as a mixin in the api was so obvious the right way to do it (and i had hoped we would get to0 | 14:54 |
| jimbaker | 2. the discussion on the DELETE format | 14:54 |
| thomasem | It's not a big deal. I mention it because I also saw sigmavirus mentioning some stuff about it last week, too, iirc. If it's a chronic thing going on here, thinking it'd be better to talk about it and see what we can do to address it. | 14:57 |
| thomasem | jimbaker: ^^ | 14:57 |
| jimbaker | sulo, thomasem - i'm having difficulty setting up outside this test the REST API calls for labels. i am also concerned about how the query actually works - at the very least it requires unnecessary joins, but it seems to me it has a different logic for how multiple labels would match (disjunctive, vs conjunctive) | 14:57 |
| thomasem | jimbaker: What problems are you running into? | 14:58 |
| thomasem | And would you mind providing an example of your last point? | 14:59 |
| jimbaker | thomasem, just setting up the basic label support | 14:59 |
| jimbaker | also, what's up with the different payload, vs in variables? | 14:59 |
| jimbaker | anyway... meeting | 15:00 |
| sigmavirus | git-harry: care to join is in #openstack-meeting-4? | 15:03 |
| *** Syed__ has joined #craton | 15:19 | |
| sigmavirus | thomasem: btw, were you wearing Gunnar's last week? | 15:44 |
| -openstackstatus- NOTICE: We are currently investigating an issue with our AFS mirrors which is causing some projects jobs to fail. We are working to correct the issue. | 15:48 | |
| thomasem | sigmavirus: I was! | 16:00 |
| jimbaker | we can continue to discuss what was on our agenda over here | 16:00 |
| thomasem | I might have to step away at a moment's notice. Pest control is coming by this morning. | 16:00 |
| thomasem | FYI | 16:00 |
| thomasem | Getting prepped for spring time | 16:00 |
| jimbaker | thomasem, no worries, and i appreciate the heads up | 16:00 |
| jimbaker | it is interesting, we have our version of pest control in colorado | 16:01 |
| thomasem | What? Winter? | 16:01 |
| sigmavirus | thomasem: how do you like them? Thinking of getting a pair for myself | 16:01 |
| jimbaker | it's called, -20°F temps | 16:01 |
| thomasem | YEP | 16:01 |
| thomasem | sigmavirus: they're great! I got LASIK a month and a half ago, so they have been immensely helpful for eye strain. | 16:01 |
| jimbaker | just a couple of nights of that, that's all that's necessary | 16:01 |
| thomasem | sigmavirus: Since I was in recovery from that over the holidays, but I still wanted to play video games, they were a necessity. | 16:03 |
| thomasem | And likewise, they help when I'm sitting here staring at code and forget to blink and such. | 16:04 |
| jimbaker | ahh, good idea about the tinting | 16:04 |
| thomasem | jimbaker: I can imagine | 16:04 |
| thomasem | Does it get cold enough there to throw hot coffee out of your back door and have it hit the ground cold/frozen? | 16:04 |
| thomasem | :P | 16:04 |
| jimbaker | no | 16:05 |
| jimbaker | this is not minnesota | 16:05 |
| jimbaker | it will be in the 50s to 70s this week | 16:05 |
| thomasem | That's right. I'd heard stories about that from friends who live around that area. | 16:05 |
| thomasem | Sounds awesome | 16:06 |
| jimbaker | so usual spring weather. of course probably next week it will snow | 16:06 |
| thomasem | Lol | 16:06 |
| *** klindgren has joined #craton | 16:07 | |
| thomasem | So, I wanted to chat a bit about the requirements/user stories doc. I'm not wild about us duplicating that information somewhere, I would really prefer it be a public document to begin with. It's cool to have a private copy, but the more times it gets replicated, the higher chance for confusing somebody | 16:07 |
| thomasem | and things getting out of sync | 16:07 |
| thomasem | I can see a case for 1 private with maybe some internal details or something, that then translates to 1 public copy. But, having it spread out across waffle cards and etherpads and collab word documents... | 16:08 |
| jimbaker | thomasem, it gets crazy | 16:08 |
| thomasem | Just doesn't seem like a good idea | 16:08 |
| jimbaker | so i pushed back against waffle cards and the like | 16:08 |
| thomasem | Gotcha | 16:08 |
| jimbaker | the only problem is, launchpad has no great way to roll up stuff without building some external reporting | 16:08 |
| jimbaker | and storyboard isn't really happening, is it? | 16:09 |
| thomasem | storyboard? | 16:09 |
| jimbaker | https://wiki.openstack.org/wiki/StoryBoard/Roadmap | 16:09 |
| thomasem | Ahhhhhh | 16:09 |
| thomasem | I didn't know we were going to go that route with OpenStack | 16:09 |
| thomasem | Well, talking about it. From your comment, I guess it's stalled? | 16:09 |
| jimbaker | well, it was a good idea | 16:09 |
| jimbaker | and yes, at best, slow progress | 16:10 |
| cloudnull | thomasem: we have a meeting at 11 can we push to 11:30 ? | 16:11 |
| cloudnull | there are a few folks that want to attend that cant due to conflicts. | 16:11 |
| jimbaker | cloudnull,+1 | 16:11 |
| thomasem | cloudnull: Ohhhh, I would love to. | 16:11 |
| cloudnull | cool | 16:11 |
| thomasem | Since pest control just called | 16:11 |
| thomasem | lol | 16:11 |
| cloudnull | can you resend the invite ? | 16:11 |
| jimbaker | thomasem, so back to https://review.openstack.org/#/c/432355/ | 16:12 |
| thomasem | cloudnull: sent update. Did you get it? | 16:12 |
| cloudnull | yup | 16:13 |
| cloudnull | can you add sigmavirus ? | 16:13 |
| cloudnull | oh, nevermind | 16:14 |
| cloudnull | tyvm | 16:14 |
| thomasem | jimbaker: okay, looking. btw, pest folks will be here in ~15 min | 16:15 |
| jimbaker | thomasem, i think we can resolve momentarily | 16:15 |
| jimbaker | so a couple of things | 16:16 |
| thomasem | Alright, so, yeah.. it just seemed like it was kind of overloading the purpose of some of these tests by also doing assertions on, like, being able to do a full get, set, delete on variables for, say, a create test. | 16:16 |
| thomasem | I see the case for exercising those assertions in separate tests, but variable delete breaking shouldn't be breaking a create test | 16:17 |
| jimbaker | thomasem, understood. it just seemed that these were potentially unique setups | 16:17 |
| jimbaker | and so adding some strengthening would be valuable | 16:17 |
| jimbaker | the question is, would it make everything then brittle - and less unitary | 16:17 |
| jimbaker | in terms of the unit testing | 16:17 |
| thomasem | I don't disagree, but that might be a case for a separate test exercising the unique setup and then testing that variable CRUD still works, in my opinion. | 16:17 |
| jimbaker | thomasem, so these tests need a strong dose of refactoring | 16:18 |
| jimbaker | i made some fixes to make them more consistent | 16:18 |
| thomasem | test_new_project_variable_crud, test_updated_project_variable_crud, etc. | 16:18 |
| jimbaker | eg `cells = response.json()` | 16:18 |
| jimbaker | thomasem, i would prefer to parameterize the test | 16:19 |
| jimbaker | so we can mixin var testing | 16:19 |
| thomasem | Philosophically that can get a bit over-the-top and you wind up needing tests for your tests... | 16:19 |
| jimbaker | maybe. it is used i think quite successfully in the python standard library in some pladces | 16:20 |
| jimbaker | so stuff that is like a dict or a set or what-have-you can share tests | 16:20 |
| jimbaker | we very much have this ehre | 16:20 |
| jimbaker | here | 16:20 |
| thomasem | Well, I don't mean to jump in here and start imposing my philosophy. I'll simply speak my concern here. I don't see a problem if it's kept simple. But, the moment we start doing excessive branching or anything to keep tests DRY, or obscuring the actual thing that's being tested, I'm going to be worried about it. | 16:21 |
| jimbaker | vars are a cross cutting concern. so too will be rbac | 16:21 |
| jimbaker | thomasem, yeah, it will hopefully be even more DRY | 16:21 |
| jimbaker | because we will be able to enjoy that common setup | 16:22 |
| thomasem | I'm positing that, to a degree, trying to be DRY in tests can be a double-edged sword and you wind up introducing the potential for bugs in your tests themselves. | 16:22 |
| thomasem | I'm not sure I see the unique setups you're referring to that could impact the variable CRUD, though? Mind elaborating? | 16:23 |
| jimbaker | but right now, i'm more concerned that because of duplicated code, we expose ourselves to stuff that doesn't work where expected | 16:23 |
| jimbaker | less so now that we have git-harry's awesome refactoring in place | 16:23 |
| thomasem | right | 16:23 |
| jimbaker | thomasem, but one example comes to mind | 16:24 |
| jimbaker | we need to ensure that variables properly override in the hierarchy | 16:24 |
| jimbaker | so we want this to be part of the testing setup | 16:24 |
| jimbaker | this is NOT done right now | 16:24 |
| jimbaker | even with this patch | 16:25 |
| thomasem | That sounds like a separate test asserting exactly that scenario. | 16:25 |
| jimbaker | but it should work in conjunction with a resource/fixture setup | 16:25 |
| jimbaker | hence this parameterization | 16:25 |
| jimbaker | we already have nicely parameterized tests. git-harry did this for the schema stuff | 16:26 |
| jimbaker | it's a very good thing | 16:26 |
| thomasem | jimbaker: I don't really have issue with the parameterization, btw. I am saying that sprinkling those assertions in so many different tests where they'll assert things unrelated to the test itself (judged by the name of the test), gets confusing. | 16:26 |
| jimbaker | i would like to see more of this in our testing. and our coding. less duplication. stronger testing. | 16:26 |
| thomasem | So, I added a separate test or two for projects, when implementing on top of your patch, to test the variable CRUD separately, using your parameterized assertions. | 16:27 |
| thomasem | brb | 16:27 |
| jimbaker | thomasem, ttyl | 16:27 |
| thomasem | jimbaker: back | 16:37 |
| thomasem | So, yeah. I mean, ultimately I'm only pointing out some concerns I have with this approach. I think we can have both, All I'm asking is that we put the assertions when they're not directly related to the test they're a part of and put them in a separate test. | 16:39 |
| thomasem | So, instead of asserting that, say, variables can be set in a test_project_create_with_variables test, we'd assert separately something like test_new_project_variables_crud and do those assertions there, and use the same setup. | 16:40 |
| thomasem | jimbaker: ^^ | 16:40 |
| thomasem | Boy, butchered that first statement. I'm suggesting that we don't try to assert things beyond the scope of the test implied by the name of the test. | 16:40 |
| thomasem | To put it succinctly. | 16:41 |
| thomasem | When I see test_create_<resource>_with_variables, I assume you're going to create the resource with variables as a part of the request and assert that it was set up as expected, nothing more. | 16:42 |
| thomasem | When I see test_put_<resource>_variables, I assume you're going to test that you can PUT new variables to an existing resource, and I expect to see assertions that the new dict of variables match what's expected, nothing more. | 16:43 |
| thomasem | In your patch, in both types of scenarios, I'm seeing additional assertions on each of these types of tests to, such as seeing that variables can be set and deleted on a test_<resource>_create_with_variables test, and that variables can be deleted on a test_put_<resource>_variables test. | 16:44 |
| thomasem | Which is beyond the implied scope and will get broken by unrelated things. | 16:44 |
| thomasem | It's easier to have lots of tests with limited scope than few tests with a ton of scope. | 16:44 |
| thomasem | Reason being, then you can more-easily track down what actually broke. | 16:45 |
| thomasem | After saying all of this, if you still feel that the thing you're doing is the "right" thing, then I will say no more for now. | 16:46 |
| thomasem | And lift my -1 | 16:47 |
| thomasem | Syed__: Saw you pushed a change to https://review.openstack.org/#/c/427777? | 16:51 |
| Syed__ | thomasem: i wanted this to be baseline for my change for https://review.openstack.org/#/c/425463/ | 16:53 |
| jimbaker | thomasem, np. overconstrained is not great, and violates unit testing | 16:53 |
| Syed__ | since my change should be on top of this change | 16:53 |
| jimbaker | i think the only thing i was trying to do here was reuse some resource setups. maybe i can do a quick refactoring to further pull out | 16:54 |
| jimbaker | and then that will get us closer to something where we test what the test says it is doing in its test name | 16:54 |
| jimbaker | later, we can revisit with some additional parameterization | 16:55 |
| jimbaker | thomasem, how does that sound? | 16:55 |
| thomasem | Perfectly reasonable to me! | 16:55 |
| thomasem | If it winds up taking too much time, I'm sure we can file a bug and address separately, too. | 16:55 |
| jimbaker | thomasem, yeah, that was my only concern | 16:55 |
| jimbaker | because time | 16:55 |
| thomasem | Wanting to be sure we agree on the direction here, is my main goal. | 16:55 |
| jimbaker | these are absolutely critical fixes, because no var support in the client/CLI, well that basically breaks everything | 16:56 |
| jimbaker | in terms of a usable product. so no pressure :) | 16:56 |
| thomasem | LOL yes | 16:56 |
| thomasem | So, if it's time you're worried about, we can file a bug and reference the types of issues we're trying to clean up. | 16:57 |
| jimbaker | thomasem, i'm just going to time box. and i am going to +2 it if you give it a +1. pretty simple | 16:57 |
| thomasem | jimbaker: sgtm! Thanks for hearing me out. | 16:57 |
| jimbaker | np, great feedback, and moving to something that's better | 16:58 |
| thomasem | Sweet | 16:59 |
| thomasem | Syed__: hmmm, okay. Didn't realize. Heh, the changes you made might conflict with what I was about to push up | 16:59 |
| Syed__ | hmm, i guess mine needs to wait either way since failing some other things due to conflicts | 17:00 |
| Syed__ | +1 thomasem thanks, | 17:00 |
| thomasem | Syed__: we're probably going to get jimbaker's patch in today, I think? | 17:00 |
| *** VW has quit IRC | 17:00 | |
| thomasem | Then mine will follow shortly, I imagine | 17:00 |
| thomasem | And then we'll be scooting right along | 17:01 |
| Syed__ | Cool sounds good | 17:01 |
| *** VW has joined #craton | 17:01 | |
| *** VW_ has joined #craton | 17:01 | |
| *** VW_ has quit IRC | 17:02 | |
| *** VW_ has joined #craton | 17:03 | |
| *** VW_ has quit IRC | 17:03 | |
| *** VW_ has joined #craton | 17:04 | |
| *** VW has quit IRC | 17:05 | |
| jimbaker | thomasem, yes, we will get that patch in today | 17:06 |
| thomasem | super duper | 17:06 |
| *** jovon has joined #craton | 17:13 | |
| -openstackstatus- NOTICE: AFS replication issue has been addressed. Mirrors are currently re-syncing and coming back online. | 17:17 | |
| thomasem | jimbaker: made your review (commit) the parent to mine. | 17:27 |
| jimbaker | cool | 17:27 |
| thomasem | working through some odd functional test failures now | 17:28 |
| *** VW_ has quit IRC | 18:04 | |
| *** VW has joined #craton | 18:07 | |
| *** david-lyle_ has joined #craton | 18:08 | |
| *** david-lyle_ is now known as david-lyle | 18:12 | |
| thomasem | cloudnull: wanted to let you know - we are working on adding the Cloud resource. It's mostly wiring it up and moving region down one level in the hierarchy in Craton. Here's the bug for it - https://bugs.launchpad.net/craton/+bug/1662576 | 18:17 |
| openstack | Launchpad bug 1662576 in craton "Support multiple clouds in a given project" [High,New] - Assigned to Thomas Maddox (thomas-maddox) | 18:17 |
| thomasem | Getting another patch cleaned up, then moving back to working on this. | 18:17 |
| thomasem | I anticipate, with some code reviews, having that feature merged in by EoW. | 18:18 |
| jimbaker | cloudnull, thomasem, https://bugs.launchpad.net/craton/+bug/1664328 | 18:43 |
| openstack | Launchpad bug 1664328 in craton "Pretty print all JSON responses from REST API" [Undecided,New] | 18:43 |
| jimbaker | better demos, easier to understand what is going on. trivial refactor. | 18:43 |
| *** VW has quit IRC | 18:47 | |
| *** VW has joined #craton | 18:48 | |
| toan | thomasem: any chance we can meet 1 hr earlier, for the cmdb follow-up mtg? | 19:45 |
| toan | thomasem: i am in EST, i need to cook dinner for the family at that time. I can meet later than that as well. | 19:46 |
| thomasem | toan: That's fine with me. I was picking a time when the most people were available, since it can't work for everyone. | 19:52 |
| thomasem | I can also push to tomorrow | 19:53 |
| thomasem | @toan how's 10am (9am EST) tomorrow sound? | 19:54 |
| thomasem | And then we can go into our sync meeting right after | 19:55 |
| toan | thomasem: jimbaker, sigmavirus, antonym, cloudnull and I stuck around earlier.. with jimbaker's guarantee that craton can do the short term requirements, in short order, we pretty much decide to go with craton... | 19:55 |
| cloudnull | ++ poor cruton :) | 19:56 |
| thomasem | Okay, so do we even need another meeting? | 19:56 |
| toan | so,the follow up mtg may be just for folks to ask question on that decision | 19:56 |
| jimbaker | i agree, that would be helpful | 19:56 |
| thomasem | Is this captured in the Etherpad? | 19:56 |
| * thomasem gets on VPN | 19:56 | |
| cloudnull | im not sure anyone has even read the etherpad | 19:56 |
| jimbaker | expect thomasem to ask these sorts of questions :) | 19:56 |
| thomasem | Lol | 19:56 |
| jimbaker | he keeps us all honest, that's for sure | 19:57 |
| thomasem | cloudnull: I did, at least. | 19:57 |
| toan | so, i might not need to be there... in which case y'all can carry on with the current time for the follow-up mtg | 19:57 |
| cloudnull | thomasem: :) | 19:57 |
| thomasem | cloudnull: so, thank you for participating in the collaborative process. :) | 19:57 |
| * cloudnull read and put things in the etherpad | 19:57 | |
| thomasem | *async* collaborative | 19:57 |
| jimbaker | also i ask that we move as much as possible out of that etherpad into a public etherpad | 19:58 |
| jimbaker | thomasem, async is best. it favors text, and it scales | 19:59 |
| thomasem | jimbaker: I originally thought it was an internal project. So, that's fair, now that I realize it's not. | 19:59 |
| thomasem | I realize it's not - especially. | 19:59 |
| toan | so, thomasem, pls proceed with the meeting later today. i'll listen in while cooking dinner... just like cloudnull was doing cruton while remodeling his bathroom | 19:59 |
| jimbaker | thomasem, yeah, it's an interesting responsibility - we have a rackspace customer, and we are mostly rackers here. but we got to keep it open | 20:00 |
| jimbaker | :) | 20:00 |
| thomasem | That's cool. I'll err on that side going forward. Thanks. | 20:00 |
| jimbaker | thomasem, i think that's everyone's understanding. so it easy to be on that side | 20:01 |
| thomasem | Sounds good to me! | 20:01 |
| thomasem | toan: that sounds good. Sorry. I know this is all because of how urgent the situation is right now. | 20:05 |
| thomasem | Appreciate the flexibility and don't intend for this to be a "thing" going forward, really. :) | 20:06 |
| thomasem | There, updated with context, sent new link | 20:09 |
| thomasem | enjoy | 20:09 |
| sigmavirus | thomasem: ostensibly this afternoon's meetings will maybe discuss what priorities we should be working on | 20:26 |
| thomasem | sigmavirus: if so, they will be recorded. | 20:27 |
| sigmavirus | If y'all can get a set of priorities and document them in clear terms, maybe the rest of us can focus on what we need to do to make them reality | 20:27 |
| thomasem | sigmavirus: Good point. I will enumerate the existing priorities for Craton on that Etherpad and ask that they be prioritized by the stakeholders that are present. | 20:28 |
| jimbaker | thomasem, thanks! | 20:28 |
| thomasem | jimbaker: where's the accompanying bug for https://review.openstack.org/#/c/427032/? | 20:31 |
| jimbaker | thomasem, we need that bug | 20:32 |
| jimbaker | i will add it | 20:33 |
| thomasem | Awesome. Thank you! | 20:33 |
| thomasem | Set all things that are "priority" as of our meeting this morning to "Critical" in LP. | 20:40 |
| thomasem | Current queue at the bottom of https://etherpad.openstack.org/p/cmdb_prototype_meeting_2017_02_09 | 20:41 |
| jimbaker | thomasem, looks good. i will add that new bug to that list | 20:49 |
| thomasem | Excellent, jimbaker! | 20:49 |
| jimbaker | and we can start tracking accordingly | 20:49 |
| thomasem | Should we consider this to be a part of the priorities? https://bugs.launchpad.net/craton/+bug/1662614 | 20:50 |
| openstack | Launchpad bug 1662614 in craton "Allow search by parent_id filter to retrieve all child devices" [High,New] | 20:50 |
| thomasem | I added it, but not sure if that's part of the parent/child stuff as a priority | 20:50 |
| thomasem | If so, we need to assign someone to attack that ASAP. | 20:51 |
| *** Syed__ has quit IRC | 20:55 | |
| jimbaker | thomasem, it's part of the overall work. i suggest it has a common owner | 21:03 |
| jimbaker | so that would be git-harry | 21:03 |
| jimbaker | thomasem, pushed up the latest change in https://review.openstack.org/#/c/432355/ | 21:06 |
| jimbaker | i think we are good now, and i certainly want to get this in so we can move on to the other tasks. i did some additional minor refactoring on the tests so i could extract create_region as a useful resource setup | 21:07 |
| jimbaker | and then apply with the vars stuff | 21:07 |
| jimbaker | at this point, we have 2 files changed and 13 lines changed for functionality to get the DELETE to work as we all expected; and 8 files changed, 192 insertions(+), 89 deletions(-) for the overall work. so diminishing returns i think... | 21:14 |
| *** jovon has quit IRC | 22:02 | |
| cloudnull | i'll be a few min late. | 22:05 |
| cloudnull | joining a 2 | 22:06 |
| *** VW_ has joined #craton | 23:28 | |
| *** VW has quit IRC | 23:32 | |
| *** VW_ has quit IRC | 23:33 | |
| *** VW has joined #craton | 23:38 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!