| === bodie__ is now known as bodie_ | ||
| wwitzel3 | perrito666: thanks :) glad to hear it | 00:34 |
|---|---|---|
| wallyworld | axw: a minute late, just finishing with tim | 02:00 |
| axw | wallyworld: sure, just ping when you're ready | 02:00 |
| axw | I'll go make some tea | 02:00 |
| wallyworld | axw: bring your tea | 02:09 |
| menn0 | thumper: can you have a look at this please? http://reviews.vapour.ws/r/2366/diff/ | 03:01 |
| * thumper looks | 03:02 | |
| menn0 | thumper: i've realised that there's yet one more PR required: for the api package | 03:05 |
| thumper | k | 03:05 |
| menn0 | thumper: even though Juju won't call WatchAllEnvs itself we should probably have it implemented (WatchAll is) | 03:06 |
| menn0 | everything takes too long... | 03:06 |
| thumper | yeah | 03:06 |
| mup | Bug #1339967 changed: juju: cacheAPIInfo uses the wrong tag when storing the environ UUID <tech-debt> <juju-core:Fix Released> <https://launchpad.net/bugs/1339967> | 03:34 |
| mup | Bug #1339967 opened: juju: cacheAPIInfo uses the wrong tag when storing the environ UUID <tech-debt> <juju-core:Fix Released> <https://launchpad.net/bugs/1339967> | 03:40 |
| * thumper heads out to drop down two laptops to the repair person | 03:40 | |
| mup | Bug #1235217 changed: support 1.14 environments without .jenv files <jenv> <tech-debt> <juju-core:Won't Fix> <https://launchpad.net/bugs/1235217> | 03:46 |
| mup | Bug #1339967 changed: juju: cacheAPIInfo uses the wrong tag when storing the environ UUID <tech-debt> <juju-core:Fix Released> <https://launchpad.net/bugs/1339967> | 03:46 |
| mup | Bug #1427505 changed: apiserver/networker: test failure due to map ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Fix Released> <https://launchpad.net/bugs/1427505> | 03:46 |
| mup | Bug #1235217 opened: support 1.14 environments without .jenv files <jenv> <tech-debt> <juju-core:Won't Fix> <https://launchpad.net/bugs/1235217> | 03:52 |
| mup | Bug #1427505 opened: apiserver/networker: test failure due to map ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Fix Released> <https://launchpad.net/bugs/1427505> | 03:52 |
| mup | Bug #1235217 changed: support 1.14 environments without .jenv files <jenv> <tech-debt> <juju-core:Won't Fix> <https://launchpad.net/bugs/1235217> | 04:04 |
| mup | Bug #1427505 changed: apiserver/networker: test failure due to map ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Fix Released> <https://launchpad.net/bugs/1427505> | 04:04 |
| mup | Bug #1484789 opened: add-machine fails with hosted environments <juju-core:New> <https://launchpad.net/bugs/1484789> | 05:44 |
| voidspace | TheMue: if you get a chance, could you look at http://reviews.vapour.ws/r/2360/ | 06:52 |
| TheMue | voidspace: morning, will do now | 07:47 |
| voidspace | TheMue: morning | 07:48 |
| voidspace | thanks | 07:48 |
| TheMue | voidspace: you've got a review | 08:23 |
| mup | Bug #1484833 opened: juju sync-tools fails to complete as environment is not bootstrapped (catch 22 situation!) <juju-core:New> <https://launchpad.net/bugs/1484833> | 08:32 |
| dimitern | any takers for a trivial review? http://reviews.vapour.ws/r/2363/ | 08:48 |
| dimitern | voidspace, dooferlad, TheMue, axw, wallyworld ^^ | 08:51 |
| TheMue | dimitern: *click* | 08:52 |
| dimitern | TheMue, ta! | 08:56 |
| TheMue | dimitern: reviewed | 08:59 |
| voidspace | TheMue: thanks for the review | 08:59 |
| TheMue | voidspace: yw | 08:59 |
| voidspace | dimitern: TheMue: dooferlad: be with you in a few minutes | 08:59 |
| dimitern | voidspace, ok | 09:00 |
| dimitern | TheMue, thanks! | 09:00 |
| TheMue | oh, yes, we're starting now, have to fetch my headset | 09:00 |
| dimitern | voidspace, ping | 09:11 |
| voidspace | dimitern: ome | 09:11 |
| voidspace | *omw | 09:11 |
| === mup_ is now known as mup | ||
| dimitern | voidspace, ping | 11:55 |
| dimitern | voidspace, looking at what was scheduled and agreed to deliver for the MVP, subnet add (rather than create) is expected to land, FWIW | 11:59 |
| dimitern | voidspace, and just space create, and both of subnet|space list - that's it | 12:00 |
| dimitern | (along with constraints ofc) | 12:00 |
| === MerryChristmas is now known as benonsotfware | ||
| === benonsotfware is now known as benonsoftware | ||
| === dooferlad_ is now known as dooferlad | ||
| dooferlad | dimitern, voidspace, TheMue: I am back this afternoon. Will take a look at the CI test reviews I have got and the board to see the new plan. Anything urgent that should take priority? | 12:47 |
| TheMue | dooferlad: ah, you're back, fine. how do you feel? | 12:48 |
| mup | Bug #1484930 opened: Leader's upgrade-charm hook is not run first <juju-core:New> <https://launchpad.net/bugs/1484930> | 12:50 |
| dimitern | dooferlad, awesome! | 12:52 |
| dooferlad | TheMue: a bit foggy, but mostly fine | 12:53 |
| dimitern | dooferlad, if you don't feel well though, better not though | 12:53 |
| dimitern | dooferlad, nothing is *that* important ;) | 12:53 |
| TheMue | dimitern: +1 | 12:53 |
| dooferlad | dimitern: I will stop if I think I need to. I can at least get on with low brain effort tasks. | 12:54 |
| dimitern | dooferlad, only you can know that :) | 12:55 |
| dimitern | dooferlad, I'll leave it to your judgment | 12:56 |
| dooferlad | dimitern: sure, but once you have run out of paid sick days, it sure feels like the company wants you back :-| | 12:56 |
| mup | Bug #1484930 changed: Leader's upgrade-charm hook is not run first <juju-core:New> <https://launchpad.net/bugs/1484930> | 12:57 |
| dimitern | dooferlad, it happens sometimes, but I'm sure we've not gone there yet | 12:59 |
| dooferlad | dimitern: oh, I have run out. | 12:59 |
| dimitern | dooferlad, don't worry about it for now | 13:01 |
| mup | Bug #1484930 opened: Leader's upgrade-charm hook is not run first <juju-core:New> <https://launchpad.net/bugs/1484930> | 13:03 |
| dooferlad | dimitern: why do we want a reference count for state.subnet? We can just perform a simple mgo query to see which spaces are using a subnet (if that is what it is for) | 13:39 |
| dimitern | dooferlad, it's about which subnets have running (etc.) instances | 13:42 |
| dooferlad | dimitern: still sounds like a DB query... | 13:42 |
| voidspace | dooferlad: in which case the relationship between instances and subnets needs to be stored somewhere | 13:43 |
| voidspace | dooferlad: in fact that's true anyway | 13:43 |
| dimitern | voidspace, dooferlad, otp, sorry | 13:45 |
| dooferlad | voidspace: That is what I thought. Seems a shame to add what seems to be a workaround to something that could easily be managed by our single source of truth. | 13:46 |
| voidspace | dooferlad: well, we don't yet have a single source of truth - that's a big part of that card | 13:46 |
| voidspace | dooferlad: references could actually be "list of machine ids" I guess | 13:47 |
| dooferlad | voidspace: that is backwards. Each machine is part of 1+ spaces, so you get the machine document to store the spaces it is in. | 13:48 |
| voidspace | dooferlad: it needs to know subnet, not just space | 13:48 |
| dooferlad | voidspace: then you can query spaces that contain subnets, then machines in those spaces | 13:48 |
| dooferlad | Actually, you are right, you want to store subnets that a machine is in | 13:48 |
| voidspace | dooferlad: that doesn't tell you which machine is using any specific subnet | 13:49 |
| voidspace | right | 13:49 |
| voidspace | I suggested putting it on the machine record, dimitern wasn't so kee | 13:49 |
| dooferlad | then if you move a subnet between spaces you don't need to change anything | 13:49 |
| voidspace | *keen | 13:49 |
| voidspace | he'd have to explain why | 13:49 |
| voidspace | part of it maybe transactional | 13:49 |
| voidspace | dooferlad: our transaction simulation doesn't actually work across collections | 13:50 |
| voidspace | dooferlad: so keeping things like reference count in their own collection avoids some problems | 13:50 |
| voidspace | dooferlad: for IPAddresses we store machineId (and instanceId) on the IPAddress | 13:51 |
| dooferlad | http://blog.labix.org/2012/08/22/multi-doc-transactions-for-mongodb - "Operations may span multiple collections" | 13:51 |
| voidspace | dooferlad: operations can, the transaction guarantees aren't the same I believe | 13:51 |
| voidspace | dooferlad: that's what I was told, although that documentation doesn't seem to agree with it :-) | 13:52 |
| dooferlad | I am going with the documentation. | 13:52 |
| voidspace | dooferlad: good luck :-) | 13:54 |
| voidspace | dooferlad: there maybe another (better) reason to prefer reference counts in their own collection | 13:55 |
| voidspace | dooferlad: and it may or may not apply to storing subnet <-> machine relationships | 13:55 |
| voidspace | not amazingly helpful I realise... but I know fwereade prefers we do that for reference counts at least | 13:56 |
| dooferlad | My problem is this: we have a database. You don't need reference counts if you have the right relations. If you have reference counts you have to work hard to make sure they are right. | 13:56 |
| voidspace | dooferlad: ah, see doc/hacking-state.txt | 13:57 |
| voidspace | dooferlad: the reason for a separate doc is for the sake of watchers | 13:57 |
| voidspace | watchers don't need to be notified when reference count changes and *watching* only works at the whole doc level | 13:57 |
| voidspace | I believe... | 13:58 |
| dimitern | voidspace, dooferlad, instance state != machine life | 13:58 |
| voidspace | dimitern: what does that have to do with it? | 13:58 |
| TheMue | dimitern: quick review of http://reviews.vapour.ws/r/2369/ ? isn't complex | 13:59 |
| dimitern | voidspace, dooferlad, that's why we need a refcount + txn.Ops on it to avoid removing subnets in use | 13:59 |
| dimitern | (even if no instance are yet/anymore running on it) | 13:59 |
| voidspace | dimitern: we're not proposing anything to do with instance state | 13:59 |
| voidspace | dimitern: we're saying that we need to store machine ids using subnets *anyway* | 13:59 |
| dimitern | TheMue, sure, looking in a moment | 14:00 |
| voidspace | dimitern: in which case a subnet is in use if the number of alive machines using it > 0 | 14:00 |
| voidspace | dimitern: so you don't need a reference count, you count alive machines | 14:00 |
| voidspace | dimitern: using the db | 14:00 |
| dimitern | voidspace, you can't store machine ids that don't exist yet though | 14:00 |
| voidspace | dimitern: isn't the machine id created straight away? | 14:01 |
| voidspace | dimitern: it's instance id that is created later | 14:01 |
| dimitern | voidspace, i.e. as a side-effect or provisioning with space constraints | 14:01 |
| voidspace | dimitern: as soon as you provision with contraints a machine will be created, right? and I don't know what you mean by "side-effects" | 14:02 |
| voidspace | dimitern: picking a subnet is part of provisioning - i.e. part of machine record creation | 14:02 |
| dimitern | voidspace, I mean a service's space requirements indirectly should keep its subnets in state | 14:02 |
| voidspace | dimitern: a service constraint for undeployed services won't keep any specific subnets in use | 14:03 |
| dimitern | voidspace, and by requirements I realize constraints are a bad example (except maybe in environment constraints) | 14:03 |
| katco | natefinch: standup | 14:03 |
| dimitern | voidspace, but for bindings of a service | 14:03 |
| dimitern | voidspace, once we have them (that was the intent behind --networks) | 14:03 |
| voidspace | dimitern: in which case we add the machine id to all subnets they are "using" | 14:04 |
| dimitern | voidspace, so even if we avoid adding refcounts and use machineIds-to-subnets, we'll need it pretty soon | 14:04 |
| voidspace | I don't think so | 14:04 |
| voidspace | we *still* need to do that, even if we use reference counting - so that we could decrement | 14:04 |
| dimitern | (and not having it will keep the subnet up *until* the dead machine doc is in state) | 14:04 |
| voidspace | (by that I mean - store machine id) | 14:05 |
| voidspace | dimitern: in order to decrement properly you have to store somewhere the machine id referencing subnets | 14:05 |
| voidspace | dimitern: agreed? | 14:05 |
| dimitern | voidspace, ok, first, I absolutely agree we need to be able to link machines to subnets (many-to-many) | 14:05 |
| voidspace | even if it's an "implicit" reference as you describe | 14:05 |
| voidspace | dimitern: and if we have that link then the reference count *must* equal the number of links | 14:06 |
| voidspace | so the reference count is always redundant | 14:06 |
| dimitern | voidspace, and the original and perhaps not great model was to use machine's NICs (which have subnets) for that | 14:06 |
| voidspace | dimitern: ok, that sounds good - we can do that | 14:06 |
| voidspace | any reason not to? | 14:06 |
| voidspace | we have those in state already | 14:06 |
| dimitern | voidspace, nope - refcount shouldn't stop you from removing a subnet referenced only by non-alive machines | 14:07 |
| dimitern | voidspace, the only reason not too (not a good one) is we'll need to update (add) NICs too | 14:07 |
| voidspace | right | 14:08 |
| voidspace | NICs are already added by container address allocation | 14:08 |
| voidspace | yeah, adding NICs on machine creation is non-zero amount of work :-/ | 14:08 |
| dimitern | complexity, which can be avoided by a machineSubnetsC for the time being | 14:08 |
| dooferlad | why do we need subnets --> machines? Again, this is a query. | 14:08 |
| voidspace | dooferlad: in order to determine if the subnet is in use | 14:09 |
| dimitern | dooferlad, that's what we're discussing | 14:09 |
| alexisb | ericsnow, I moved our 1x1 to monday so that you can focus on moonstone planing | 14:09 |
| voidspace | dooferlad: so you can tell if it is safe to move the subnet to a different space or remove it altogether (we have a subnet remove command) | 14:09 |
| dimitern | dooferlad, to be able to do that query, you need less data than to ensure it stays like this during an multi-op insert | 14:09 |
| dooferlad | dimitern: ah, interesting. *thinks* | 14:10 |
| voidspace | dooferlad: or are you saying "subnets --> machines" is a query. In which case a query of *what*, that information doesn't exist unless we store it. | 14:10 |
| ericsnow | alexisb: thanks! | 14:10 |
| dooferlad | voidspace: I get that, but it feels like you should store in the machine document, what subnets it is part of. | 14:11 |
| dimitern | dooferlad, yeah, mongo makes trivial design discussions so much spicier :D | 14:11 |
| dooferlad | then everything flows from that | 14:11 |
| dimitern | dooferlad, preferably not on the machine document | 14:11 |
| dooferlad | well, wherever the machines network information is. I don't have that in my head yet and need to look it up. | 14:12 |
| voidspace | dimitern: why not? (out of interest) | 14:13 |
| dimitern | dooferlad, voidspace, having it there means any change to it potentially triggers a lot of watchers and workers | 14:13 |
| dooferlad | I think my argument is that if you have x is a member of y, you should be able to determine that by x storing that it is a member of y. If you store that y has x, y, z as members then if x goes away you need to update that membership list. | 14:13 |
| voidspace | dimitern: but it doesn't change after machine creation | 14:13 |
| dimitern | dooferlad, voidspace, it changes rarely, but always significantly | 14:13 |
| voidspace | dimitern: when does it change? | 14:14 |
| dimitern | dooferlad, voidspace, e.g. when space membership changes or subsequent deployments | 14:14 |
| voidspace | dimitern: space membership of a *machine*? | 14:14 |
| voidspace | dimitern: how is that possible | 14:14 |
| dimitern | dooferlad, voidspace, you deploy another service from a different space on the same machine | 14:15 |
| voidspace | dimitern: and if it's significant *shouldn't* watchers be triggered... | 14:15 |
| voidspace | dimitern: which would require adding an extra NIC, which we won't support initially | 14:15 |
| voidspace | dimitern: I believe | 14:15 |
| voidspace | or can you bind multiple subnets to the default NIC on an EC2 instance? | 14:15 |
| dimitern | dooferlad, voidspace, that brings a new NIC on a subnet in that other space, triggers a lot of address and other changes already | 14:15 |
| voidspace | the *right* thing to do is to use NICs to model this | 14:16 |
| voidspace | so maybe we should do that | 14:16 |
| dooferlad | voidspace: you don't need physical NICs to have >1 IP address (or addressable containers wouldn't work). I wouldn't worry about physical interfaces (or anything that looks like them) | 14:16 |
| voidspace | dooferlad: EC2 has a concept of a NIC and different instance types have a maximum number of supported NICs | 14:17 |
| dimitern | voidspace, it's not a change of the machine itself (as juju sees it) - exactly like and why we're not storing what services we deploy to a machine | 14:17 |
| voidspace | dooferlad: and a max number of IP per NIC | 14:17 |
| dooferlad | voidspace: yes, I know | 14:17 |
| dimitern | (only indirectly from their units) | 14:17 |
| voidspace | dooferlad: I think only one subnet per NIC, I may be wrong | 14:17 |
| voidspace | dooferlad: I'm not worrying about physical NICs :-) | 14:18 |
| dimitern | dooferlad, I know - that's yet to be decided (the model expects 1-nic-per-space on machines) | 14:18 |
| voidspace | dooferlad: I'm worrying about modelling machines on multiple spaces in EC2 | 14:18 |
| dooferlad | voidspace: That EC2 specific logic should be in one tidy place. It is a restriction on what we can do, not an addition. | 14:18 |
| dimitern | with one-nic-multiple-ips some things will be simpler, but impossible on EC2 | 14:18 |
| voidspace | dooferlad: well, sure | 14:19 |
| voidspace | we seem to have sidelined from the main discussion | 14:19 |
| voidspace | we have a model of NICs in state already | 14:19 |
| voidspace | NICs hold the relationship between subnets and machines | 14:19 |
| dooferlad | indeed. back to the point... | 14:19 |
| voidspace | so they seem like the right level of abstraction for what we need | 14:20 |
| voidspace | and they conveniently match what we're trying to model anyway... | 14:20 |
| dooferlad | sounds good :-) | 14:20 |
| dimitern | dooferlad, voidspace, it's not just EC2 specific, but AWS is an important target | 14:20 |
| dooferlad | dimitern: I completely agree. We just need to make sure that EC2 is a subset, not some blob on the side. | 14:21 |
| voidspace | yeah, our model needs to *work* on EC2 - just not necessarily be entirely bound by it's limitations | 14:21 |
| dimitern | and NIC in juju terms is more like a linux device than a Elastic Network Interface | 14:21 |
| dimitern | dooferlad, of course, we started from the free-for-all openstack model and AWS restrictions constrained the model in a few ways, but made it better in others | 14:22 |
| dooferlad | so, we have IPAddress. That contains a SubnetId and a MachineId. So, we can find all the IPAddress documents that reference a SubnetId before we delete it and use that as the reference count, right? | 14:26 |
| voidspace | dooferlad: IPAddress is only used for "container address allocation" | 14:27 |
| voidspace | dooferlad: not (yet) as a general IPAddress store | 14:27 |
| dooferlad | erk | 14:27 |
| dooferlad | well, that is horrid. | 14:27 |
| voidspace | because it's only for containers that we specifically allocate an address (if the feature flag is on) | 14:27 |
| voidspace | we get them automatically for machines | 14:27 |
| dooferlad | what do we use for machines? | 14:28 |
| voidspace | so no need to request or model them | 14:28 |
| dooferlad | to store them that is | 14:28 |
| voidspace | well, to work out which is the current public/private address for a machine we spit on our finger and stick it in the wind | 14:28 |
| voidspace | which is why we have all sorts of bugs around the private/public address of machines appearing to change... | 14:28 |
| dooferlad | machineDoc has two slices of IP addresses. | 14:29 |
| voidspace | (we ask the machine OS and the provider what addresses it thinks it has and report those - holding them on the machineDoc) | 14:29 |
| voidspace | right | 14:29 |
| dooferlad | but no CIDRs | 14:29 |
| dooferlad | great | 14:29 |
| dooferlad | oh, hang on... | 14:30 |
| voidspace | we have a bug we have to fix reqarding machine IP addresses apparently changing | 14:30 |
| voidspace | have to fix *soon* | 14:30 |
| voidspace | so moving to a model that actually works would be better | 14:30 |
| dooferlad | the address struct that machine uses could become ipaddressDoc. | 14:31 |
| dooferlad | that would make life easier... | 14:31 |
| dooferlad | then we use that plus a list of machines not yet provisioned that have been allocated a subnet | 14:32 |
| dooferlad | which I assume is generated from another query looking at constraints | 14:33 |
| dooferlad | (assuming we can't just look at constraints) | 14:33 |
| natefinch | katco: dang.... somehow my copy of the link failed, can you re-paste? | 14:53 |
| TheMue | dooferlad: dimitern: thx for reviews. the whitebox test does not rely on BaseSuite, so no PatchValue() this time. | 14:56 |
| mup | Bug #1484993 opened: TestBootstrapReusesAffinityGroupAndVNet: no tools are available for your environment <blocker> <ci> <i386> <ppc64el> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1484993> | 14:57 |
| mup | Bug #1484993 changed: TestBootstrapReusesAffinityGroupAndVNet: no tools are available for your environment <blocker> <ci> <i386> <ppc64el> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1484993> | 15:00 |
| mup | Bug #1484993 opened: TestBootstrapReusesAffinityGroupAndVNet: no tools are available for your environment <blocker> <ci> <i386> <ppc64el> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1484993> | 15:03 |
| dimitern | TheMue, you can still call it from juju/testing | 15:06 |
| dimitern | TheMue, at least it does the same thing | 15:07 |
| TheMue | dimitern: will have a look, thought it's a method of an embedded type, which isn't used here | 15:09 |
| TheMue | dimitern: in the moment the patched attempt strategie like you said by PatchAttemptStrategies isn't working | 15:09 |
| dimitern | TheMue, it is a method of BaseSuite via CleanupSuite, which calls PatchValue inside | 15:09 |
| TheMue | dimitern: so I would have to embed the CleanupSuite into the whole suite only for this one patching of a variable I directly have access to | 15:11 |
| dimitern | TheMue, what a moment | 15:11 |
| TheMue | dimitern: will see how the side effects are | 15:11 |
| dimitern | TheMue, s/wait/ | 15:11 |
| TheMue | yep | 15:11 |
| dimitern | TheMue, environSuite (in whitebox test) uses PatchValue already | 15:11 |
| TheMue | the whitebox tests are a bit ... different ;) | 15:11 |
| dimitern | TheMue, the other environSuite (non-whitebox one) directly embeds BaseSuite | 15:12 |
| dimitern | looking provider/maas on master | 15:12 |
| TheMue | so, back, just had phone, sorry | 15:15 |
| TheMue | dimitern: yeah, for the non-wb I've seen, but missed it here | 15:16 |
| dimitern | TheMue, whitebox tests effectively use providerSuite, which already uses PatchValue as it embeds CleanupSuite via Fake(Juju)HomeSuite | 15:19 |
| TheMue | dimitern: yes, deep nested embedding, almost like the "good" old OOP | 15:20 |
| dimitern | TheMue, luckily rogpeppe's godef is amazing for navigating deeply nested types | 15:21 |
| TheMue | dimitern: have to see how I can integrate it into my editor macros | 15:22 |
| dimitern | TheMue, +1 | 15:23 |
| voidspace | right EOW | 15:23 |
| voidspace | happy weekend everyone | 15:23 |
| TheMue | dimitern: hehe, this bad foo == 5, gc.Equals, true is a leftover from some former approaches | 15:24 |
| TheMue | dimitern: PatchValue works fine now | 15:25 |
| TheMue | dimitern: even optimised it using variables for retries and enoughRetries to patch it only once, final problem is now the strategies patching | 15:28 |
| dimitern | TheMue, great! | 15:28 |
| dimitern | TheMue, just use PatchValue for the strategies | 15:30 |
| TheMue | dimitern: yep, thought the same | 15:30 |
| dimitern | TheMue, patching it once and using a retries chan for reporting back | 15:31 |
| mup | Bug #1485013 opened: MgoSuite tests must be run with MgoTestPackage <ci> <intermittent-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1485013> | 15:33 |
| mup | Bug #1485017 opened: add the ability to open terminal in hook context <juju-core:New> <https://launchpad.net/bugs/1485017> | 15:33 |
| TheMue | dimitern: hmm, think it's more simple now, will push it so that you can have a final look | 15:33 |
| TheMue | dimitern: so, updated | 15:35 |
| dimitern | TheMue, looking | 15:35 |
| TheMue | dimitern: thx for review, will now merge it | 16:08 |
| dimitern | TheMue, go for it | 16:09 |
| TheMue | dimitern: I added the cards for dummy, maas and ec2. the original one is still there, I grouped them at the end of the lane, so you'll easier find them. I also change the "master card" to a user story, the points are still in there. IMHO these have to be removed due to the points on the individual cards now. | 16:34 |
| * TheMue grumbles, has branch cannot land due to a fix blocker *sigh* | 16:35 | |
| alexisb | TheMue, you could fix it ;) | 16:35 |
| TheMue | alexisb: hehe, sure, but then I have to fix my wife too | 16:36 |
| alexisb | I assigned it to Ian because it is his PR that caused the regression but really it is up for anyone to fix that is affected by the block | 16:36 |
| alexisb | heh understood | 16:36 |
| alexisb | it is friday evening :) | 16:36 |
| TheMue | alexisb: yep, but sill will have a look | 16:37 |
| dimitern | TheMue, got it, thanks! | 16:43 |
| TheMue | dimitern: yw | 16:43 |
| mup | Bug #1485071 opened: juju deploy and add-machine not installing agent <juju-core:New> <https://launchpad.net/bugs/1485071> | 18:27 |
| katco | ericsnow: wwitzel3: sorry, also forgot we have to take care of this bug: https://canonical.leankit.com/Boards/View/114568542/116652767 | 19:38 |
| wwitzel3 | oh right | 19:40 |
| natefinch | ericsnow: what do you want to do about the problem with my untrack code and ids that could conflict if they're for different workload types? | 20:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!