[00:49] <thumper> https://github.com/juju/juju/pull/10834/files
[01:31] <wallyworld> kelvinliu: +1 but with a request for validation, might be possible, let me know
[01:32] <wallyworld> thumper: lgtm, ty
[01:36] <kelvinliu> wallyworld: tyrv, no, we can't validate the cr before getting the CRD. because it's just a string for us without knowledge of the CRD.
[01:37] <wallyworld> kelvinliu: yes, but can't we make an api call to validate?
[01:37] <kelvinliu> but k8s will return the validation error if the deployed CR did't match the CRD format
[01:38] <wallyworld> and we can't check that before actually trying to create one?
[01:38] <wallyworld> there's no k8s Validate() method?
[01:38] <wallyworld> i guess we can't be sure the crd exsists
[01:38] <wallyworld> until be process the entire yaml
[01:38] <kelvinliu> so just deploy, either success or fail(return validation error from k8s) would be better,
[01:39] <wallyworld> what does kubectl do if the unstructured cr yaml is bad?
[01:39] <kelvinliu> errors returns from api-server
[01:39] <wallyworld> does it return an error or just do it and you see the error with kubectl get
[01:40] <kelvinliu> we are following the kubectl way
[01:40] <wallyworld> ok, so long as we set an error in juju status which i think we do
[01:40] <kelvinliu> yes, we do
[01:40] <wallyworld> ok, sgtm, ty
[01:44] <kelvinliu> np
[01:52] <wallyworld> hpidcock: getting through your PR, have a meeting in 5 but will continue after that
[02:51] <timClicks> "Highlighting some important Juju workloads" https://discourse.jujucharms.com/t/2077
[02:52] <wallyworld> hpidcock: why do we need to annotate the pods with init id as part of the running check?
[02:56] <wallyworld> ah, if you scale directly in k8s, the juju unit won't exist straight away
[02:58] <timClicks> babbageclunk: nice work on the vsphere nics bug
[02:59] <babbageclunk> :(
[02:59] <babbageclunk> oops, thanks!
[03:09] <hpidcock> wallyworld: yeah there is a race condition that the unit and provider id has not matched yet, which means the WatchContainerStart facade will filter it out because it doesn't know it yet.
[03:10] <hpidcock> Also, it's now a nice useful debug annotation :)
[03:11] <wallyworld> indeed
[03:22] <hpidcock> anyone else getting test fails on localServerSuite.TestNetworkInterfacesForMultipleInstances? I think it's an ordering issue, but wondering if anyone has fixed it or seen it
[04:56] <wallyworld> hpidcock: i've not seen it it myself. is it blocing landing your PR?
[04:58] <hpidcock> I don't think it will block, something is using a map somewhere, it has 2 elements, so that makes it a 50% chance to land :D
[04:58] <wallyworld> could be worse :-)
[04:59] <wallyworld> kelvinliu: your PR good to land today too?
[05:01] <kelvinliu> wallyworld: i think so, I m solving some races in tests.
[05:01] <wallyworld> ok, ty!
[08:20] <manadart> Still after a tick on https://github.com/juju/juju/pull/10821.
[08:58] <manadart> nammn_de: Can you try the 2nd QA step on a different substrate for patch 10821 and approve if it passes? Need to get it landed.
[09:01] <nammn_de> manadart: will do :-)
[09:02] <nammn_de> does it have to be space aware like aws? Or does lxd work?
[09:05] <manadart> nammn_de: LXD should work.
[09:12] <achilleasa> manadart or nammn_de: one line PR for fixing the ec2 intermittent test failure that hpidcock reported: https://github.com/juju/juju/pull/10835
[09:15] <jam> manadart: have you considered whether we want to be passing space ids in the migration content?
[09:15] <jam> manadart: that's the only thing keeping me from flagging that Approve, so if you're confident we can move forward
[09:20] <manadart> jam: I am confident. I understand communicating in terms of space names from a conceptual point, but I don't think reverting from IDs gets us any more "correctness" for the effort.
[09:38] <nammn_de> manadart: run qa, approved as you are confident and qa worked
[09:38] <manadart> nammn_de: Ta.
[10:37] <manadart> achilleasa: Looks like I need to rebase with your test fix for mine to play ball and land.
[10:38] <achilleasa> manadart: fix is still landing... that test fails about 20% of the time so if you retry the merge it should probably work
[10:39] <manadart> achilleasa: Giving it another lash. Last 2 failed.
[10:44] <nammn_de> stickupkid: coming back to the charming thing. I was thinking a little how to make it consistent with the old behaviour while removing the bug we were talking before. I think this should do it https://github.com/juju/charm/pull/297/files
[11:05] <stickupkid> nammn_de, nearly there :D
[11:18] <achilleasa> manadart: fix has landed
[11:19] <manadart> achilleasa: Yeah, mine was backed up behind yours, so I could have just waited. Running now.
[11:50] <nammn_de> stickupkid: updated it
[11:51] <stickupkid> nammn_de, much better
[11:52] <stickupkid> readability ftw!
[11:53] <nammn_de> stickupkid: let's hope big that now all things work as expected there compared with before :D
[12:01] <manadart> achilleasa: Mine is in. Let me see if I can chase this issue. I think your time is better spent on the instance-poller stuff.
[12:13] <hml> manadart: what do you mean by “a zero-value SpaceInfo “ for the peergrouper getHASpaceFromConfig()
[12:15] <manadart> hml: "network.SpaceInfo{}"
[12:15] <manadart> hml: Which is effectively sending "" for space ID/name.
[12:16] <hml> manadart: ack
[12:47] <achilleasa> hml: one small comment for your PR; I will run the QA steps in a bit
[12:47] <hml> achilleasa:  thank you.
[12:48] <hml> achilleasa:  if you have time after stand up, or after pick up, i’d like to chat on the other one pls  10825
[12:49] <achilleasa> hml: sure, I have 1h before pickup so let's do this after standup
[13:26] <Mudchains> Hi all, I am deploy a kubernetes-core on a onpremise vpshere environment atm. its already 10 minutes 'stuck' at Juju Controller is initializing. Please wait. The console of the juju-controller VM is waiting at a logon screen. is this normal behavior?
[13:40] <hml> manadart: ping?  can you join daily for pr chat?
[13:43] <manadart> hml: OMW
[13:56] <nammn_de> manadart: do these changes make sense to you? I reuse the metrics pointer from application to use them in the charmconfigwatcher
[13:56] <nammn_de> https://github.com/juju/juju/pull/10833
[14:19] <nammn_de> jam: I was looking into how some charm tests are written in juju/juju. Some are under /juju/juju/repositoy... and they contain a "version" file as well. Right now the "git describe dirty" would take precedence over the version file. Is that wanted?
[14:41] <nammn_de> stickupkid: got a minute?
[14:57] <nammn_de> stickupkid: https://github.com/juju/juju/pull/10836 added some background
[15:07] <nammn_de> rick_h: above I sent to jam ^ should vcs or version file take priority?
[15:25] <manadart> hml achilleasa: Should I expect all bindings not-explicitly defined to be "0" now?
[15:27] <hml> manadart:  yes, the exception is if the application’s default endpoint has a defined value.
[15:28] <manadart> hml achilleasa: This looks like the issue with https://bugs.launchpad.net/juju/+bug/1850589
[15:28] <mup> Bug #1850589: migrating kubernetes-core fails <model-migration> <juju:Triaged by manadart> <https://launchpad.net/bugs/1850589>
[15:29] <manadart> The bindings migrated from 2.6 are all "" in the 2.7 model.
[15:31] <hml> manadart:  i thought we had code to convert them when the bindings were migrated.  hrm…
[15:40] <achilleasa> manadart: hml That looks correct to me; it's the old default space name, no?
[15:41] <hml> achilleasa:  yes… but we should be saving in to the db with an ID, not a name
[15:45] <hml> achilleasa: manadart  i think i found a bug in the cmr code related to the space name/id… spaceIDs do not translate outside of the given model.  spaces are used to match up subnets on each side of the offer.
[15:45] <Mudchains> Ok it was defently a firewall issue. conjure-up is now deploying the kubernetes-core on the vsphere environment
[15:48] <manadart> achilleasa hml: Look at what I posted in the bug. The issue is here: https://github.com/juju/juju/blob/6bf5de9ded487a4ecb8d23a8118ef3df030c24c0/state/migration_import.go#L853
[15:49] <manadart> We are relying on NewBindings to return endpoint:space-id, but if all are "", it returns the original map.
[15:50] <manadart> So we import it untouched from an old controller with no explicitly bound endpoints.
[16:00] <achilleasa> hml: this is why we should probably dumb down NewBindings so it only works with space ids... ^^
[16:02] <hml> achilleasa: ensuring it’s called that way might be a bigger problem.  and changing code handingly “”
[16:06] <manadart> achilleasa hml: Who should I assign it to? I have to make a move here.
[16:06] <hml> achilleasa:  can you pick it up?  i’m knee deep in get the other two PRs going
[16:24] <achilleasa> hml: on it
[16:24] <hml> achilleasa: awesome!
[16:38] <achilleasa> hml: ok, so the issue here is that when you export from 2.6.x the description contains ep => space name (with "" for the default) whereas for 2.7+ it will contain space IDs... I guess the fix is to auto-map "" => AlphaSpaceID
[16:39] <hml> achilleasa:  yes, a good place to start.  we should perhaps review with handing of model config default-space.
[16:52] <achilleasa> hml: since the model config is a 2.7 only feature, I think that the migration should not take it into account as it could lead to unpredictable bindings
[16:53] <hml> achilleasa:  gd point
[17:20] <nammn_de> Someone wanna take a look at this one? https://github.com/juju/juju/pull/10838 Adds bash branch completion
[17:22] <rick_h> nammn_de:  sure thing
[17:59] <achilleasa> rick_h: should 'juju run --unit ubuntu-lite/0 "network-get another"' print something out?
[18:01] <rick_h> achilleasa:  no? since it's not in a relation context?
[18:01] <rick_h> achilleasa:  or maybe...thinking more
[18:01] <achilleasa> rick_h: ah yes...
[18:01]  * rick_h checks if that's an extra-binding or a endpoint
[18:02] <achilleasa> well, I have a fix for thumper's issue and probably https://bugs.launchpad.net/juju/+bug/1850589
[18:02] <mup> Bug #1850589: migrating kubernetes-core fails <model-migration> <juju:In Progress by achilleasa> <https://launchpad.net/bugs/1850589>
[18:03] <rick_h> achilleasa:  hmm, what does 2.6 do with it?
[18:26] <achilleasa> rick_h: something odd is going on 'github.com/juju/juju/cmd/juju/commands/exec.go:434: timed out waiting for result from: unit ubuntu-lite/0'
[18:27] <rick_h> achilleasa:  yea...
[18:27] <rick_h> achilleasa:  working to rebootstrap/test that here as well
[21:55] <timClicks> have a minute? any eyes on this piece is appreciated: https://discourse.jujucharms.com/t/draft-juju-2-7-0-creating-a-new-usability-standard-for-infrastructure-automation/2294
=== narindergupta is now known as narinderguptamac
[23:37] <anastasiamac> fwiw, we already collect and display in machine-format cloud 'source'
[23:38] <anastasiamac> wallyworld: path of less resistence is to add it to tabular as 'Kind'
[23:38] <anastasiamac> wallyworld: but 'personal' clouds r called 'local' atm.. m happy to keep them as 'local'.. r u?