[00:11] wallyworld: sweet, test highlighted the issue, quick fix in the end (conditional at wrong level, let probablySetStatusHistory make that choice) [00:11] yup, it checks for status being the same [00:11] aye, I had to tweak that a little with the history overwrite bits [00:59] kelvinliu_: no rush, just sometime today if possible, i added placement support https://github.com/juju/juju/pull/9190 [01:01] wallyworld, yeah, will take a look soon [01:02] * wallyworld pops out to buy coffee [02:38] wallyworld: seeing this in the operator pod log: https://paste.ubuntu.com/p/WS8STGfb9F/ did something land recently that might cause that? I'm pretty certain it's unrelated to my changes at all [02:39] operator pod code has changed, but your local copy of the code is stale [02:39] you just need to rebase [02:40] ack thanks, will do [03:55] wallyworld: ok, finally got that PR updated, history looks good: https://paste.ubuntu.com/p/FnVQ7q3QX8/ I did see these logs in the controlelr debug-log, I don't think it's my changes, I did touch the provisioner though: https://paste.ubuntu.com/p/pjfvpmYngV/ [03:56] veebers: yeah, those are "normal". just getting a coffee and then will look [03:57] ack, thanks. should be pretty much there this time :-) [04:17] * thumper sighs [04:18] anastasiamac, wallyworld: do you know of any CLI tests that ensure there is a controller entry for a mock CLI test? [04:18] using testing.BaseSuite [04:18] which has a fake xdg data suite thingy [04:18] you mean in the local yaml files? [04:19] yeah, to fake a controller entry [04:19] hmmm, there's a few slightly different ways tests do it; i can't recall a specific example without digging around, i can take a look [04:19] oh... [04:20] it uses a different base... [04:20] uses JujuOSEnvSuite [04:20] there's a MemStore that tests can use [04:20] and that's passed ion to the CLI constrcution [04:20] and the mem store is set up with data [04:20] so the test never hits disk at all [04:21] is that in the model wrapper? [06:02] wallyworld: https://github.com/juju/juju/pull/9191 [06:02] righto [06:02] wallyworld: it seems github diff doesn't like me renaming the state_test.go to state_internal_test.go [06:02] and then add a different state_test.go [06:02] sigh [06:02] if only it tracked renames :) [06:04] * thumper EODs [06:04] see y'all tomorrow [06:04] oh joy! +5,633 −5,423 [06:13] wallyworld: yeah, that description seems too brief given the size of the PR [06:14] wallyworld: want a shorter one? https://github.com/juju/juju/pull/9192 [06:14] most of it just a test move, like file rename kind of... [06:14] anastasiamac: ah right - yeah, there are a lot of status tests. [06:14] yep [09:54] I loke how we have two different places for escaping mongo "." in names [09:54] s/loke/like [10:25] stickupkid: Regarding recent changes to CI for formatting, what might cause this? http://ci.jujucharms.com/job/github-check-merge-juju/3433/console [10:26] manadart: what go version you using? [10:27] gsamfira: Want to jump in here? stickupkid: should that matter for CI? [10:27] manadart: if it's 1.11, then you need to downgrade to 1.10.x - golang made a breaking change [10:28] RE: https://github.com/golang/go/issues/26098#issuecomment-400859370 [10:28] manadart: we're going to force 1.11 next week at the sprint, so all outstanding branches etc will need updating [10:30] stickupkid: gotcha. Downgrading. I'm running 1.11 [10:30] thanks [10:32] gsamfira: np :D [11:12] manadart: i'm looking at escaping documents from mongo, have you seen this in passing? or do we do it late in the day, before we use it [11:12] s/escape/unescape [11:13] mandart: I'm looking if there is any common pattern for this [11:13] stickupkid: Not sure. I've not had accommodate it directly. [11:13] manadart: fair [12:51] stickupkid: manadart I thuoght we had a tool around that. I remember jam mentioning making things "fat hyphen" and such [12:51] rick_h: we do, i found it [12:52] rick_h: well i found it twice, there is code duplication :D [12:54] stickupkid: hah, ok cool [14:09] stickupkid: changes made: https://github.com/juju/charm/pull/264 [14:09] stickupkid: i plan to squash the commits before merge. [14:09] hml: yeah, fine by me [14:09] hml: LGTM - :D [14:13] stickupkid: merged [14:57] Good Morning [15:02] morning parlos [15:02] externalreality: QA'd the branch there. Looks awesome! [15:02] externalreality: one typo note and I thought I recalled a conversation around the error at the end of complete? If that's for followup work then carry on [15:11] I've used the openstack-bundle-57 to deploy OS, works nice. However, I ran in to trouble a few miles down the line. What I discovered was that nova compute ran out of local storage, however afaik, there is no config option for that in the nova-compute service, as that is handed by Libvirt. Which then got me wondering, who installes/configures libvirt? Guess it comes with the OS, and if so, how could this be modified from the bundle? [15:12] hml: are you using "gopkg.in/charm.v6-lxdprofile" in the dep file [15:12] hml: i'm trying to do it the standard way, rather than injecting the git repo directly into the vendor folder... [15:17] parlos: so the bundle is a collection so applications and each application will have its own config available. I'd expect that it's something you can tweak in the nova-compute charm config: https://jujucharms.com/nova-compute/ (look at the config section) [15:17] parlos: for expertise on setting that up better I'd reach out to the openstack folks but hopefully that helps [15:19] rick_h; from that you can config the empheral storage, but the storage i think i'm refering too is managed by libvirt. which isnt a service in the bundle... [15:20] rick_h; from that I can config the ephemeral storage, but the storage i think i'm referring too is managed by libvirt. which isnt a service in the bundle... [15:23] rick_h; the question can be generalized, who configures the 'base' services on a node? SSH seems to be configured by maas in my case, but juju also does something too it (i think) but ssh is not listed as a service..hope my question is understandable. [15:26] hml: this is really annoying, we can't namespace dep toml file to point to "gopkg.in/juju/charm.v6-lxdprofile" [15:26] hml: it's because https://github.com/niemeyer/gopkg/blob/master/version.go#L16 hardcodes unstable :| [15:26] stickupkid: poopy [15:27] hml: i've got an idea :D [15:28] hml: yes it works :D [15:29] stickupkid: w00t [15:29] hml: one sec, i'll make a branch, that we can use as our base branch [15:30] hml: this could be away to get rid of the patches folder as well [15:31] stickupkid: cool, jam was wondering if that could be done with deps [15:31] hml: yeap :p [15:32] hml: CR here https://github.com/juju/juju/pull/9193 [15:33] hml: so we don't have to change any source code in juju, just update the revision, when the v6-lxdprofile feature branch is done, then we just update the dep Gopkg.toml + lock file and we're done :D [15:34] hml: right, i can start working on the validation stuff now :D [15:34] hml: don't feel dirty hacking on my vendor folder now [15:35] stickupkid: how does that work? charm/lxdprofile instead of charm/v6-lxdprofile? [15:35] hml: typo, just needs to be charm, one sec [15:36] hml: it ignores everything after the project anyway [15:38] hml: try now [15:41] stickupkid: trying [15:41] parlos: so juju will touch things on a node that it needs to communicate/work like ssh keys. It doesn't do anything else. All of that is up to the charms on it. So I'd expect that if nova-compute needs to manage things for vms it would have those knobs. Otherwise i'd expect some other charm to provide the tools/controls for something else running. [15:42] manadart: is there away to have multiple leases at once, i.e. could leases overlap and how do know which leases are being offered [15:50] stickupkid: worked for me. :-) [15:52] stickupkid: looking at the safeLXDProfile now [15:52] hml: https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcRIOg8AK-PpstPTj5MeHL-loVkvw4V9RRhFrwMs9sVnz5AP7-k1 [15:52] :-D [15:54] rick_h: so, your guess would be that nova-compute (or some of the charms in the bundle) would install and configure libvirt in this case. [15:56] guess I have to do some digging, to see if thats something I can configure. thanks for the answers [15:57] parlos: correct, that would be my assumption if nova is creating VMs on top of libvirt. That's its job to manage then. [16:01] hml: we should be able to do that from the charmstore now - in theory "juju deploy cs:~simonrichardson/lxd-profile-3" [16:02] stickupkid: yes [16:02] stickupkid: or from juju/juju : juju deploy --debug ./testcharms/charm-repo/quantal/lxd-profile [16:03] hml: i wanted to make sure that it worked from the charmstore :D [16:03] stickupkid: did you push a charm up to the store? I haven't [16:03] just been using local charms todate [16:03] hml: yeah, we can always remove it later, but will help with manual testing [16:04] stickupkid: i believe we were going to add as juju-qa or something [16:04] stickupkid: there’s some up there already [16:04] hml: fair [16:04] hml: i'll see how that works in a minute [18:37] externalreality: are you sure on the do-release-upgrade? Did that get pushed up? I don't see it in the diff and the second round of QA still shows the space. [20:44] Morning all o/