| wallyworld | veebers: that happens and we just create watcher. don't know why we get dropped | 00:01 |
|---|---|---|
| veebers | wallyworld: ok. I haven't yet reproed the error you saw in your email, gonna leave things running, go to lunch and see if anything pops up | 00:02 |
| wallyworld | veebers: the error happens immediately on deploy for me | 00:05 |
| veebers | wallyworld: do you do anything more than just: juju deploy cs:~veebers/caas-mariadb ? | 01:13 |
| wallyworld | you need storage | 01:14 |
| wallyworld | either static pvs or dynaimic | 01:14 |
| wallyworld | or you can comment out the storage bit to test wothout | 01:14 |
| wallyworld | edit metadata.yaml | 01:15 |
| veebers | wallyworld: ah, I commented out storage. So I need to setup storage somehow to repro? | 01:15 |
| wallyworld | to repro what? | 01:15 |
| veebers | wallyworld: the error you see in the logs | 01:15 |
| wallyworld | which one? | 01:15 |
| wallyworld | there were a couple | 01:15 |
| veebers | wallyworld: or was your comment about neededing storage just regarding deploying that charm | 01:16 |
| wallyworld | yeah, was just about deploying | 01:16 |
| veebers | wallyworld: There was only one in your email, let me grab it real quick | 01:16 |
| wallyworld | sorry, haven't got it paged in | 01:16 |
| veebers | wallyworld: unexpected error: resource name may not be empty | 01:16 |
| veebers | wallyworld: I can deploy that charm (and others) and see no errors at all :-| | 01:16 |
| wallyworld | not even this one? ERROR juju.worker.dependency "caas-unit-provisioner" manifold worker returned | 01:17 |
| wallyworld | unexpected error: resource name may not be empty | 01:17 |
| veebers | (except for WARNING juju.workers.caasunitprovisioner k8s event watcher closed, restarting which I see every 6-8 minutes) | 01:17 |
| veebers | wallyworld: nope, none. | 01:17 |
| wallyworld | hmmm | 01:17 |
| wallyworld | i'll see if i can reproduce | 01:18 |
| veebers | juju debug-log -m controller --replay | grep ERROR comes back clean | 01:18 |
| veebers | wallyworld: oh, which k8s cluster where you using? That shouldn't matter though | 01:18 |
| wallyworld | k8s deployed on top of aws | 01:18 |
| kelvinliu | wallyworld, veebers would you take a look this PR when u got time? https://github.com/juju/juju/pull/8997/files thanks | 01:22 |
| wallyworld | kelvinliu: the jenkins 2.3 and 2.4 builds work? | 01:23 |
| veebers | can do | 01:25 |
| veebers | kelvinliu: the re-run of the unit tests for your test run passed this time around, so the failure seems like an intermittent test not something you're build changes have introed | 01:25 |
| kelvinliu | wallyworld, i think the build was working fine. | 01:26 |
| kelvinliu | veebers, awesome! | 01:26 |
| wallyworld | kelvinliu: i left a few comments | 01:37 |
| veebers | kelvinliu: once you've fixed the operator image job, do a 'resume build' on the latest 2.3 commit to get a full run through | 01:45 |
| kelvinliu | veebers, sure | 01:45 |
| kelvinliu | wallyworld, thanks. looking now | 01:46 |
| thumper | sweet, my branch merged into develop | 02:01 |
| thumper | all that 2.4 goodness | 02:01 |
| thumper | veebers: seems like the merge job for juju/clock is also not talking to github | 02:02 |
| veebers | thumper: aye, they will all need redeployed | 02:02 |
| thumper | ok... are you sorting that? | 02:03 |
| veebers | thumper: I am, I pinged you the PR for the changes, but I'm just going to go ahead and re-deploy it now anyway as that's how I roll | 02:03 |
| * thumper nods, looking now | 02:03 | |
| veebers | I'm def going to template/use a project those jobs on Friday, those 30-ish files could be 2 files | 02:04 |
| veebers | thumper: try again now on the clock PR | 02:04 |
| thumper | veebers: build noticed | 02:05 |
| veebers | sweet | 02:05 |
| thumper | I'll wait for that to complete | 02:05 |
| thumper | (just to be sure) | 02:05 |
| thumper | then merge | 02:05 |
| kelvinliu | veebers, http://localhost:18080/view/ci-run/job/ci-run/1004/console 2.3 buildjob is passing | 02:12 |
| wallyworld | kelvinliu: more dep changes just landed in develop | 02:56 |
| kelvinliu | wallyworld, yes, I saw thumper 's comments. I m fixing an 2.3 build issue now, but it's not related dep change. | 02:58 |
| wallyworld | np | 02:58 |
| kelvinliu | thumper, wallyworld veebers I just sync the toml file from dev branch dependencies.tsv, please a take a look again when u got time, I m going for lunch now, be back soon. | 03:42 |
| thumper | I trust that the build will fail should we be missing things | 03:46 |
| jam | hey wpk, nice to see you around | 03:57 |
| wallyworld | kelvinliu: one thing we will need to do is figure out how to allow people to switch branches, eg git checkout 2.4 will leave the vendor dir in place. and that will mess up the 2.4 build | 05:12 |
| wallyworld | maybe a make target to move it out of the way / rename. we don't want to have to donload the whole lot again when switch back to devleop | 05:13 |
| anastasiamac | kelvinliu: veebers: wallyworld: with ^^ in mind, if m working on 2.3 (or 2.4) do i now neeed to run 'make dep' instead of 'godeps -u dependencies.tsv' locally? | 05:15 |
| wallyworld | anastasiamac: 2.3 and 2.4 will retain use of godeps and you can use via the make target if you want as the makefile is checked in code | 05:16 |
| wallyworld | the issue is how to move the vendor dir out of the way | 05:17 |
| anastasiamac | wallyworld: nice. thnx | 05:17 |
| wallyworld | as that will mess with the 2.3 and 2.4 builds | 05:17 |
| kelvinliu | wallyworld, the dependencies are cached on local, so rm -rf vendor then run make dep will not be too slow | 05:19 |
| anastasiamac | wallyworld: i see. m guessing ur saw rog's suggestion in the doc on how to deal with it | 05:19 |
| kelvinliu | anastasiamac, if u work on 2.3 or 2.4, u can just follow previous workflow, either use make dep/godeps or godeps -u dependencies.tsv | 05:21 |
| anastasiamac | kelvinliu: yep, got it :) | 05:21 |
| kelvinliu | anastasiamac, all should be working fine | 05:21 |
| wallyworld | i haven't seen the doc update yet | 05:21 |
| kelvinliu | anastasiamac, actually 2.3 2.4 is still using godeps. | 05:22 |
| anastasiamac | kelvinliu: when u say "still" do u mean, they will keep use it? :D | 05:23 |
| kelvinliu | anastasiamac, yes. unless we want to migrate 2.3 and 2.4 to dep | 05:24 |
| anastasiamac | kelvinliu: ack | 05:25 |
| wallyworld | jam: thumper: so rog has suggested a bash script to move vendor dirs from upstream repos away before doing a build. http://paste.ubuntu.com/p/fVBJXMnbdf/ But that seems rather error prone to me and is working against the grain. I think we are better off just embracing upstream tooling rather than coming up with a workaround to compound the issues with using a homegrown solution. Agree? | 05:28 |
| jam | wallyworld: so that is 'for everything in $GOPATH hide vendor/ when building and then restore wehn we're done' ? | 05:30 |
| wallyworld | everyhting in dependencies,tsv | 05:31 |
| wallyworld | every upstream in there | 05:31 |
| wallyworld | you may have other stuff in gopath | 05:31 |
| jam | wallyworld: and this is *instead* of using dep ? | 05:31 |
| wallyworld | yeah | 05:31 |
| wallyworld | i thik he's trying to find a workaround to not switch to it | 05:32 |
| wallyworld | i haven't tried the swrript, i only just noticed it as a comment on the googel doc | 05:32 |
| wallyworld | i can see though ways thing could mess up, eg you moved the vendor dirs, then updated dependencies.tsv; you can end up with your upstream repos messed up if stuff is removed from dependencies.tsv etc. just more moving parts to go wrong | 05:36 |
| kelvinliu | veebers, i think the branch check condition issue has been solved. http://localhost:18080/view/ci-run/job/ci-run/1014/ http://localhost:18080/view/ci-run/job/ci-run/1010/ | 05:36 |
| veebers | kelvinliu: ok will check shortly, just truing to get this streams stuff sorted | 05:36 |
| kelvinliu | veebers, thx | 05:37 |
| wallyworld | kelvinliu: did you see my question about how we deal with switch branches? | 05:39 |
| kelvinliu | wallyworld, yes, I did. sorry, I relied to anastasiamac only | 05:40 |
| kelvinliu | wallyworld, if u work on 2.3 or 2.4, u can just follow previous workflow, either use make dep/godeps or godeps -u dependencies.tsv | 05:40 |
| wallyworld | kelvinliu: oh sorry, you included me, i missed it | 05:41 |
| wallyworld | what i meant was not that | 05:41 |
| kelvinliu | ah, typo, make godeps but no make dep | 05:41 |
| wallyworld | but when you git checkout 2.4 branch, the vendir dir will interfere with the build | 05:41 |
| wallyworld | so it needs to be moved out the way | 05:41 |
| wallyworld | when you say thinsg are cacheed loally, where is that? | 05:42 |
| kelvinliu | wallyworld, in this case, we either gitignore vendor in 2.3/2.4 or rm -rf vendor. the dependencies are cached on local, so rm -rf vendor then run make dep will not be too slow | 05:42 |
| wallyworld | will it really be fast to rm -rf vendor and then later run dep ensure again? | 05:42 |
| wallyworld | gitignore vedor will not do anything | 05:42 |
| wallyworld | as the dir will still be there right? | 05:43 |
| wallyworld | it will just be untracked in git | 05:43 |
| kelvinliu | wallyworld, ll $GOPATH/pkg/dep | 05:43 |
| wallyworld | so if that is the case and dep ensure is fast, we need a make target to remove vendor or something | 05:44 |
| wallyworld | and that will need to be in the 2.3 and 2.4 makefiles | 05:44 |
| kelvinliu | wallyworld, vendor is just files copied from this cache dir but not git repos. so dep cache the git repos in there to do version ensuring | 05:44 |
| wallyworld | and we'll need to document that workflow | 05:44 |
| wallyworld | ok, we were fearful that dep ensure would dowmload everything from upstream | 05:45 |
| wallyworld | after the vendor dir was removed when swiching to 2.4 and back to develop | 05:45 |
| kelvinliu | wallyworld, ic. i am thinking currently we need to run make godeps to ensure the correct revisions after switch branches because 2.3 and develop branches could have different dependencies.tsv. | 05:48 |
| veebers | thumper, wallyworld would you mind giving this a quick eyeball and a +/- 1? This is an update to the scripts jerff uses, and an update to them: http://paste.ubuntu.com/p/vmPJvP2nMx/ | 05:49 |
| wallyworld | kelvinliu: indeed we will and that is what we do now each time. but when switch from develop we will *also* need to move the vendor dir | 05:50 |
| kelvinliu | wallyworld, if we have vendor gitignored on 2.3, 2.4 and develop branches. it will solve this problem? | 05:51 |
| wallyworld | how? | 05:51 |
| wallyworld | gitignore doesn't remove the dir when switch branches does it? | 05:51 |
| wallyworld | if there's a vendor dir there, it will still be there after git checkout 2.4 | 05:52 |
| kelvinliu | wallyworld, if it's ignored, we don't need remove it | 05:52 |
| wallyworld | what stops go build from using it? | 05:52 |
| wallyworld | surely not gitignore? | 05:53 |
| kelvinliu | wallyworld, ah, u r right.. | 05:53 |
| kelvinliu | wallyworld, unless we commit the vendor, but it would be too big for us | 05:53 |
| wallyworld | right, hence the suggestion to adjust the make targets for godeps in 2.3 and 2.4 make files to rm -rf vendor | 05:54 |
| kelvinliu | wallyworld, well, we can just rm -rf vendor in make godeps target | 05:54 |
| wallyworld | that way the workflow will be the same across all branches | 05:54 |
| wallyworld | so we'll need a 2.3 and 2.4 PR | 05:54 |
| wallyworld | the assuption is that dep ensure a second time ia very fast | 05:55 |
| wallyworld | assuming stuff is cached like you say | 05:55 |
| kelvinliu | wallyworld, yes, it's fast | 05:55 |
| veebers | wallyworld, thumper if you have no issues with it I'll push and get hatch to try again (it's late for him and I need to get dinner sorted for the boy :-)) | 05:55 |
| wallyworld | veebers: looks ok at first glance | 05:56 |
| veebers | actually, this diff now as I sorted out 2 small issues http://paste.ubuntu.com/p/XvMm34HKVF/ | 05:56 |
| veebers | wallyworld: sweet, I'll push it up and try it, if it fails I'll revert it and try again later (tonight or tomorrow) | 05:56 |
| wallyworld | sgtm, no harm if there's an issue | 05:57 |
| wallyworld | veebers: you happy that we are good with the dep stuff? | 05:57 |
| kelvinliu | wallyworld, well, it's fast if we think ~10s is not too slow | 05:57 |
| wallyworld | that's reasonable, it takes godeps a few seconds sometimes | 05:58 |
| wallyworld | is that on an SSD? | 05:58 |
| anastasiamac | could I get a review plz on https://github.com/juju/juju/pull/9035 - tiny check to ensure local charms have hooks at deploy | 05:58 |
| kelvinliu | wallyworld, yes. half of the time was for dep to figure out the revision to copy to | 05:58 |
| wallyworld | i can like with 10s personally | 05:59 |
| anastasiamac | wallyworld: thumper: this PR (9035) will b heading into 2.3 and 2.4 if we can/like | 06:00 |
| veebers | wallyworld: yep, it looks like kelvinliu has the ci-run bits sorted | 06:00 |
| wallyworld | ok, gr8 ty | 06:01 |
| wallyworld | kelvinliu: since it's EOD soon let's land tomorrow so we can get discourse post etc sorted out | 06:01 |
| wallyworld | and not rush | 06:01 |
| kelvinliu | wallyworld, yup | 06:03 |
| wallyworld | anastasiamac: done, ty, IS wil be happy | 06:07 |
| anastasiamac | wallyworld: re: error and suggestion to build charm... we rarely make suggestions in errors coming from api (which this one is)... and digging in deploy command will be to snow-flaky... so to compromise, we could rename this error to say "poorly built charm:.." instead of "invalid charm:..." | 06:12 |
| anastasiamac | what do u think? | 06:12 |
| wallyworld | invalid charm is probaly ok, cause that's what it is | 06:14 |
| anastasiamac | ack | 06:14 |
| anastasiamac | i was tossing and turning btw one and the other all day... at the end went with "invalid" coz it felt moer definitive, final almost.. whereas "poorly built" implied "hey, u've tried to built it but did such a bad job of it, we have to b polite here" | 06:16 |
| wallyworld | inalid works for me | 06:16 |
| anastasiamac | +1 | 06:17 |
| veebers | wallyworld, thumper: after a couple iterations need to make this change: http://paste.ubuntu.com/p/rsKTJh5XMF/ | 06:34 |
| veebers | wallyworld, thumper FYI the fixes worked, the gui release/streams is sorted | 06:45 |
| wallyworld | veebers: thank you | 07:21 |
| naturalblue | Hi Everyone. I asked this question over on #maas but was redirected to ask it here. I hope someone can help. | 08:17 |
| naturalblue | It's about maas with juju lxds and maas's builtin proxy feature | 08:18 |
| naturalblue | I have setup maas and juju. I have multiple VLANS and all of them have a gateway address on the maas controller. I have enabled builtin proxy but when I juju deploy an lxd container the proxy settings are not configured and i have to manually enter the lxd and create/add the maas proxy settings into apt.d/proxy.conf file | 08:18 |
| naturalblue | i have been told that possible juju is not setting the inherited maas proxy setting sent down by maas. Any help would be appreciated. | 08:19 |
| wallyworld | jam: ^^^^ ? i can't recalloff hand the supported behaviour | 08:25 |
| jam | naturalblue: juju has model-config for apt-proxy and http-proxy. You need to set them for Juju to set it on the containers it creates. We don't auto-populate the values from maas. | 08:26 |
| naturalblue | jam: ah i see. What happens if you have some lxds that need 1 proxy because they only have some bindings and others that have different bindings. Is it possible to set and apt-proxy setting to a specific lxd on deployment | 08:32 |
| jam | naturalblue: we don't support per-machine/per-container proxy settings atm. | 08:35 |
| naturalblue | jam: so if i have different containers that have different bindings I will need to make manual changes to apt/apt.d/juju-proxy.conf to reflect this. It's not so bad | 08:38 |
| naturalblue | jam: i last thing. Is there a way to see the network settings for all units in a model. I wish to see if all machines/units/lxds have 1 common binding that i could use in the model-config and circumvent having to change multiple apt config files | 08:39 |
| jam | naturalblue: juju status --format=yaml I believe lists bindings for applications. But that would be newly introduced in 2.4, IIRC. | 08:51 |
| naturalblue | i am on 2.4 so i will give it a go | 08:52 |
| naturalblue | jam: thats a cool command unfortunately it only shows the public-addresses and none of the other. Still handy to have though. Thanks | 08:53 |
| naturalblue | jam: I added the proxy settings into the model-config and redeployed the lxd units. it passed down the https and ftp into the 95-juju-proxy-settings file but for some reason didn't pass the http setting. | 09:50 |
| jam | naturalblue: can you give the output of "juju model-config" for me ? | 09:55 |
| naturalblue | ok | 09:56 |
| naturalblue | will i paste it here or pastebin | 09:56 |
| naturalblue | jam: will i paste it here or pastebin | 09:56 |
| jam | pastebin is good | 09:56 |
| naturalblue | col | 09:57 |
| naturalblue | jam: https://pastebin.com/PbpmtTuK | 09:58 |
| jam | naturalblue: you didn't set apt-http-proxy or http-proxy | 09:58 |
| naturalblue | theres something not right there. i did set them and when i ran the command earlier it showed them all being set. | 10:00 |
| naturalblue | that paste also shows that https is not set but it was and has actually been passed down to the lxd containers | 10:01 |
| naturalblue | i set them using the command "juju model-default apt-http-proxy=http://172.30.100.1:8000". i did this for apt-http/https as well as juju-http/https | 10:02 |
| naturalblue | for some reason all the config settings for http & https have gone but the ftp has stayed | 10:02 |
| naturalblue | i must have ran acommand somewhere that set them back to the default rather than the one i wanted. i am still not sure the difference between juju model-config, juju model-default and juju model-defaults | 10:04 |
| naturalblue | it would seem that although there are 2 commands juju model-default and juju model-defaults they are both identical in what they do | 10:11 |
| naturalblue | jam: https://pastebin.com/rTcSL9PT This shows all the settings correct (juju moel-defaults comand) but the other command (juju model-config) only shows the ftp settings | 10:13 |
| manadart | jam: externalreality approved it yesterday, but I've made some additions. Mind taking another look at https://github.com/juju/juju/pull/9029 ? | 10:23 |
| jam | manadart: will do | 11:32 |
| jam | naturalblue: you'll need to "juju model-config --reset apt-https-proxy" etc. The value from model-defaults is snapshotted when the model is created, and only used again if you reset the value | 11:32 |
| naturalblue | jam: Yeah thanks. I worked it out and removed all the excess proxys using juju model-default --reset juju-http-proxy,juju-ftp-proxy etc | 11:36 |
| naturalblue | then i redepoyed the model. at first i removed the http-proxy etc instead of the juju-http-proxy but found everything just got stuck on initialising agent, so tried again with http-proxy instead of juju-http-proxy and its working away now. i'll see how it goes | 11:37 |
| jam | naturalblue: if you set 'juju-http-proxy' then juju will set a JUJU_HTTP_PROXY value for the charms to use, but it *won't* set HTTP_PROXY | 11:44 |
| jam | naturalblue: its been a discussion since often charms actually need to enable and disable the proxy because NO_PROXY doesn't work the way you would like | 11:45 |
| jam | (all of the C libs only support exact IP matches, not CIDR, which means you can't just say "don't proxy everything in the local datacenter") | 11:45 |
| stub | cory_fu: Can we release a charms.reactive update? PostgreSQL charm is failing under trusty, fixed by https://github.com/juju-solutions/charms.reactive/commit/328ae1b2f69f07059b17766a9db0586c3243cc14 | 11:46 |
| stub | I think I can bump the version number and push it to pypi if we are good | 11:47 |
| stub | I can release just up to my commit if the series upgrade stuff needs more baking | 11:51 |
| naturalblue | jam: Thanks for the help. Everyday's a schoolday :) It's working now and the deploymets have worked for me. Now to debug the openstack services themselves. | 12:43 |
| naturalblue | Thanks again | 12:43 |
| jam | naturalblue: happy to help. I'm glad you got it working. | 12:44 |
| cory_fu | stub: +1, let's do it | 12:51 |
| stub | cory_fu: ta. HEAD or just up to that commit? | 12:52 |
| cory_fu | stub: Up to HEAD, I think. I don't think the upgrade series flags will affect anyone who doesn't want to start testing them. | 12:53 |
| cory_fu | stub: Also, you'll want to update the VERSION file and changelog | 12:54 |
| stub | cory_fu: Shall I call that 'preliminary support for operating system series upgrade'? | 12:54 |
| stub | (in the changelog) | 12:54 |
| cory_fu | Yeah, that sounds good | 12:54 |
| stub | Technically that will be a new feature, so 0.7.0. Or do I get to call this 1.0.0 ? | 12:55 |
| cory_fu | stub: :) I'm not really sure why we've been holding off on calling it 1.0.0, other than potentially reserving that for breaking changes. I'm not averse to making the switch. | 12:56 |
| cory_fu | stub: Oh, I think layer:basic might be range-pinned to <1.0.0 | 12:57 |
| cory_fu | stub: Nope, it's charms.reactive>=0.1.0,<2.0.0 | 12:57 |
| cory_fu | stub: GTG if you want to pull that trigger. :) | 12:57 |
| stub | k | 12:57 |
| cory_fu | stub: Speaking of layer:basic, did you see my reply to the issue you opened about the import stuff. Would you like to discuss that further? I'm still leaning toward it being better than not but if it's causing problems or seems like really bad form, I'd like to try to resolve it | 13:00 |
| stub | cory_fu: I was going to think further and do some tests. | 13:01 |
| cory_fu | stub: Ok, sounds good. Let me know what you find. | 13:01 |
| stub | cory_fu: I can come up with some rationalizations, but they might just be me not liking stuffing everything into charms.layer in the first place. | 13:01 |
| stub | cory_fu: I submitted an issue on layer:status, which looks like it is relying on naming convensions, with a way of avoiding that need. | 13:02 |
| cory_fu | stub: Fair enough. It suits my mental organizational scheme better but it was always intended as a convention and not a hard rule. | 13:03 |
| cory_fu | I honestly thought that more people would use external libraries rather than every single layer embedding a small lib. | 13:03 |
| cory_fu | But I've never done that myself, either, so... | 13:03 |
| stub | With layers and interfaces requiring separate repos, there is already too much to juggle. | 13:04 |
| cory_fu | Yeah | 13:04 |
| stub | And if we could stuff them together in shared repos, you don't need external libraries because they can share code already | 13:04 |
| stub | So when interface:pgsql can point to a subdir of the pg charm source, I stop needing an external library to share my helpers like the ConnectionString class. | 13:05 |
| stub | https://github.com/juju-solutions/charms.reactive/pull/187 | 13:20 |
| stub | cory_fu: ^^ (tests pass locally, but I'll see what travis says too) | 13:20 |
| * stub twiddles formatting | 13:22 | |
| hml | stickupkid: I’m not having issues with localhost and develop: https://pastebin.canonical.com/p/cbHKgszbz2/ | 13:36 |
| hml | stickupkid: which version of the lxd snap are you using? | 13:36 |
| drcode | hi all | 13:36 |
| drcode | I got strange error: bootstrap.go:538 failed to bootstrap model: cannot start bootstrap instance: unexpected: ServerError: 400 Bad Request | 13:37 |
| drcode | any idea? | 13:37 |
| stickupkid | hml: 3.3 as well, i'll restart :p | 13:37 |
| drcode | I am using MAAS + juju in virtualmachine | 13:37 |
| drcode | juju command: juju bootstrap maas-cloud maas-cloud-controller --bootstrap-series=bionic | 13:38 |
| stickupkid | hml: thanks for this, was about to go down a rabbit hole | 13:39 |
| hml | stickupkid: did a restart work? | 13:40 |
| stickupkid | hml: i'll do it in a bit | 13:40 |
| hml | stickupkid: my lxd config has been up and running for a long time, haven’t re-setup since then | 13:41 |
| stickupkid | hml: k, thaknk | 13:42 |
| stickupkid | s/thaknk/thanks/ | 13:42 |
| drcode | what I am doing wrong? | 13:46 |
| drcode | Ce faci? | 13:48 |
| rick_h_ | drcode: try with --debug to see what it's trying to do. That feels like a cloud api call that got told no for some reason | 13:49 |
| rick_h_ | drcode: so we would need more info on what cloud/etc you're doing | 13:49 |
| drcode | can I past is here? | 13:50 |
| rick_h_ | drcode: I'd suggest using a pastebin like https://paste.ubuntu.com/ | 13:56 |
| drcode | thank you | 14:09 |
| drcode | https://paste.ubuntu.com/p/G2pZZwn6Rd/ | 14:11 |
| anastasiamac | drcode: is ur maas install configured to have bionic images? | 14:22 |
| stickupkid | manadart: you got 5 minutes, in about 30 minutes, to pick your brains before end of day for you? | 14:24 |
| manadart | stickupkid: Sure, just say when. | 14:29 |
| stickupkid | hml: worked after restart | 14:36 |
| drcode | I will check it , is it recommanded to use bionic? | 14:36 |
| hml | stickupkid: nice | 14:36 |
| drcode | do I need to setup NAT in MAAS , or juju can use MAAS proxy? | 14:37 |
| anastasiamac | drcode: u r asking for it according to ur msg: [23:38:39] <drcode> juju command: juju bootstrap maas-cloud maas-cloud-controller --bootstrap-series=bionic | 14:39 |
| drcode | ok | 14:39 |
| drcode | I think I had problem with NAT | 14:40 |
| drcode | Can I tell juju to use MAAS proxy? | 14:40 |
| manadart | hml: I was able to clear the test Neutron model networks in the end; see what you think. | 14:46 |
| hml | manadart: ack, i’ll take a look | 14:46 |
| stickupkid | manadart: now? HO? | 14:47 |
| manadart | stickupkid: Ja. | 14:47 |
| hml | rick_h_: when you get a chance, i think i have the pr comments resolved if you could pls take a 2nd look. ty! https://github.com/juju/juju/pull/9015/commits/462a644b24ab064b4ae9172e328867db428d2d96 | 20:07 |
| rick_h_ | hml: cool ty looking | 20:07 |
| hml | rick_h_: it helped once i stopped the square peg round hole problem :-) | 20:09 |
| rick_h_ | hml: good to hear | 20:09 |
| rick_h_ | hml: do we still test if the cert is parse-able? | 20:10 |
| rick_h_ | hml: or am I missing that in there? | 20:10 |
| hml | rick_h_: yes… - it’s checked when the filename is given | 20:10 |
| hml | rick_h_: pollster now allows a VerifyCertFile to be provided | 20:11 |
| rick_h_ | ah doh, yea right after it's read. missed it | 20:11 |
| hml | rick_h_: not intuitive just reading the code. ;-) | 20:11 |
| rick_h_ | hml: it's not bad, I just missed it. | 20:12 |
| veebers | Morning all o/ | 20:40 |
| hml | veebers: morning | 20:42 |
| veebers | hey hml o/ hows things this morning (also known as afternoon in some places ;-)) | 20:47 |
| hml | veebers: good. and u? | 20:47 |
| veebers | hml: all good, it's a bit cool but have the fire going | 20:48 |
| thumper | fyi, https://bugs.launchpad.net/juju/+bug/1786099 in 2.4.2 proposed | 21:51 |
| thumper | I'm aware and looking at it | 21:51 |
| thumper | it is a bit icky... | 21:51 |
| thumper | let's just say there is an easy and wrong fix | 21:51 |
| veebers | kelvinliu__: did you happen to push your ci-run changes up? | 22:12 |
| thumper | where's wally? | 23:00 |
| kelvinliu__ | veebers, yes | 23:03 |
| kelvinliu__ | veebers, i did | 23:03 |
| veebers | kelvinliu__: sorry as in merge it to master? | 23:03 |
| kelvinliu__ | veebers, ah, im going to merge if u r happy | 23:18 |
| veebers | kelvinliu__: yes please | 23:23 |
| veebers | I'm going to be doing updates to ci-run so don't want to overwrite your changes | 23:23 |
| kelvinliu__ | veebers, do it now, thx | 23:23 |
| kelvinliu__ | veebers, done. | 23:24 |
| veebers | mean, cheers | 23:24 |
| wallyworld | thumper: want a teady bear still? | 23:41 |
| anastasiamac | wallyworld: if thumper does not have ur attention, can i? | 23:48 |
| wallyworld | guess so | 23:49 |
| wallyworld | i you insist | 23:49 |
| anastasiamac | yes, m draging u into a corner.. standup? | 23:49 |
| wallyworld | ok | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!