[00:43] babbageclunk: a couple of thoughts, see what you think? [00:48] wallyworld: ok, will take a look [00:51] wallyworld: I agree with both of those, thanks! [01:00] babbageclunk: so to check, the only place you will change to plug in the raft backend is (st *State) getLeaseClient() [01:01] getLeaseStore() even [01:02] wallyworld: no, it'll need to be higher up - not a method on state at all [01:02] wallyworld: because the new manager won't be running as a state worker. [01:02] It'll be a method on the facade context. [01:03] righto [01:03] Oh, hang on - that's how an API facade will get the checker or claimer it needs. [01:04] The store will be passed into a manager worker running in the machine agent manifolds, constructed from the FSM and the hub. [01:05] makes sense [01:05] cool [01:05] let me know when the pr is not WIP [01:11] wallyworld: ok, just doing the last set of tests. [01:13] wallyworld: I've pushed up PR fixes and additions. There is a bit of duplication there (for the config retrieval); where would be the best place to put a common function or 2 so there is only 1 impl (plus will be easier to test that one) [01:28] veebers: just saw the above, was reviewing the commit. it's not too bad have a few lines of code duplicated. can you make sure you fully test against the staging controller, deploying and upgrading charms etc, before landing [01:29] wallyworld: can do [01:51] wallyworld: could u plz look at PR. I have modified the mock to export state obj. [01:55] ok [01:57] wallyworld: i am adding back the bundles.go file in facades/client/client [02:04] vino: i left a couple of comment s- it's coming along nicely [02:04] a few things to look at. i'll be back in 15 minutes [02:06] sure. [02:34] wallyworld: i have added back the files bundles.go and bundles_test.go fixed the issues becuase of my changes in NewFacade. [02:34] ok [02:34] ... adding validation for unit test n export method. yes i has issue becuase nothing is filled in. [02:34] i thought validation is enough. [02:35] do u want to mock serialize methods as well ? [02:39] vino: not mock serialise methods, just return a model.Description that is then serialised as normal and checked [02:40] description.Model i mean [02:40] ok. [02:40] the mock state would just return description.NewModel() [02:40] with args having an app or unit or something [02:41] just something to result in a really simple result to check [02:43] i am adding a simple app. and get that validated. [03:24] wallyworld: ok, that PR isn't WIP anymore. I'm doing a smoke test then I'll review your PR [03:24] yay, ty [03:24] babbageclunk: i have to head to hospital in 5, will quickly review, then back in an hour [03:25] ok - no rush [03:32] babbageclunk: i think it looks ok, lgtm. we should run some manual tests as well with charms etc [03:32] bbiab [03:32] ok [04:21] babbageclunk: why can I not do something like: "s.ControllerConfig[controller.CharmStoreURL] = s.srv.URL" at the end of "func (s *charmStoreSuite) SetUpTest(c *gc.C)". It's not an error, but that value isn't sticking [04:23] wallyworld: pushed a commit. can u please verify... [04:28] ah, probably because I"m just changing the copy in the test suite, whereas the one in the actual code will be a version based on that which was passed into the bootstrap [04:58] thumper: you have a moment? [04:59] or babbageclunk ? [05:18] and finally wallyworld ? ^_^ http://paste.ubuntu.com/p/x8G9BN5qcz/ The problem being that the conn suite does the bootstrap, and setups up the DB that's needed to start the charmstore and http server, but we need that url *before* the bootstrap so we can set the charmstore controller config :-\ [05:18] so my fix here was to shoehorn in a patch [05:20] veebers: jujuconnsuite has controller config attrs [05:21] you can put any initial values to use with bootstrap in there in setup [05:21] wallyworld: ack, you need to set them before calling SetUpTest [05:21] setupsuite [05:21] or, do that and then call jujuconnsuite setup test [05:21] wallyworld: But you need to call SetUpTest to prepare the DB that's used to spin up the charm store, which is where we get the url that we need to set [05:21] ie set the controller cfg, and then call jujuconnsuite setuptest [05:23] veebers: so SetupTest calls setupConn() which bootstraps [05:23] so before calling SetUpTest(), set the controller cfg [05:24] wallyworld: but I don't know what the value is until the charmstore is spun up, and I can't spin up the charmstore until after setuptest [05:25] what does the charmstore depend on in setup test? [05:25] wallyworld: the db [05:25] but not the same one as juju uses [05:25] veebers: I think you could change JujuConnSuite to allow you to set a callback that it would call to get attrs for controller config. [05:25] charmstore and juju controller state are different dbs [05:26] or should be different dbs [05:26] they are not the same db in the real world [05:26] And then abuse the fact that the session would be set up by the time the callback runs [05:26] wallyworld: unless I'm reading this wrong: it does: "db := s.Session.DB("juju-testing")", then ".. = charmstore.NewServer(db, nil, "", params, charmstore.V5)" [05:26] so that's unfortunate [05:26] whoever wrote the test is abusing things [05:27] hah ok, so it can be improved. [05:27] but it can still be made to work [05:27] I think we can all agree though that my attempted fix is pretty shoddy and can be done better [05:27] set up mongo ahead of time [05:28] i'll have a quick look at the code, going from memory here [05:28] the fix is "ok" but we don't want to introduce new Patch functions if we can help it [05:28] wallyworld: ack thanks. I gotta EOD shortly, visiting family but I'll check back in later on [05:28] no rush, we can land monday [05:29] agreed, it would be nice to just set the controller config and have it all shake out like in real life [06:09] kelvin_: reviewed. there's an issue with test setup to get the charms. see my comments and can chat if needed [06:09] looking good though [06:10] wallyworld, thanks, looking it now. [06:12] veebers: quick thought, in charmstoreSuite we do JujuConnSuite.SetUpTest(), then s.srv = httptest.NewServer(handler), then charmstore client set up [06:12] we can move s.srv = httptest.NewServer(handler) to the top of the set up if we get a different mongo session [06:13] no strict need to use the same one as for juju [06:13] the sessions will use the same mongod which is running, but will be constructed individually [06:13] using the s.Session for both was just a shortcut [06:14] worth digging a bit to see how it pans out [06:16] kelvin_: the charm testing comment make sense? at a high level, it's a matter of correctly setting up the (global) testcharms.Repo to point to the correct path ("quantal" or "kubernetes") [06:18] wallyworld, yes, i m working on it right now. thx [06:18] great, ty [06:18] wallyworld: ack, will do [06:19] veebers: ty. i haven't dug too deeply but it should be doable once we see how the s.Session is constructed [06:20] just make one to use for the store storage itself, remembering to add to cleanup [08:47] Anyone able to do a quick back-port review? https://github.com/juju/juju/pull/8901 [09:14] all: anyone tried juju 2.4 with bionic? [09:14] Trying to get bionic lxd containers work with ti [09:14] fails do proper bridge setup [10:06] rathore_: What is the particular issue you are seeing? [10:10] manadart: The container networking seems to be issue on bionic. Everything works well on series xenial and lxd containers are not able to complete initial bootstrap [10:10] https://paste.ubuntu.com/p/6YqtgNBpxZ/ [10:11] manadart: I am trying to install openstack using https://github.com/openstack-charmers/openstack-bundles/blob/master/development/openstack-lxd-bionic-queens/bundle.yaml [10:20] rathore_: On what provider are you attempting to deploy the bundle? [10:21] Maas [10:22] manadart: maas [10:26] rathore_: I'll try the same bundle shortly. In the meantime, if you can locate any specific logged errors, that would be good info for a Launchpad bug. [10:27] manadart: I am trying to get a simplest bundle to reproduce it. [10:28] hi everybody [10:30] I am having an issue with juju and maas. juju reload-spaces doesnt reflect the new space changes. it still shows an old space that is no longer there. also juju show-controller shows an ols model that is not there and i dont seem to be able to remove it [10:36] manadart: Simplest bundle to reproduce: https://paste.ubuntu.com/p/4T75kzCt3B/ [10:36] manadart: paste has more information on the issue [10:37] seems to be lxdbr0 is not using provider network [10:38] manadart: it also looks that containers have got IP address from provider network (br-bond0) but are connected to lxdbr0 [11:02] rathore_: This *could* be an issue with cloud-init networking and netplan (Bionic) vs e/n/i (Xenial). I will investigate. [11:19] manadart: [11:23] manadart: I have a feeling it could be mtu 9000. Trying with mtu 1500 now [11:23] rathore_: Oooh, I have definitely seen that one. [11:24] manadart: Thats a relief. In that case it should work with mtu 1500, i will confirm in few minutes [11:41] manadart: Yes confirmed it is mtu 9000 issue. It doesn't work with bionic. [12:30] all: any ideas to kill containers that are stuck in error state [12:30] 0/lxd/5 error pending bionic Creating container [12:53] juju --helo [12:53] juju --help [12:53] juju --help; [12:54] shutdonw now [14:18] all: What is the way to kick a container stuck in error state while being created [14:26] rick_h_: Any suggestions ? [14:58] Getting quite a lot of "juju.provisioner provisioner_task.go:1115 failed to start machine" in 2.4 bionic [15:27] rathore_: try "juju status --format=yaml ". sometimes the yaml output will yield more info about provisioning issues. [15:28] rathore_: there's also "juju retry-provisioning " if you want juju to retry a failed machine. [16:22] kwmonroe: It doesn't allow retry for containers