| davecheney | ping, anyone OCR today ? http://reviews.vapour.ws/r/4040/ | 00:32 |
|---|---|---|
| davecheney | thumper: i'm currently seeing 1 in 3 landing attempts fail because mongo crashes with the usual bad mac error | 00:34 |
| anastasiamac | davecheney: OCRs today according to Juju Team calendar r Andrew and Eric | 00:35 |
| davecheney | cmars: thanks | 00:39 |
| thumper | davecheney: I'm hoping that RSN we will just have mongo 3 where they have fixed that | 00:50 |
| mup | Bug #1552469 opened: Credentials are not utilised when creating a hosted model <docteam> <juju-core:New> <https://launchpad.net/bugs/1552469> | 00:53 |
| davecheney | thumper: menn0 https://github.com/juju/juju/pull/4611 | 01:06 |
| davecheney | as we talked about yesterday | 01:06 |
| davecheney | this is part 1 of 2 | 01:06 |
| davecheney | to make sure that the apiserver knows all the ways we say that we're in upgrade state | 01:07 |
| davecheney | and can convert all of them to the right ErrorCode | 01:07 |
| thumper | done | 01:09 |
| menn0 | davecheney: your PR makes me cringe | 01:19 |
| menn0 | davecheney: can we not have a well defined "upgrade in progress" error in state | 01:19 |
| menn0 | davecheney: which the apiserver knows how to convert to it's "upgrade in progress" error? | 01:20 |
| menn0 | davecheney: the reason for state returning "upgrade in progress" are quite different from the error returned by the apiserver. | 01:23 |
| menn0 | davecheney: the upgrade in progress error from state is about an attempt to start an upgrade failing because an upgrade is already in progress | 01:24 |
| menn0 | davecheney: maybe it should just be a different error? | 01:25 |
| davecheney | menn0: i agree | 01:32 |
| davecheney | it's a disaster | 01:32 |
| davecheney | to be clear, I'm not going to pass state.errUpgradeInProgreess up | 01:32 |
| davecheney | but there are a bunch of "helper" (using that term very loosely) methods in apiserver/common/errors.go that translate one to the other | 01:32 |
| perrito666 | Uh big +1 to that | 01:36 |
| === bogdanteleaga_ is now known as bogdanteleaga | ||
| === natefinch_ is now known as natefinch | ||
| === _stowa_ is now known as _stowa | ||
| === bcsaller_ is now known as bcsaller | ||
| thumper | wallyworld: hey | 03:27 |
| === meetingology` is now known as meetingology | ||
| wallyworld | hi | 03:27 |
| === mup_ is now known as mup | ||
| thumper | wallyworld: got 5 min for a quick chat? | 03:27 |
| wallyworld | sure | 03:27 |
| thumper | 1:1 | 03:27 |
| === marlinc_ is now known as marlinc | ||
| mup | Bug #1552523 opened: Unable to deploy a wily or precise service with MAAS <maas> <network> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1552523> | 03:41 |
| === bradm_ is now known as bradm | ||
| wallyworld | anastasiamac: you'll hate me, but i'd love a review when you get a moment http://reviews.vapour.ws/r/4052/ | 04:32 |
| anastasiamac | wallyworld: i won't hate u fo asking so nicely :D | 04:33 |
| wallyworld | wait till you see the code :-) | 04:33 |
| wallyworld | anastasiamac: sorry :-( another one if you have time http://reviews.vapour.ws/r/4053/ | 07:03 |
| anastasiamac | wallyworld: sure, m hald way thru the 1st... then will look at this one \o/ | 07:03 |
| wallyworld | yay, ty | 07:03 |
| mup | Bug #1552589 opened: TestProvisionerObservesMachineJobs fails intermittently <intermittent-failure> <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1552589> | 07:54 |
| fwereade | anyone free to talk me through the space-discovery login synchronisation a bit? | 08:39 |
| fwereade | frobware, dooferlad_? | 08:40 |
| fwereade | actually brb but ping me if you know it | 08:41 |
| jam | quick review: https://github.com/juju/juju/pull/4614 | 08:50 |
| fwereade | jam, ship it -- the notification is yucky in the first place but it's not worth a rewrite to fix | 08:52 |
| fwereade | frobware, dooferlad_ : in particular, ISTM that: it runs per-model but limits logins for everything; but works around that by only limiting logins until the first one that runs reports completion; but subverts *that* by always marking completion even when there's an error | 09:03 |
| fwereade | frobware, dooferlad_ : any insights? | 09:03 |
| fwereade | frobware, dooferlad_ : in particular my understanding is that this *is* only critical for the controller model (especially given that it's ineffective for later ones): can you think of a reason for me not to move it to the per-controller bit rather than the per-model bit? | 09:08 |
| fwereade | frobware, dooferlad_ : ah, I'll ask voidspace | 09:09 |
| voidspace | fwereade: ask me what... :-) | 09:12 |
| fwereade | voidspace, huh, thought I'd PMed you to avoid spam | 09:13 |
| voidspace | ah, you have I just didn't notice | 09:13 |
| === dooferlad_ is now known as dooferlad | ||
| dooferlad | voidspace, fwereade, jam: standup? | 10:01 |
| === Odd_Blok1 is now known as Odd_Bloke | ||
| voidspace | dooferlad: frobware: just finishing a chat with fwereade - be right there | 10:02 |
| frobware | voidspace: dooferlad: http://reviews.vapour.ws/r/4055/ | 10:11 |
| perrito666 | morning all | 11:03 |
| voidspace | frobware: you still need that review? | 12:06 |
| frobware | voidspace: yes please | 12:06 |
| voidspace | frobware: can you explain to me the change in provider/maas/environ.go | 12:10 |
| voidspace | frobware: it's relatively esoteric | 12:10 |
| frobware | voidspace: when the container starts it has no gateway, so it can start but can't do anything real. | 12:11 |
| voidspace | frobware: doesn't setting juju_bridge_all_interfaces=0 make the code immediately following unroutable | 12:11 |
| voidspace | frobware: yeah, that's the bug - I mean what do the changes do specifically? | 12:12 |
| frobware | voidspace: we know the bridge-device the container is connected to (the param in the call) so we find the IP address for that specific device and make it the gateway | 12:12 |
| voidspace | (I may have interrupted - sorry if so) | 12:12 |
| voidspace | what does this do? uju_networking_preferred_python_binary %[1]q --bridge-prefix=%[2]q --one-time-backup --activate %[4]q | 12:12 |
| voidspace | and: | 12:13 |
| voidspace | juju_ipv4_interface_to_bridge=$(ip -4 route list exact default | head -n1 | cut -d' ' -f5) | 12:13 |
| voidspace | dammit | 12:13 |
| frobware | voidspace: ah, sorry. I was talking about the wrong file. :) | 12:13 |
| frobware | voidspace: first bit, bridges all interfaces with the specified bridge prefix, in our case 'br-' | 12:13 |
| voidspace | frobware: line 1046 in provider/maas/environ.go | 12:14 |
| voidspace | frobware: won't juju_bridge_all_interfaces always be 0? | 12:14 |
| frobware | voidspace: yes, I did that deliberately because if we merge this back from master into maas-spaces2 we should make that 1 in our branch. So, rather than continuously futzing with the changes we can choose the behaviour we want by specifiying 0 or 1. | 12:15 |
| voidspace | frobware: ah... cool | 12:15 |
| frobware | voidspace: the 0 behaviour is what we want on 1.25 too | 12:16 |
| frobware | voidspace: so the if .. else ... serves as an example of how to drive the script for bridging all interfaces or just a specific interface. | 12:16 |
| frobware | voidspace: I can add a comment for this behaviour. | 12:18 |
| voidspace | frobware: yeah, that would be cool | 12:18 |
| voidspace | frobware: not possible to test? | 12:21 |
| frobware | voidspace: in terms of bridging all or a specific one? | 12:25 |
| voidspace | frobware: the change has no test | 12:25 |
| frobware | voidspace: there are existing tests cases that exercise the all or one behaviour. | 12:25 |
| frobware | voidspace: this is a runtime thing... which I think is difficult to test in any meaningful way. Where & how would we bring interfaes up/down? | 12:26 |
| voidspace | frobware: well, the finding of the ipv4 address should be testable with some mocking (the discoveryIPv4InterfaceAddress path) | 12:26 |
| frobware | voidspace: ah, that one. | 12:27 |
| frobware | voidspace: true. | 12:27 |
| frobware | voidspace: it's a tradeoff though. this would disappear once we merge maas-spaces2. | 12:27 |
| voidspace | frobware: you want to land it untested? | 12:28 |
| frobware | voidspace: it's been live tested | 12:28 |
| voidspace | frobware: heh, ok | 12:28 |
| frobware | voidspace: let me think about it a bit... | 12:28 |
| voidspace | frobware: it will live on in 1.25 | 12:29 |
| frobware | voidspace: nope, master only. | 12:29 |
| voidspace | ah, ok | 12:29 |
| frobware | voidspace: and, again, only for as long as we don't merge maas-spaces2 | 12:29 |
| voidspace | frobware: you have my LGTM with a comment about the missing test | 12:29 |
| frobware | voidspace: ironically, the unit tests did not highlight that there would be a live failure. | 12:29 |
| frobware | voidspace: https://bugs.launchpad.net/juju-core/+bug/1549545/comments/8 | 12:30 |
| mup | Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created <ci> <deploy> <maas-provider> <test-failure> <juju-core:In Progress by frobware> <https://launchpad.net/bugs/1549545> | 12:30 |
| voidspace | yeah, I saw | 12:32 |
| voidspace | :-/ | 12:32 |
| voidspace | basically impossible to unit test all possible networking scenarios | 12:32 |
| voidspace | frobware: I found out why my tests were failing in a weird way | 12:34 |
| voidspace | frobware: the maas provider caches the result of checking if spaces are supported on creation | 12:34 |
| voidspace | frobware: so setting the capabilities after creating the provider has no effect - you have to do it first | 12:34 |
| voidspace | down to 3 failures now | 12:35 |
| frobware | heh | 12:35 |
| === lazypower_ is now known as lazyPower | ||
| fwereade | voidspace, hmm, how does discoverspaces work in an HA environment? | 14:50 |
| fwereade | voidspace, it's in the singular runner, so... will logins ever be unblocked for non-master controllers? | 14:51 |
| === rcj` is now known as rcj | ||
| fwereade | voidspace, ah, ok, it will, but only because it's not blocked until we start the worker... which surely implies that logging in after that point is a matter of luck? | 14:57 |
| fwereade | voidspace, I'm starting to think it's impossible without a persistent flag..? and I was really hoping not to have to change the apiserver. ah well | 15:11 |
| === icey_ is now known as icey | ||
| voidspace | fwereade: :-( | 15:17 |
| voidspace | back shortly, picking up the daughter from school | 15:18 |
| voidspace | fwereade: (not a matter of luck as you bootstrap one machine - which does discovery and is blocked - and then you go HA.) | 15:21 |
| fwereade | voidspace, what ensures that the client won't connect after the apiserver starts but before the discoverspaces worker starts? | 15:34 |
| frobware | dooferlad: ping | 15:45 |
| dooferlad | frobware: pong | 15:46 |
| frobware | dooferlad: can you junp into sapphire HO? | 15:46 |
| dooferlad | frobware: sure | 15:46 |
| voidspace | fwereade: so, nothing stops login before the discoverspaces worker has startedc | 16:19 |
| voidspace | fwereade: the intention of blocking logins was that bootstrap be synchronous so that spaces are available immediately after bootstrap completes | 16:19 |
| voidspace | fwereade: non-master HA controllers never unblocking sounds scary | 16:21 |
| voidspace | fwereade: although it shouldn't happen - as it's in a singular runner the worker shouldn't be started on non-master | 16:22 |
| voidspace | fwereade: and login is only blocked if the worker is started (the channel is set the first time the worker is started) | 16:22 |
| fwereade | voidspace, right; so, how do we prevent the bootstrapping client from logging in before the discoverspaces worker is started? | 16:25 |
| voidspace | fwereade: hmm... that might explain a bug that frobware has seen that I haven't (bootstrap completing and *then* login being blocked) | 16:26 |
| voidspace | fwereade: I've never seen it, but it's obviously timing related | 16:26 |
| fwereade | voidspace, yeah, there's nothing stopping that afaict | 16:26 |
| voidspace | there isn't, setting the channel before the worker is started would be problematic for non-master HA | 16:26 |
| voidspace | fwereade: are you sure you don't want me to own fixing this? | 16:29 |
| fwereade | voidspace, yeah; and I'm not entirely willing to be certain that we can't have problems if we manage to bring up extra controllers without waiting | 16:29 |
| voidspace | we need a different way of doing this | 16:30 |
| fwereade | voidspace, still think it's my problem really -- I'm trying to get my dependency-engine update of startEnvWorkers in | 16:30 |
| voidspace | fwereade: maybe remove the blocking altogether until menno's work is done and then re-introduce | 16:30 |
| voidspace | fwereade: that's only nearly as bad as just doing it for the controller and not per-model | 16:31 |
| fwereade | voidspace, ...that's terribly tempting actually | 16:31 |
| voidspace | fwereade: if it has to be fixed anyway | 16:31 |
| fwereade | voidspace, ok, I will try just dropping the notification for now and see where it takes me | 16:34 |
| fwereade | voidspace, thanks | 16:34 |
| fwereade | voidspace, I'll let you know where I end up | 16:34 |
| voidspace | fwereade: cool | 16:35 |
| perrito666 | bbl | 16:39 |
| katco | natefinch: hey can you join us in moonstone rq? | 17:01 |
| mup | Bug #1552804 opened: worker/metrics: intermittent data race <ci> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1552804> | 17:01 |
| frobware | cherylj: is bootstrapping xenial a gating issue for 1.25.4? | 17:04 |
| cherylj | frobware: yes, I would say so. It came up in the cross team call today | 17:04 |
| cherylj | frobware: what are you finding? | 17:04 |
| frobware | cherylj: that seems odd to me as you have to use daily images (i think) and there's a lot of shifting sand if you do that. | 17:05 |
| frobware | cherylj: I've possibly spent a large part of the day looking at a non problem but last comment in bug #1550306 shows a correlation of xenial cloud-init failing and bootstrap failing | 17:06 |
| mup | Bug #1550306: 1.25.3 can't bootstrap xenial environments <landscape> <juju-core:Fix Committed by frobware> <juju-core 1.25:In Progress by frobware> <https://launchpad.net/bugs/1550306> | 17:06 |
| cherylj | :( | 17:07 |
| cherylj | frobware: I'm still trying to get xenial images on my vmaas to test. The controller ran out of disk space | 17:07 |
| frobware | cherylj: the issues I saw with /e/n/i yesterday have definitely gone with today's images as /e/n/i is rendered differently. bad timing perhaps. or the curse of shifting sand. | 17:07 |
| frobware | cherylj: I'm still surprised we would consider 1.25.4 x a-daily-build-of-xenial something that is gating. | 17:08 |
| frobware | cherylj: as I've seen in the last 24 hours, daily images change... | 17:08 |
| cherylj | frobware: If we can confirm that it is a problem with xenial, I think we could release and point to whatever bug we've opened against xenial cloud images | 17:09 |
| bogdanteleaga | how do I get rid of all the params redacted thingie in logs? | 17:09 |
| cherylj | bogdanteleaga: to see the redacted params? | 17:09 |
| bogdanteleaga | yeah | 17:09 |
| cherylj | bogdanteleaga: set logging level to trace | 17:09 |
| cherylj | it will show you the contents | 17:10 |
| frobware | cherylj: I haven't gone beyond bootstrapping today, but with the bridge script fix for xenial (1550306) I can still bootstrap with precise, trusty and wily. | 17:10 |
| cherylj | frobware: can you deploy? | 17:10 |
| frobware | cherylj: kinda run out of time now... :( | 17:10 |
| bogdanteleaga | cherylj, thanks that did it :) | 17:11 |
| natefinch | rick_h__: I assume the charmstore should have the same contract about push-resource matching the extension? | 17:13 |
| katco | natefinch: ping? | 17:13 |
| natefinch | katco: yo | 17:13 |
| katco | natefinch: must have missed my previous ping ;p | 17:13 |
| katco | natefinch: join us in moonstone? | 17:13 |
| natefinch | katco: oh, crap, sorry | 17:13 |
| katco | natefinch: lol nw | 17:13 |
| natefinch | katco: new IRC client is totally screwing me up | 17:13 |
| rick_h__ | natefinch: yes | 17:25 |
| mup | Bug #1552815 opened: ability to apply profile/config modifications to lxd containers <juju-core:New> <https://launchpad.net/bugs/1552815> | 17:31 |
| mattyw | katco, ping? | 17:45 |
| katco | mattyw: pong | 17:48 |
| mattyw | katco, hey hey, pinging you as I thought you might have good intuition on this: when I come to destroy controllers I normally forget the name I've given them. I reckon juju status should tell you the name of the controller (and also maybe the model) it's displaying the status of. What do you think? | 17:50 |
| katco | mattyw: hm | 17:50 |
| katco | mattyw: that seems reasonable to me... maybe like a header at the beginning of status? | 17:50 |
| katco | mattyw: especially in a world where you might be flipping between models very often | 17:51 |
| mattyw | katco, yeah, what more or less exactly what I was thinking | 17:51 |
| katco | mattyw: the name of the controller may not carry it's weight since there will likely only ever be 1? what do you think? | 17:51 |
| mattyw | katco, I don't know, I think it would be useful to display it, even if it's only one, since the user has named it | 17:53 |
| katco | mattyw: i mean i'd be fine with it. it's not like it would take up a lot of space | 17:53 |
| mattyw | katco, I'll do it, and see how it looks | 17:53 |
| katco | mattyw: cool | 17:53 |
| mattyw | katco, wanted to get some initial feedback to check it wasn't a totally insane idea | 17:54 |
| mattyw | katco, so thanks | 17:54 |
| katco | mattyw: hth | 17:54 |
| perrito666 | back | 18:38 |
| natefinch | ericsnow: wondering if ListResources in the charmstore should be ResourceMeta, to match Meta about charms | 18:38 |
| ericsnow | natefinch: we need all the info about the resources, not just the meta portion | 18:38 |
| natefinch | ericsnow: it's all meta, except the bytes | 18:39 |
| ericsnow | natefinch: "meta" means the resource info from the charm metadata | 18:39 |
| ericsnow | natefinch: a la resource.Resource vs. resource.Meta | 18:39 |
| natefinch | ericsnow: in the charm package, sure. It could have a different meaning in the charmstore... | 18:41 |
| natefinch | ericsnow: we are calling id/meta/resources after all | 18:41 |
| ericsnow | natefinch: naming conflicts aside, ListResources() needs to return the full resource.Resource from the charm store | 18:42 |
| natefinch | ericsnow: resource.Resource is all the metadata about the resource :) (metadata -> everything except the data-data, i.e. the bytes) | 18:42 |
| ericsnow | natefinch: okay | 18:43 |
| natefinch | ericsnow: anyway, I was just trying to keep with the conventions already there. It's fine by me if we use ListResources | 18:44 |
| ericsnow | natefinch: oh, this is not a match to charm Meta | 18:44 |
| ericsnow | natefinch: it is the resource "meta" plus the other things that resource.Resource adds | 18:45 |
| natefinch | ericsnow: I'm just talking about the function name to wrap the call to id/meta/resources | 18:45 |
| ericsnow | natefinch: so more like the charm store's "entity" | 18:45 |
| natefinch | ericsnow: as an aside, I think the charm/resource.Meta name was a mistake, since it's all metadata... that's possible more accurately called the resource definition (as defined in the metadata.yaml)... | 18:46 |
| ericsnow | natefinch: there isn't an equivalent ListCharms on the client; I'd say let's stick with ListResources() | 18:46 |
| natefinch | ericsnow: that's fine | 18:46 |
| ericsnow | natefinch: hmm, I believe I originally called it Definition and someone pushed for Meta instead | 18:47 |
| ericsnow | natefinch: (maybe remembering something else) | 18:47 |
| natefinch | ericsnow: I remember something about definition too... not sure if that was this or payloads or what | 18:47 |
| jcastro | jam: you're currently working on lxd/juju right? | 19:58 |
| alexisb | jcastro, he is but is out for the day | 20:01 |
| jcastro | ok so maybe you can help | 20:01 |
| jcastro | the new lxd landed in ubuntu, so now I need to update the instructions: https://jujucharms.com/docs/master/config-LXD | 20:02 |
| jcastro | since lxd-images is being deprecated | 20:02 |
| jcastro | the nice bit is that lxd now includes the remotes for the images built in, so doing like `lxc launch ubuntu:14.04 my-test-container` Just works ootb. | 20:02 |
| jcastro | my question is, will we need this step at all in our instructions or if the lxd provider will just snag the image and pipe the output to the user | 20:03 |
| katco | jcastro: hey | 20:04 |
| katco | jcastro: so the provider could certainly do that; however, one nice side-effect is that the provider will use any image named ubuntu-trusty | 20:04 |
| katco | jcastro: so it's kind of nice that you can pre-build an image and the provider will just use it | 20:05 |
| katco | jcastro: or use alternative images (i.e. not trusty) | 20:05 |
| jcastro | ok so I should just change the import command to making an alias | 20:05 |
| jcastro | oh wait | 20:05 |
| jcastro | I just thought about what you said | 20:05 |
| jcastro | so I can premake an image | 20:05 |
| katco | jcastro: yep :) | 20:05 |
| jcastro | and as long as it's aliased as ubuntu-trusty that just works? | 20:06 |
| katco | jcastro: i expect we'll refine this if jam and tych0 haven't begun doing so already | 20:06 |
| katco | jcastro: you may have to twiddle with where tools are pulled from | 20:06 |
| pmatulis | jcastro: kindly open an informative docs bug and i'll jump on it | 20:06 |
| jcastro | wait a minute | 20:06 |
| jcastro | did you guys just give us image based workflows? | 20:06 |
| katco | jcastro: but what i've done is bootstrapped a xenial host (i think), snapshotted it | 20:06 |
| natefinch | jcastro: for local only, sure | 20:06 |
| katco | jcastro: and then just alias that, and standup time is super quick | 20:06 |
| katco | jcastro: shhhhhh | 20:07 |
| jcastro | pmatulis: I think I can submit a PR, quick fix once I sort the command | 20:07 |
| katco | jcastro: don't use the i word! | 20:07 |
| natefinch | heh | 20:07 |
| jcastro | marcoceppi: ^^ look what just happened! | 20:07 |
| katco | no! nothing to see here. ignore the images behind the alias | 20:07 |
| jcastro | right, I can see how that would be bad and unsupported | 20:07 |
| katco | jcastro: more like off-brand. i'm sure solid workflows could be built off it | 20:08 |
| marcoceppi | jcastro: oh, yeah, I knew about that ;) | 20:08 |
| jcastro | hmm ok, so really the only thing we need to update is figure out how to make the ubuntu:14.04 remote image aliased to ubuntu-trusty on my local machine | 20:10 |
| katco | jcastro: yeah | 20:11 |
| alexisb | so jcastro I was chatting with jam about this this morning | 20:15 |
| alexisb | we will be making some updates to the user experience on this | 20:15 |
| alexisb | and I would love your input | 20:15 |
| alexisb | I might schedule some time to chat | 20:16 |
| jcastro | yeah, I kind of feel like, since LXD has remote images available already | 20:16 |
| alexisb | pmatulis, the workflow for using lxd provider is in the release notes | 20:16 |
| jcastro | and I do juju bootstrap, just spawn it, one less step for us | 20:16 |
| alexisb | jcastro, yep | 20:16 |
| alexisb | jcastro, we agree | 20:16 |
| alexisb | but I dont want to loose the ability to tag an image and use it | 20:16 |
| katco | alexisb: keep in mind mark's requirement that we be able to specify the image to use | 20:16 |
| katco | alexisb: yep | 20:16 |
| pmatulis | alexisb: jcastro is all over it. i'm on standby | 20:17 |
| alexisb | katco, yep | 20:17 |
| katco | alexisb: (goes into muppet mode) yep yep yep yep | 20:17 |
| katco | uhhuh uhhhuh | 20:17 |
| alexisb | :) | 20:17 |
| katco | https://www.youtube.com/watch?v=vh3tuL_DVsE | 20:17 |
| === thumper is now known as thumper-afk | ||
| mup | Bug #1552523 changed: Unable to deploy a wily or precise service with MAAS <maas> <network> <juju-core:Invalid> <juju-core 1.25:Invalid> <https://launchpad.net/bugs/1552523> | 21:23 |
| katco | ericsnow: standup time! | 21:33 |
| === thumper-afk is now known as thumper | ||
| marcoceppi | help! juju init doesn't work in beta1 | 22:54 |
| rick_h__ | marcoceppi: there's nothing to init | 22:59 |
| marcoceppi | rick_h__: dude | 22:59 |
| marcoceppi | read the help output | 22:59 |
| marcoceppi | now I hav to create the XDG_DATA path and stuff | 23:00 |
| rick_h__ | marcoceppi: it should be there with install for the cloud list | 23:00 |
| rick_h__ | marcoceppi: and the add-credential command is coming to esit that file | 23:00 |
| mup | Bug #1456717 opened: TestUpgradeStepsStateServer fails <ci> <test-failure> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1456717> | 23:17 |
| mup | Bug #1552948 opened: metricsmanager DB collection shouldn't be "global" <juju-core:New> <https://launchpad.net/bugs/1552948> | 23:17 |
| marcoceppi | rick_h__: I need help, azure 2.0-beta1 | 23:18 |
| marcoceppi | demo in 45 mins | 23:18 |
| marcoceppi | it's asking for an auth-type | 23:18 |
| marcoceppi | userpass | 23:19 |
| cmars | marcoceppi, LP:#1544890 | 23:19 |
| mup | Bug #1544890: "ERROR the name of the model must be specified" when 'juju init' required <bootstrap> <juju-release-support> <juju-core:Triaged> <https://launchpad.net/bugs/1544890> | 23:19 |
| cmars | i opened this before i realized juju init was going away, but still | 23:20 |
| rick_h__ | marcoceppi: heading toncomputer onw sec | 23:24 |
| marcoceppi | rick_h__: I got it sorted | 23:24 |
| marcoceppi | it's bootstrapping | 23:24 |
| rick_h__ | marcoceppi: k | 23:24 |
| marcoceppi | was just getting a little tight, since it takes 20 mins to deploy and I couldn't get 2.0 to bootstrap | 23:25 |
| marcoceppi | <3 the error messages, they were helpful | 23:25 |
| rick_h__ | marcoceppi: k, email sent with all the details I sent to another perosn as well | 23:25 |
| rick_h__ | marcoceppi: has sample file in it and such | 23:25 |
| rick_h__ | marcoceppi: in case it's giving you any grief | 23:25 |
| marcoceppi | rick_h__: I used beta1 release notes to find what I needed to copy from environments.yaml | 23:26 |
| rick_h__ | marcoceppi: k | 23:26 |
| marcoceppi | I already had ARM setup in alpha3 when it landed, thankfully | 23:26 |
| marcoceppi | tried to use 1.25 though, and realized my mistake | 23:26 |
| rick_h__ | ah cool | 23:26 |
| marcoceppi | so have to plow through with 2.0 for the demo | 23:26 |
| rick_h__ | you have the alpha gui? | 23:27 |
| rick_h__ | https://jujucharms.com/u/juju/juju-gui | 23:27 |
| rick_h__ | marcoceppi: ^ is the beta to work on top of juju 2.0 | 23:27 |
| rick_h__ | marcoceppi: some bugs, but supposed to work | 23:27 |
| marcoceppi | rick_h__: ack, no more ~yellow? | 23:27 |
| marcoceppi | I just need it to show the model, everything else is cabs cabs cabs | 23:27 |
| marcoceppi | thanks for the mail, looking forward to beta2! | 23:28 |
| rick_h__ | marcoceppi: it's still in ~yellow but wanted to move to a more 'public' space if we're going ot hand out a beta widely | 23:28 |
| rick_h__ | marcoceppi: so we'll put betas under ~juju from now on as it's more meaningful than yellow | 23:29 |
| marcoceppi | rick_h__: cool beans | 23:29 |
| cmars | i need to parse a user-facing string into an apiserver/params type in a couple of different api client packages. where is the best place to put such a ParseXYZ() function? | 23:32 |
| cmars | wallyworld ^^ any suggestion? | 23:33 |
| alexisb | wallyworld, I want you to know that marcoceppi reads release nots: | 23:34 |
| alexisb | <marcoceppi> rick_h__: I used beta1 release notes to find what I needed to copy from environments.yaml | 23:34 |
| wallyworld | cmars: one sec, just finishing standup | 23:34 |
| alexisb | marcoceppi, I am sure that line just made wallyworld's day | 23:34 |
| marcoceppi | alexisb: read the release notes? I live by them. esp for the 2.0 releases | 23:36 |
| marcoceppi | it's like a little gift from core every few weeks | 23:36 |
| alexisb | lol | 23:36 |
| marcoceppi | fuck, I can't get rid of an errored unit | 23:41 |
| marcoceppi | rick_h__: I found a fun gui bug | 23:48 |
| wallyworld | alexisb: marcoceppi: you did just make my day :-) we put a lot of effort into those notes | 23:49 |
| wallyworld | cmars: what sort of parsing? | 23:49 |
| rick_h__ | hatch: ^ | 23:50 |
| rick_h__ | marcoceppi: what's up? | 23:50 |
| marcoceppi | rick_h__: in the ~juju/juju-gui, if I got to remove units for a service, it just creates a new machine instead of removing the unit | 23:51 |
| rick_h__ | marcoceppi: i think they're on that one | 23:51 |
| marcoceppi | cool | 23:51 |
| marcoceppi | i just realized this whole demo is borked because cabs can't speak 2.0 api | 23:52 |
| rick_h__ | oh no! | 23:52 |
| davecheney | oh uh | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!