[01:06] <thumper> quick PR for someone https://github.com/juju/bundlechanges/pull/40
[01:17] <thumper> and another https://github.com/juju/gomaasapi/pull/73
[01:17] <veebers> thumper: lgtm on the fist one
[01:17] <veebers> first*
[01:19] <veebers> thumper: reviewed the 2nd, one question and a suggestion ^_^
[01:19] <thumper> veebers: juju/names is the old one
[01:19] <thumper> and not used again
[01:19] <veebers> thumper: ack, makes sense
[01:20] <thumper> yes, many of the things I'm doing need merge jobs
[01:21] <thumper> veebers: there used to be a merge bot... was it the old one?
[01:24] <veebers> thumper: probably, many moons ago. All that old stuff is long gone
[01:24]  * thumper sighs
[01:24] <thumper> I know we went through it last time...
[01:24] <veebers> thumper: it's for the best ;-) Have you done a merge job before? it's pretty straight forward
[01:24] <veebers> and also lots of fun
[01:25] <thumper> lies
[01:25] <veebers> and, uh, helps the environment?
[01:25] <thumper> can you point me to the notes again?
[01:32] <thumper> https://github.com/juju/description/pull/38
[02:15] <wallyworld> veebers: tiny one https://github.com/juju/juju/pull/8706
[02:17] <veebers> wallyworld: hey, no name calling, I might get taller one day. Oh you mean the PR right. What does ?= do, or is it a typo
[02:17] <wallyworld> veebers: it means set if empty
[02:17] <veebers> ack
[02:18] <wallyworld> we also use it for tje docker user name
[02:18] <wallyworld> allow env var to override
[02:19] <veebers> wallyworld: ack, quick question on the pr, looks good to me though
[02:19] <wallyworld> looking
[02:21] <wallyworld> veebers: answer make sense?
[02:21] <veebers> wallyworld: indeed, LGTM
[02:21] <wallyworld> ty
[02:23] <wallyworld> kelvinliu__: veebers: we need to talk at some point about k8s CI testing - the docker operator image needs to be built and uploaded as part of that whole process
[02:24] <wallyworld> i just did it manually for rc1
[02:24] <veebers> wallyworld: ack, there was a brief email thread about that. I'm pretty sure we can fit that into our CI-Run bits easily enough (i.e. add an early step in the build process)
[02:24] <wallyworld> yup, no big issue, just something to add to the todo list
[02:25] <veebers> wallyworld: or is that for a release? (or both, something for each commit and something official for a release)
[02:25] <wallyworld> we'll need to get the qa user to have perms on the jujusolutions repo
[02:25] <wallyworld> both
[02:25] <wallyworld> we need to push somewhere to test prior to release
[02:26] <wallyworld> we can push to a qa namespace and override the source in juju for testing
[02:26] <kelvinliu__> yes, agreed, we could make it automated
[02:39] <kelvinliu__> or should we consider to create a separate dockerhub account for test to avoid some weird thing happened like test flow pushing image to the released image namespace. wallyworld veebers
[02:46] <wallyworld> kelvinliu__: a separate account is what i was thinking yes. there's a controller setting to override the default "caas-operator-image-path"
[02:48] <kelvinliu__> yeah
[02:51] <veebers> wallyworld, kelvinliu__ excuse my ignorance, what is getting pushed? can it be uniquely named? i.e. can I push something named ci-run-abc123?
[02:52] <veebers> (if so) We can then inject that as an env var so the test jobs can pick it up
[02:52] <wallyworld> veebers: it's a docker image for the jujud agent on k8s. it is tagged with the release number
[02:52] <wallyworld> theoretically that would be sufficient
[02:53] <wallyworld> eg if we have released 2.3.7 and are testing 2.3.8 there's no clash
[02:53] <wallyworld> as they have different labels/tags
[02:53] <wallyworld> so they could all live in the jujusolutions namespace. depends on how paranoid we want to be about accidentally overwriting
[02:53] <veebers> wallyworld: but for ci runs where it's the same version but different builds it will need to be unique (ci runs can be run in parallel)
[02:54] <wallyworld> right, hence we'd use the controller config setting
[02:54] <wallyworld> push with a tag and then use that path in the controller config
[02:55] <wallyworld> the image path is <dockerusername>/<imagename>:<tag>
[02:55] <veebers> wallyworld: ah right, if <imagename> can be anything we're sorted
[02:55] <wallyworld> CI tests should not pollute the offcial user namespace with test images
[02:56] <wallyworld> so we'd want to use a qa namespace for that
[02:57] <veebers> having a namespace for ci runs seems nice, de-clutters actual release stuff
[02:57] <wallyworld> yup
[03:53] <wallyworld> kelvinliu__: free for 5 minutes before next meeting, quick chat?
[03:53] <kelvinliu__> yup,
[03:53] <wallyworld> am in standup
[03:58] <thumper> review anyone? kinda simple, just big https://github.com/juju/juju/pull/8707
[03:58] <thumper> 229 files
[03:59] <thumper> very mechanical changes
[04:33] <anastasiamac> could i plz have a review for https://github.com/juju/juju/pull/8709? removing distant relations in status... really simple and straightforward :D
[04:49] <babbageclunk> anastasiamac: looking
[04:49] <blahdeblah> anastasiamac: +1 to feature, and great function names like TestFilterOutRelationsForRelatedApplicationsThatDoNotMatchCriteriaDirectly
[04:49] <blahdeblah> I have no idea whether the code is good or not, though. :-)
[04:52] <babbageclunk> blahdeblah: I'll factor your enthusiasm into the review!
[04:53] <blahdeblah>  👍
[04:54] <anastasiamac> blahdeblah: \o/ i had to look at a test recently that i myself wrote in another life... it took me longer to figure out what it does than to actually write it originally... had to b very explicit here with status ;)
[04:55] <anastasiamac> another simplistic review plz - https://github.com/juju/juju/pull/8710 ... this one just reduces loggin noise :D literally 4 lines of changes maybe...
[04:56] <veebers> anastasiamac: +1
[04:57] <anastasiamac> veebers: ta :)
[05:04] <anastasiamac> babbageclunk: fwiw, i wrote the test first to see it fail with current impl... then fixed the code :)
[05:04] <babbageclunk> anastasiamac: ooh, fancy! Approved.
[05:04] <anastasiamac> babbageclunk: :)
[05:05] <babbageclunk> anastasiamac: hmm, looks like it still fails though?
[05:05] <anastasiamac> babbageclunk: yep :( looking
[05:06] <anastasiamac> babbageclunk: it seems to b racy \o/
[05:06] <babbageclunk> oh stink, I've got a few of those too.
[06:10] <wallyworld> kelvinliu__: tiny review? https://github.com/juju/juju/pull/8711
[06:11] <kelvinliu__> wallyworld, looking now
[06:17] <kelvinliu__> wallyworld, looking all good to me.
[06:17] <wallyworld> ty
[06:17] <wallyworld> i'm happy about the size reduction
[06:17] <kelvinliu__> wallyworld, the image size is much smaller, nice!
[06:18] <wallyworld> indee
[06:18] <wallyworld> d
[06:22] <myrat> hello guys
[09:42] <manadart> Small one for review: https://github.com/juju/juju/pull/8713
[09:43] <myrat> how create a openstack project
[10:37] <manadart> externalreality: Any chance you could take a look at that one? ^
[13:27] <bobeo_> kwmonroe: rick_h_ do either of you know what port the termination port for spiceclient proxy is for nova-cloud-controller? Im having issues with web based access to my project instances, and I know it has something to do with spice and the nova cloud controller, im assuming it needs to terminate on that server, and pass to the novaa servers from there.
[13:54] <kwmonroe> bobeo_: beisner or admcleod_ are my openstack gotos.  one of them might know deats about spice/nova ^^.  you also might want to try asking in #openstack-charms.
[15:06] <admcleod_> bobeo_: you just enable the config option on nova-cloud-controller, then you use the api to get an access url (i.e. openstack console url show instance_id)
[15:09] <bobeo_> admcleod_: how do I "use the api" to get the access url? Via the web UI, it provides a token for the instance, how do I forward for that?
[15:10] <admcleod_> bobeo_: when you say webui what do you mean? openstack dashboard? horizon?
[15:10] <admcleod_> + whats the token?
[15:10] <bobeo_> admcleod_: openstack dashboard (horizon)
[15:11] <bobeo_> it provides a project instance id via /horizon/project/instances/<id>
[15:11] <bobeo_> it also does it via /spice_auto.html?<token>
[15:11] <bobeo_> i figured I could use haproxy to forward for those
[15:13] <admcleod_> bobeo_: do be honest, i dont use horizon, and we typically dont use spice, so anything i could tell you i would read here: https://docs.openstack.org/nova/pike/admin/remote-console-access.html
[16:04] <manadart> Another up for review: https://github.com/juju/juju/pull/8715
[18:59] <bobeo_> kwmonroe: beisner admcleod_ I think i found the issue as to why spice isnt working. I noticed in the nova compute after reading the docs that the update for spice applies at the nova compute, but openstack via openstack dashboard (horizon) processes the connection with the nova cloud controller directly, but I dont see anything that also modifies the connection for spice in the
[19:00] <bobeo_> nova cloud controller. with that being said,a nd with spice expressly requiring vnc settings to be disabled as per openstack docs, this would mean that I dont believe there is a proxy pass to the nova compute nodes, which would create a break inside the config files correct? or am I missing something?
[19:01] <bobeo_> nova compute - http://paste.ubuntu.com/p/DsPF7wRbpW/  nova cloud controller - http://paste.ubuntu.com/p/TH9jNQ6s3B/ with spice configured to be used.
[19:06] <bobeo_> further review shows that the [spice] section inside the nova cloud controller isnt configured with anything for spice in the nova.conf file, even though inside the juju config file, for the nova cloud controller, according to juju, spice is configured.  nova cloud controller config: http://paste.ubuntu.com/p/7bx68YZCW4/   is this another bug?
[19:09] <admcleod_> bobeo_: is there anything for spice in nova.conf on the nova-compute nodes?
[19:13] <bobeo_> admcleod_: yes, which is what makes me think the issue is either with the nova cloud controller config since there is a section for spice in it, but its blank, and horizon forwards to the nova cloud controller
[19:14] <bobeo_> or its with nova cloud controller not proxy forwarding to the nova compute nodes directly, which would simply require the nova cloud controller to proxy to the nova computes. My only question would be how would it know how to do that, except through nova-consoleauth
[19:14] <admcleod_> bobeo_: if you think there is a bug you should definitely log it..
[19:14] <bobeo_> admcleod_: I dont think I would be the best person for that. I honestly dont understand the charms enough to speak well enough for it.
[19:15] <admcleod_> bobeo_: if you think there is a problem, thats understanding well enough - the docs should be clear enough, or things should 'just work'
[19:15] <admcleod_> bobeo_: unfortunately i have less experience with spice + horizon than you do
[19:15] <bobeo_> admcleod_: Ill definitely try then. its done through launchpad right?
[19:16] <admcleod_> yep - if you find the charm you think is at fault on the charm store, there is a link to 'submit a bug' on the right hand side
[19:24] <kwmonroe> bobeo_: +1 to admcleod_'s suggestion for filing a bug -- you definitely don't need to know the inner workings of the charms to do that.  worst case, somebody comes along and says "you're doing it wrong; do it this way".  best case, there's an actual doc/bug that needs fixing.  either way, you'll get unstuck :)
[19:28] <TheAbsentOne> hey guys, is it possible in a bundle to have an option that says how many charms need to be deployed? For example I have charm a, b, c (all of them only once) that all have a relation to charm x. In some cases I only need 1 x but sometimes I need 5 x. Is this possible?
[19:28] <TheAbsentOne> kwmonroe you will probably know that x)
[19:29] <bobeo_> TheAbsentOne: I have seen this done
[19:29] <TheAbsentOne> Ohn cool bobeo_ do you have any docs on that?
[19:30] <bobeo_> TheAbsentOne: I have you one better, https://api.jujucharms.com/charmstore/v5/~elasticsearch-charmers/elk-stack/archive/bundle.yaml
[19:31] <bobeo_> it deploys two seperate instance units of elasticsearch inside the ELK bundle, which if Im understanding correctly is what you are looking to do, except maybe not with ELK
[19:31] <kwmonroe> TheAbsentOne: you lost me on your use case
[19:31] <bobeo_> TheAbsentOne: is that what you were talking about?
[19:31] <TheAbsentOne> haha xD I need to figure out if it's gonna work with multiple units but I really want different machines for it to work
[19:31] <kwmonroe> what is 'x' where you would sometimes need 1 and other times need 5 in the same bundle?
[19:32] <TheAbsentOne> wait I will illustrate it with a pastebin!
[19:32] <TheAbsentOne> x is a charm!
[19:32] <bobeo_> so like -machine 1  ; -machine 2 ; -machine 3
[19:33] <bobeo_> https://api.jujucharms.com/charmstore/v5/openstack-base/archive/bundle.yaml TheAbsentOne
[19:34] <TheAbsentOne> https://pastebin.com/LANAB7pN
[19:34] <TheAbsentOne> yeah bobeo_ that was my first thought too, with machines
[19:35] <TheAbsentOne> But it would be cool if a user of the bundle could give the number of x's that need to be deployed
[19:36] <bobeo_> hmmm..I know after the bundle is deployed they can easily deploy additional units
[19:37] <TheAbsentOne> yeah exactly therefore it's no big deal, it was just a showerthought or rather question x)
[19:37] <TheAbsentOne> thanks for the help though guys!
[19:38] <admcleod_> num_unis
[19:38] <kwmonroe> TheAbsentOne: afaik, there is not a way to do dynamic bundles -- meaning you can't adjust num_units or applications at deploy time.
[19:38] <bobeo_> TheAbsentOne: I think its a great point, especially towards the point that I would like to have isolated instances of postgres in the same model. FOr instance, I have app A that I want to keep data from app B completely isolated from, and have a different config file for. Currently, im required to deploy an additional model so I can deploy additional postgres instances.
[19:39] <kwmonroe> TheAbsentOne: for your use case, you might be better served with multiple bundles.. mybundle-core could have 1 'x' deployed and related.  mybundle-scaled could have 5 'x' deployed and related per your paste.
[19:39] <TheAbsentOne> that's clear kwmonroe, that was basicly my question. Sorry for the poor formulation and yeah multiple bundles or clear instructions for users to edit it to their needs
[19:39] <kwmonroe> bobeo_: you can deploy the same postgres charm multiple times
[19:39] <bobeo_> kwmonroe: yea, id agree with what he said. ELK did something something simliar, and bdx did something like that as well.
[19:40] <bobeo_> kwmonroe: yea, but I want different deployments. for instance, app A, i dont want replication on, app b, I do.
[19:40] <TheAbsentOne> bobeo_: you can deploy the same charm multiple times without issue, just give them a name
[19:40] <TheAbsentOne> ahn I see
[19:40] <TheAbsentOne> and kwmonroe was way ahead of me xD
[19:40] <kwmonroe> yeah bobeo_, what TheAbsentOne said.  you can just pick a different name for the pg deployment
[19:41] <bobeo_> TheAbsentOne: wait, I think I misread that, you mean I can have different charm instances of the same type of charm, like postgres? So I can have postgresA, which has no replicaton turned on in the config, and then postgresB, which does? in the same model?
[19:41] <kwmonroe> yup
[19:41] <bobeo_> kwmonroe: 8O
[19:41] <bobeo_> kwmonroe: can you provide me a command line on that?
[19:42] <TheAbsentOne> juju deploy postgresql postgres-a ; juju deploy postgresql postgres-b
[19:42] <TheAbsentOne> and you will have 2 different machines
[19:42] <TheAbsentOne> available at your command x)
[19:43] <kwmonroe> yup ^^ that's it on the command line.. here it is in a bundle: http://paste.ubuntu.com/p/T2RxVsHJQ2/
[19:43] <kwmonroe> bobeo_: ^
[19:44] <bobeo_> kwmonroe: TheAbsentOne with totally separate postgres configurations? so id do juju config postgres-a for config a and juju config postgres-b for config b?
[19:44] <kwmonroe> yup bobeo_
[19:44] <TheAbsentOne> yep completely different machines
[19:46] <bobeo_> kwmonroe: DATAFARM!!!! I can build replicated databases on the same MODEL!
[19:47] <kwmonroe> it's like i can see the lightbulb burning from here
[19:48] <TheAbsentOne> Haha x) good stuff guys
[19:48] <kwmonroe> :)
[19:50] <bobeo_> juju deploy postgres postgres-a --to lxd:0 && juju add-unit -n 2 postgres postgres-a --to lxd:0 && juju add-relation postgres:peer postgres:peer postgres-a
[19:50] <bobeo_> kwmonroe: TheAbsentOne yes?
[19:50] <bobeo_> replicated triplicate databases on a single machine, machine 0, in lxd.
[19:52] <kwmonroe> bobeo_: once you provide that first name, postgres-a, that's how you'll be referring to it.  so it's not "juju add-unit postgres postres-a", but rather "juju add-unit postgres-a"
[19:52] <TheAbsentOne> yah wanted to say thing, once it gets a name always use the name and not the charm name anymore
[19:52] <kwmonroe> bobeo_: and there's no need to explicitly add the peer relation -- juju does that for you
[19:52] <bobeo_> kwmonroe: oOOOH! So postgres effectively bcomes postgres-a or postgres-b, depending on which one I refer to
[19:53] <kwmonroe> yup bobeo_
[19:53] <bobeo_> so the charm name is not a permanent name, but more so a placeholder name, with the permenant name declared at deployment
[19:53] <bobeo_> OMG!
[19:53] <bobeo_> I CAN HAVE DIFFERENT TYPES OF NOVA COMPUTES!
[19:54] <kwmonroe> yeah bobeo_, postgres-a in your example is what you've chosen for your application name.  it's optional and defaults to the charm name if not specified, but you're welcome to give it whatever you want:
[19:54] <kwmonroe> $ juju deploy --help|head -1
[19:54] <kwmonroe> Usage: juju deploy [options] <charm or bundle> [<application name>]
[20:00] <kwmonroe> bobeo_: i just double checked, and your add-unit won't quite work as written.  juju add-unit -n 2 postgres-a --to lxd:0 would add 2 new postgres-a units, but only the first would go to a new lxd container on machine 0; the second will go to a new machine.
[20:00] <kwmonroe> not sure if that's by design or not.. but to get what you want, you'd have to do:
[20:01] <kwmonroe> juju deploy postgresql postgres-a --to lxd:0 && juju add-unit postgres-a --to lxd:0 && juju add-unit postgres-a --to lxd:0
[20:01] <TheAbsentOne> ohn did not know that
[20:03] <kwmonroe> yeah, that's new to me too
[20:18] <bdx> https://www.dropbox.com/s/g5e85591y1l4ahd/IMG_9161.JPG?dl=0 - just got these 40Gb switches in, looks like they run debian 😓 😓 😓
[20:18] <bdx> have no idea what to do with this lol
[20:18] <wpk> bdx: install Ubuntu? :)
[20:19] <bdx> wpk: definitely crossed my mind
[20:20] <bdx> I'm wondering if its just straight linux networking going on here
[20:21] <bdx> each port shows up as an interface or something
[20:21] <bdx> thats all I can think of ... unless there is some special networking application running
[20:22] <bdx> well I know not the user name and password, so I'm going to have reinstall something on it
[20:23] <zeestrat> bdx: Those Dell/Broadcom S6000?
[20:24] <bdx> ya
[20:24] <bdx> zeestrat: you have experience with these?
[20:24] <kwmonroe> bdx: did you try admin/admin?
[20:25] <bdx> from what I can gather, it looks like they just use they network stack of whatever os you install on it
[20:25] <kwmonroe> Windows For Workgroups!  make it happen bdx
[20:25] <bdx> yes
[20:25] <bdx> tried a bunch lol
[20:26] <veebers> Morning
[20:27] <zeestrat> bdx: Nah, just seen them around. As you say, I think there are a couple of different stacks. Looks like there's some cumulus stuff and https://github.com/Azure/SONiC
[20:28] <bdx> totally, I'm finding a bunch of stuff out there, just another new thing to learn thats all  :)
[20:29] <zeestrat> Any special plans or just TOR?
[20:32] <bdx> ahh, I was hoping these most inexpensive switches could lay the foundation for my SAN
[20:32] <bdx> picked up 3 of them used for < 2k
[20:32] <bdx> :)
[20:33] <bdx> now, now is when I pay the prie
[20:33] <bdx> price
[20:33] <bdx> the price of time
[20:35] <zeestrat> Haha. Man, I do get jealous of the decent used and refurbished market in the US.
[20:35] <zeestrat> What kind of storage you doing?
[20:36] <bdx> I've been grabbing used gear from https://unixsurplus.com and https://www.orangecomputers.com - possibly they will ship to you
[20:39] <bdx> zeestrat: I have a bunch of these https://unixsurplus.com/collections/4u-servers-1/products/freenas-server-36-bay-supermicro-4u-2x-e5-2680-2-8ghz-192gb-2-port-10gbe-sfp-nic
[20:39] <bdx> filled with 6TB drives and ssds
[20:39] <zeestrat> Cool. Most outlets don't ship to eu, nevermind Norway which is outside. Then you get hit with vat and customs
[20:39] <bdx> ahh
[20:40] <bdx> well shoots
[20:41] <zeestrat> Yeah, I remember you showed them last time around. How much a pop? How many disks?
[20:41] <kwmonroe> zeestrat: sounds like you need a 3d printer
[20:41] <kwmonroe> then bdx can just send you a few detail pics and BAM, free switches
[20:42] <bdx> zeestrat: we can devise a plan to smuggle you cheap used hardware from the US
[20:42] <bdx> have  you ever seen the movie "blow"?
[20:43] <zeestrat> Now we're talking. Can I be Penelope Cruz?
[20:43] <bdx> ahhhh sure ....
[20:43] <bdx> haha:)
[20:44] <zeestrat> Forgot how it ends so I figured Johnny Depp bought it in the end
[20:44] <zeestrat> kwmonroe: I'll take my chances printing my own money
[20:45] <kwmonroe> that... that's a terrible idea.
[20:46] <zeestrat> That's exactly what Photoshop said when I tried to scan some bills when I was younger
[20:53] <zeestrat> bdx: got 40g nics in there as well?
[20:58] <bdx> sure do
[20:59] <bdx> 40Gb, 10Ggb, 1Gb, these things are stacked
[21:22]  * thumper blows out
[21:22] <thumper> setting up a merge from 2.3 -> develop
[21:22] <thumper> quite a few conflicts there... wasn't expecting any
[21:22] <rick_h_> thumper: surprise!
[21:23] <thumper> hmm...
[21:23] <thumper> I think these are me reordering and regrouping imports properly
[21:23] <thumper> dumb me
[21:28] <babbageclunk> thumper: no good deed yada yada
[23:13] <admcleod_> thumper: is that anything to do with 2.3.8? :}
[23:14] <thumper> admcleod_: no... it was due to a branch I had which was breaking apart packages
[23:14] <admcleod_> bugger
[23:25] <thumper> admcleod_: all fixed now though
[23:25] <admcleod_> \o/
[23:26] <thumper> well... just checked and no it isn't
[23:26] <thumper> I think I have another conflict
[23:26]  * thumper enfixorates
[23:26] <wpk> thumper: o/
[23:28] <thumper> hey wpk
[23:30] <thumper> ok... I've had enough of this bollocks
[23:31] <thumper> why does 'make pre-check' on my machine fail differently to the merge bot?
[23:31] <thumper> they are both running the verify script
[23:31] <thumper> and both should be using the same go version
[23:32] <thumper> wallyworld, veebers ^^ ? anyone
[23:32] <rick_h_> wpk: what's up?!
[23:33] <veebers> thumper: OTP will look shortly
[23:33] <wpk> rick_h_: not much, not much. watching natgeo, drinking an APA.
[23:33] <rick_h_> wpk: sound like a fine evening.
[23:34] <rick_h_> I'm waiting eagerly for the blue planet ii stuff to drop
[23:43]  * thumper just doesn't understand why his local verify is failing...
[23:45] <veebers> thumper: did you do a make add-patches (or haven't added patches)
[23:45] <thumper> veebers: hadn't added patches
[23:45] <veebers> thumper: or are your local deps been patched when they shouldn't have?
[23:45] <thumper> nope
[23:46] <thumper> veebers: I'm about to head to class, can I grab you after lunch?
[23:46] <thumper> perhaps you can shed light on this
[23:46] <veebers> thumper: sure thing