=== narindergupta is now known as narinderguptamac
[01:33] <babbageclunk> wallyworld: Here's the fix for bug 1847278: https://github.com/juju/juju/pull/10714
[01:33] <mup> Bug #1847278: [vsphere] Juju does not respect --constraints root-disk-source to select appropriate datastore per node <juju:In Progress by 2-xtian> <https://launchpad.net/bugs/1847278>
[01:35] <wallyworld> babbageclunk: looking
[01:35] <babbageclunk> thanks!
[01:41] <wallyworld> babbageclunk: +1, did you manage to get vsphere to play nicely to test?
[01:42] <babbageclunk> yup yup
[01:42] <wallyworld> \o/
[02:21] <hpidcock> wallyworld: I've run the BlockDeviceMatching change against AWS, GCE and OpenStack with no issues. Do you think a run against vSphere is in order?
[02:21] <wallyworld> given it broke once, it would be good if possible, just to be 10000% sure
[02:35] <babbageclunk> wallyworld: tried extending a disk with the new govmomi, I still get a permission error waiting for the task
[02:35] <babbageclunk> I'll check that it still works with the wait and push that change anyway
[02:35] <wallyworld> damn, ok. bug time
[02:36] <babbageclunk> actually, do you think I should upgrade the lib?
[02:36] <babbageclunk> (I mean, push the change updating the dep)
[02:38] <babbageclunk> wallyworld: ^
[02:38] <wallyworld> does that help with the polling of the dsk size?
[02:38] <wallyworld> if no, then i'd only do it for 2.7
[02:39] <babbageclunk> yeah, makes sense
[02:39] <babbageclunk> no difference for the extend disk task
[02:40] <wallyworld> right, the errperm thing
[02:41] <wallyworld> but we still need to fogure out how to poll
[02:42] <babbageclunk> wallyworld: my plan is to get them to use the cli tool govc to dump details of a VM on the datastore of interest to see how the structure differs from ours
[02:43] <babbageclunk> hopefully that would show what we should be looking at instead
[02:43] <wallyworld> fingers crossed
[02:43] <wallyworld> and hopefully an upstream bug will get some info as well
[02:44] <wallyworld> maybe post the workaround we are using and see if anyone upstream replies to that
[02:48] <babbageclunk> ok - will do both of those
[02:48] <babbageclunk> need to go for a run though
[04:09] <thumper> more robust controller config: https://github.com/juju/juju/pull/10715
[05:07] <kelvinliu> wallyworld: should we allow charm to create more than extra service account or just one?
[05:08] <wallyworld> > 1 i think is the requirement
[05:08] <kelvinliu> wallyworld: ok, https://github.com/juju/juju/pull/10716 could u take a look this PR? thanks!
[05:09] <wallyworld> sure, just pushing up one, will look in 5
[05:09] <kelvinliu> wallyworld: np
[05:21] <wallyworld> kelvinliu: here's a small k8s peer relation fix https://github.com/juju/juju/pull/10717
[05:22] <kelvinliu> yup
[05:29] <wallyworld> kelvinliu: so the PR supports 1 SA in the kubernetesResources but we need to support > 1, ie a list
[05:29] <wallyworld> i believe that ken has operators that need > 1
[05:31] <kelvinliu> ah, just saw u said ">" 1.. my bad eyes. changing to a slice
[05:33] <wallyworld> \o/ ty
[05:46] <kelvinliu> wallyworld: changed to a slice of sa in KubernetesResources.
[05:46] <wallyworld> ok, looking
[05:49] <kelvinliu> thx
[05:51] <wallyworld> kelvinliu: +1 ty. we'll need to check with ken tomorrow to ensure it meets his needs
[05:52] <wallyworld> hpidcock: you saw i +1 your pr?
[05:52] <kelvinliu> wallyworld: thx,
[05:53] <hpidcock> wallyworld: yep just want to get this vsphere run done + add a vsphere test in
[05:53] <wallyworld> \o/ ty
[05:53] <hpidcock> I don't want this to break again haha
[05:53] <wallyworld> :-)
[05:53] <wallyworld> and oracle
[05:56] <hpidcock> already tested oracle
[06:24] <wallyworld> kelvinliu: shouldn't mark the bug as fix committed until the PR lands :-)
[06:26] <kelvinliu> wallyworld: ok..
[06:26] <wallyworld> leave for now, but for next one...
[06:27] <kelvinliu> changed 1847125 back to in progress already
[06:28] <wallyworld> ok
=== pal__ is now known as parlos
=== nammn_de is now known as nammn_de_
[08:26] <nammn_de_> any easy way to enforce upgrade steps run? Like a matcher whatever version I deploy to just run them again?
[10:09] <manadart> Anyone able to review https://github.com/juju/juju/pull/10697 ?
[10:19] <achilleasa> manadart: looking
[11:03] <achilleasa> manadart: or jam : If a relation unit used to have an ingress entry in its settings and when I try to refresh the network info I can't find one anymore, should I just delete the old entry from the settings?
[11:04] <achilleasa> (same question about egress-subnets)
[11:06] <manadart> achilleasa: I'm a bit light on this particular area, but I can't think why it would go away unless the machine NICs actually changed...
[11:07] <manadart> achilleasa: Actually, jump on a HO?
[11:07] <achilleasa> manadart: I was thinking something like machine rebooted and NIC is not there anymore
[11:07] <achilleasa> omw
[12:17] <nammn_de_> achilleasa manadart any clue how to find out why "running machine configuration script" is taking ages, last log from `cloud-log-output.log` is "agent binaries downloaded succesfully. Its like half an hour for on lxd controller
[12:17] <manadart> nammn_de_: Blocked upgrade will do that.
[12:18] <nammn_de_> manadart: I did not run "upgrade-controller" how do I find out more to debug that?
[12:18] <nammn_de_> was just bootstraping
[12:19] <manadart> nammn_de_: Got a /var/log/juju/machine-0.log ?
[12:19] <nammn_de_> nope not created yet
[12:20] <nammn_de_> juju folder still empty, cloud-output seems to have finished. Trying to find oput where it is stuck
[14:29] <bdx6> wallyworld: <3 #10717
[14:29] <mup> Bug #10717: gnome-vfs2: new changes from Debian require merging <gnome-vfs2 (Ubuntu):Fix Released by seb128> <https://launchpad.net/bugs/10717>
[14:29] <bdx6> heh - https://github.com/juju/juju/pull/10717/files
[14:30] <bdx6> ^ big time thank you!
=== bdx6 is now known as bdx
[14:56] <hml> achilleasa: actually… i do have an endpoint binding question for you.  why do we sometimes have the default EB specified, and sometimes not.  It’s not clear to me in these tests i’m fixing
[14:57] <achilleasa> hml: test link? are they bundle-related tests?
[14:58] <hml> achilleasa:  it’s all over, state, deploy (apiserver)
[15:00] <hml> achilleasa:  mostly i see it, because the changes i’ve made have caused the default empty string endpoint to be returned in some places it wasn’t expected.
[15:02] <achilleasa> hml: I wonder whether they were written assuming MAAS...
[15:03] <hml> achilleasa: i’ve hit code from 2013 now… so who knows at this poit
[15:03] <hml> point
[15:03] <achilleasa> because otherwise they would end up un network.DefaultSpaceName, right?
[15:03] <hml> achilleasa:  HO?
[15:03] <achilleasa> sure, meet you in daily
[15:33] <rick_h> bdx:  cool was going to send you that link but didn't know if you'd get bdx6 lol
[15:36] <bdx> christmas came early this year
[15:36] <bdx> you guys rock
[15:38] <rick_h> bdx:  trying
[15:38] <rick_h> bdx:  ty for the help in chasing that down, strange one
[15:44] <bdx> np
[15:44] <bdx> yeah, a sneaky one
[15:57] <nammn_de_> hml: manadart: regarding our discussion from before, the old code does not seem to restart the agents:
[15:57] <nammn_de_> https://github.com/juju/juju/blob/74c0afcf3714e602d2a1bbde8195a3cd9fe85802/upgrades/steps_245.go#L26
[16:05] <nammn_de_> hml manadart: could it be that the models dont run the upgrade steps? I have upgraded the controller which did execute it (given log), then run "upgrade-model" they did not seem to run it, is there an option to do it?
[16:05] <nammn_de_> the upgradesteps I mean
[16:14] <hml> nammn_de_:  to confirm, the models you ran upgrade-model with updated their version numbers?
[16:15] <nammn_de_> hml: yes they did. Juju status is returning the new version number
[16:15] <nammn_de_> has it something todo with steps being defined as 2.7.0 and we run 2.7-beta or is that independent and should work regardless?
[16:15] <hml> nammn_de_: there are a few different types of upgrade steps.  state and non (one other that shouldn’t be necessary)
[16:17] <nammn_de_> hml: reading the go doc i cannot make sense of the difference beween `stateUpgradeOperations` and  `upgradeOperations` Is former only run on the controller?
[16:17] <hml> nammn_de_: the state ones is for updating the database on the controller in one go.
[16:18] <hml> nammn_de_: looking at the other init changes… you might need the other, non state version
[16:18] <hml> nammn_de_: so stepsFor27() instead of stateStepsFor27()
[16:19] <nammn_de_> hm: I added to this slice as well and try it again, fi thats what you meant
[16:19] <nammn_de_> hml ^
[16:20] <hml> nammn_de_: check out upgrades/steps_24.go and steps_245.go
[16:21] <nammn_de_> hml: I see, there actually seems to be a diff, should have looked closer thanks!
[16:30] <nammn_de_> hml: but we don't have a kind of graph/code doc how upgrades are handled, right? Like which comes first, where we set the log and so on (?)
[16:31] <hml> nammn_de_: we don’t have a doc, the slices are executed in order.  depending on the order of the slice func.  can you expand on “where we set the log”, i’m not following
[16:32] <nammn_de_> hml: no that works perfect, I misswrote, sry. I mean lock :D
[16:33] <hml> nammn_de_: those pieces happen automagically as part of  upgrades.  no additional locks should be necessary??
[16:33] <nammn_de_> hml: yes, I assumed that. Just wanted to know more for background understanding
[16:34] <hml> nammn_de_: :-)
[16:34] <nammn_de_> hml: your tipp worked like a charm, thanks 🦸‍♀️!
[16:36] <achilleasa> hml: if I have a machine instance do you know how can I update its addresses in the machine doc?
[16:37] <achilleasa> "SetDevicesAddresses" changes docs in other collections
[16:37] <hml> achilleasa:  huh, let me look at something then
[16:38] <hml> achilleasa:  SetMachineAddresses()?
[16:39] <hml> achilleasa:  though it might be a set all…. not update
[16:39] <achilleasa> doh! how did I miss that? thanks!
[16:39] <hml> achilleasa: there are any methods with address in machine.  hahaha  :-)
[16:54] <manadart> achilleasa: Note the difference between SetMachineAddresses (machine agent sourced) and SetProviderAddresses (from provider).
[16:54] <achilleasa> yes, already stumbled on that :D
[16:55] <achilleasa> I need the latter
[16:55] <manadart> I'm not sure we really need MachineAddresses on that doc, but we can audit once things aren't in such flux.
[17:03] <nammn_de_> manadart: regarding the adding a upgrade step for space model config value, is to set for existing models the default value?
[17:05] <manadart> nammn_de_: Yes. If 2.7 assumes it's there, we need to set it for older models that are upgraded instead of bootstrapped anew.
[17:05] <nammn_de_> manadart: got it, thanks!
[17:46] <pmatulis1> hml, hi. when creating openstack image metadata for juju you need to supply a region. where does that value come from? is that from the region defined via 'juju add-cloud'? is it related to a "project" within openstack?
[17:46] <hml> pmatulis1:  both.  they should be the same.
[17:47] <pmatulis1> ohh
[17:47] <hml> pmatulis1:  you can have multiple regions in the o7k cloud.  and in juju
[17:47] <pmatulis1> o7k?
[17:47] <hml> pmatulis1:  openstack
[17:47] <hml> a shorthand of sorts i’ve seen
[17:48] <pmatulis1> ohh nice
[17:48] <rick_h> k8s, o7k, a11y, wheeee
[17:48] <pmatulis1> right right nice
[17:48] <hml> or i18n
[17:48] <hml> that one really saves you
[17:48] <pmatulis1> what is it for? sorry
[17:51] <rick_h> internationalization
[17:53] <hml> rick_h: ty!  long type.
[17:53] <hml> :-)
[17:53] <pmatulis1> and a11y ?
[17:53] <rick_h> that's my keyboard practive for the day
[17:53] <rick_h> accessibility
[17:54] <rick_h> e.g. https://a11yproject.com/
[17:54] <pmatulis1> ah ha
[17:55] <pmatulis1> hml, so when i do 'openstack project list' i get back 'admin' and 'service'. r u (heh) saying i need to use one of those with 'juju metadata generate-image'?
[17:56] <rick_h> pmatulis1:  not projects, regions. Think us-east-1, us-east-2, etc
[17:56] <hml> pmatulis1:  no, check your novarc file for an OS_REGION
[17:56] <rick_h> pmatulis1:  you can have lots of projects, those are kind of "per user" tenants
[17:56] <rick_h> pmatulis1:  but then you would deploy into your project resources from 1+ regions of the cloud (boston and chicago) or the like
[17:57] <pmatulis1> right, but hml i thought said project and region should be the same above. i must have misunderstood
[17:57] <hml> pmatulis1: no, there are different.
[17:58] <hml> pmatulis1: they
[17:59] <hml> pmatulis1:  you need to match what’s in the cloud definition for your juju o7k cloud, when creating the image metadata
[17:59] <hml> it’ll do an exact string match
[18:00] <pmatulis1> hml, ok, but there is no verification for that variable with add-cloud right?
[18:01] <pmatulis1> so i need to make sure it's correct
[18:01] <hml> pmatulis1:  there is some versionification… to check that the URL is available
[18:01] <hml> pmatulis1:  you can do add-cloud from the OS_ env var which should help
[18:02] <pmatulis1> hml, yeah, i'm working with microstack and stuff is not as normal
[18:02] <pmatulis1> it prolly should be though
[18:02] <pmatulis1> i don't have OS_REGION in my env
[18:02] <hml> pmatulis1:  what does the juju cloud definition look like?
[18:02] <hml> hrm…
[18:06] <pmatulis1> hml, i decided to go cowboy and use 'localhost' since microstack is local. but in the end i've spoken to the developer and we're going to get OS_REGION hardcoded to 'microstack'
[18:07] <pmatulis1> and expose that to the user
[18:07] <hml> pmatulis1:  what happens if you leave the region blank?
[18:07] <hml> on both the simplestreams and the juju cloud def?
[18:08] <pmatulis1> hml, i haven't tried that
[18:13] <pmatulis1> hml, juju command says "ERROR image region must be specified"
[18:14] <pmatulis1> also, add-cloud doesn't work without that region line
[18:14] <hml> pmatulis1:  rgr
[18:20] <pmatulis1> https://bugs.launchpad.net/microstack/+bug/1847649 <-- hml
[18:20] <mup> Bug #1847649: Generating image metadata for Juju could be clearer in terms of Region <MicroStack:New> <https://launchpad.net/bugs/1847649>
[18:28] <hml> pmatulis1:  makes me wonder if anything else is different for add-cloud etc.
[18:48] <nammn_de_> rick_h: wallyworld: as we were talking before. One of you might wanna take a look at this small one?
[18:48] <nammn_de_> https://github.com/juju/juju/pull/10685
[18:50] <rick_h> nammn_de_:  sorry sure thing
[18:51] <nammn_de_> rick_h: No worries, gonna go now anyway. Btw my networ works again with all the beta upgrades :D
[18:51] <rick_h> nammn_de_:  yay!
[18:51] <rick_h> nammn_de_:  have a good night
[19:47] <thumper> hmm... another day where I forget to close IRC
[19:47] <thumper> morning team
[19:48] <hml> morning thumper
[20:16] <rick_h> morning thumper
[20:32] <xavpaice> anyone know if there's a way to export the config of an application in a format compatible with "juju config mediawiki --file path/to/myconfig.yaml"?
[20:41] <rick_h> xavpaice:  if you do the --format=yaml is it not acceptable?
[20:43] <xavpaice> that gives me the same output as 'juju config $application', but if I pipe that to a file, make an edit, then juju config $application --filename theyaml.yaml, it's a totally different layout
[20:43] <xavpaice> I mean, export-bundle, edit, then deploy, should be fine in most cases, just wanting an app config I can 'borrow' from one place and put in another
[20:44] <rick_h> xavpaice:  yea, it should/would be that what you output you can accept
[20:45] <xavpaice> juju config output is really good because it shows all the defaults, and the help, etc - but I can't use that to configure an app, needs a bunch of processing first
[20:46] <rick_h> xavpaice:  yea, understand.
[20:46] <rick_h> xavpaice:  the bundle path is closer but still not going to be right, as you say.
[20:46] <rick_h> xavpaice:  almost want a juju config --values-only
[20:46] <rick_h> or something
[20:46] <xavpaice> yeah, exactly
[20:47] <rick_h> xavpaice:  so not something we currently have but I'm open to a bug on that. In general we've been looking at places where we output one thing but then don't accept it as input
[20:47] <xavpaice> anyway, just a thought - if it was there already, would be handy to know about it, but I guess it's not so I'll just copy/paste out of a bundle
[20:47] <rick_h> xavpaice:  this falls under that umbrella for sure
[20:47] <xavpaice> cool - will scribble up a wishlist bug
[20:47] <rick_h> ty!
[23:53] <hpidcock> https://github.com/juju/juju/pull/10721 2.6 to develop merge