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