/srv/irclogs.ubuntu.com/2018/04/16/#juju.txt

jamwallyworld: balloons: thumper: it seems Bionic bootstrap broke over the weekend. I have one bug that may have been there for a while, and one where it looks like they dropped an old package from bionic06:19
jamIt seems a different package provides what we wanted, but we just always installed it from the old place06:19
wallyworldjam: do you have details?07:04
jamwallyworld: bug #1764264 I have a patch up07:05
mupBug #1764264: bionic cloud-init 18.2 refuses Juju's 'runcmd' stanza <bionic> <juju> <cloud-init:New> <juju:Triaged> <juju 2.3:Triaged> <https://launchpad.net/bugs/1764264>07:05
jamwallyworld: sorry, wrong bug07:05
jambug #176426707:05
mupBug #1764267: python-software-properties not found on bionic <bionic> <bootstrap> <juju:In Progress by jameinel> <juju 2.3:In Progress by jameinel> <https://launchpad.net/bugs/1764267>07:05
jamwallyworld: https://github.com/juju/juju/pull/860207:06
wallyworldlooking07:06
jam(the former is also an issue on bionic, I'm trying to sort out how big of a deal it is)07:06
wallyworldjam: lgtm, a small change :-)07:08
jamwallyworld: thanks.07:10
=== frankban|afk is now known as frankban
balloonswallyworld, jam, so roll both changes into 2.3.6 or ?09:02
jamballoons: what are you doing awake ? :)09:02
balloonsGood morning! ;)09:03
wallyworldballoons: i still haven't had a chance to look at the potential dry-run regression09:03
wallyworldno commits i can see since 2.3.5 touch that area, but i could be wrong09:04
balloonsI was thinking perhaps do the 2.4-beta1 first, since we have a queue to do09:05
balloonsYea, the dry run regression is weird. We fixed that09:06
balloonsjam, will you roll back the juju version in a PR so we're 2.3.6?09:07
jamballoons: yeah, I can roll it back.09:07
jamballoons: though we have a number of actual bugs with real Bionic support I'm finding out, so maybe we don't want to block 2.3.6 on that09:08
jamand instead we just say "not fully supported" yet, and wait for 2.3.7 or something09:08
balloonsYea, the goal was to not break on bionic, not so much support it09:08
balloonsSo 2.3.6 is already primed at that commit. Easy to finish09:09
jamballoons: so basic support is just broken on bionic with https://launchpad.net/bugs/176426709:15
mupBug #1764267: python-software-properties not found on bionic <bionic> <bootstrap> <juju:In Progress by jameinel> <juju 2.3:Fix Committed by jameinel> <https://launchpad.net/bugs/1764267>09:15
jamballoons: at least, I see we try to install a package that just isn't there anymore09:15
balloonsYea, that one is pretty straightforward09:19
jamballoons: so, should we roll back to 2.3.6 and then release with the package fix, or just release and say bionic not supported in 2.3.6?09:26
jamwallyworld: so I'm trying to merge 2.3 into develop, but 'cmd/juju/commands/resolved.go' was deleted in 2.4. it got moved to application/resolved.go09:28
balloonsjam, I think it's a hard call. If 2.4 is delayed to long, saying upgrade for support is harder09:28
jamwallyworld: do you know how your NoRetry is supposed to be in 2.4? Did you land the fix directly there?09:28
balloonsBut that was the original intent09:28
jamballoons: well, I've always wanted us to support bionic in 2.3 and netplan support *is* there. Just I found about 4 other bionic support bugs while testing it today09:28
balloonsYea everyone else wanted to stick with xenial, which 2.3.6 as is does do09:30
jamwallyworld: it looks like your fix was to pass !c.NoRetry instead of c.NoRetry, which looks to already be done in 2.409:31
jammanadart: just to confirm, if I just resolve the lxd conflicts in favor of the 2.4 code, you're ok with that, right?09:32
manadartjam: Yeah, I can interrogate and apply what is required.09:35
jammanadart: container/lxd/lxd_test.go seems like makeManager is a pretty big ball of differencees09:37
jamin 2.4 it starts taking a string param, and you changed it to take a baseConfig() param09:37
jammanadart: although, it looks like the name string was always ignored09:38
jamin 2.409:38
jam... weird09:38
manadartjam: Ignored in 2.3 as well. I think my change should be OK after-the fact if you resolve in favour of 2.4.09:42
manadartFrom my PR that should leave lxd.go and lxd_test.go untouched.09:43
manadartShould still build/pass yes?09:43
jammanadart: so I'm just doing "git co HEAD lxd.go lxd_test.go" so it forces it specifically to 2.4. merging lxd.go was trying to pull in "Remote" from the 'lxdclient' which wasn't being imported into container/lxd.go anymore so I'm just punting09:46
jammanadart: export_test.go also needed to be reverted.09:47
manadartjam: Ah, yes.09:48
jammanadart: https://github.com/juju/juju/pulls/8606 is on its way to be merged. You could base your work off of that if you wanted, or you can wait for it to land10:20
jambut the container/lxd stuff is just upstream/develop so you can probably work from there already10:21
manadartjam: Thanks.10:39
jammanadart: it has now landed10:52
jammanadart: heads up (can you review) https://github.com/juju/juju/pull/860912:07
manadartjam: Yep.12:08
jammanadart: its trying to make a much smaller patch vs upstream lxd, so we can more easily transition.12:08
jamwpk's patch was rejected in favor of a different approach, so eventually we'll have to follow along. But presumably we can't do anything until we can update to master tip of lxd12:09
manadartjam: Approved.12:16
jammanadart: https://github.com/juju/replicaset/pull/6 and https://github.com/juju/replicaset/pull/7 if you could be so kind14:25
manadartjam: OK. Opened https://github.com/juju/juju/pull/8610 over here too.14:35
=== deanman_ is now known as deanman
manadartjam: Approved both. 1 trivial comment.14:53
bdxcharm build failure alert https://paste.ubuntu.com/p/PfBYVHMFy8/16:22
bdxanyone else failing to get the setuptools wheel?16:22
bdxhttps://files.pythonhosted.org/packages/20/d7/04a0b689d3035143e2ff288f4b9ee4bf6ed80585cc121c90bfd85a1a8c2e/setuptools-39.0.1-py2.py3-none-any.whl16:22
bdxseems to be working now16:47
rick_h_bdx: so python community rolled over to the new pypi site today16:50
rick_h_bdx: first redeploy/new software in 10yrs16:50
rick_h_bdx: so there's going to be some rough spots in python community packaging access today heh16:50
bdxrick_h_: ahhh good to know, thanks16:51
rick_h_yea, I know a few things getting bit by the big upgrade today16:51
bdxalso hitting this in apt install charm package https://github.com/juju/charm/issues/24016:51
rick_h_bdx: hah, yea that packaging is a new upgraded pip version16:51
bdxI'll keep that in mind as I go about my way16:51
rick_h_I wonder if that hit as well16:51
rick_h_cory_fu: ^16:52
rick_h_I wonder if the pip is the dstro, from the pypi, or something else used there16:52
cory_furick_h_, bdx: I hit that today as well when running some tests.  Doing a manual `sudo pip install --upgrade pip` to pick up 10.0.0 fixed it for me.  We might need to rebuild the charm snap16:54
bdxcory_fu: cool, the charm snap doesn't exhibit ^16:54
cory_fubdx: If you got the error during charm build, then I think it's the version of pip inside the charm snap that's causing the issue16:55
bdxahh, but I only get it with apt installed snap16:56
bdxgeh16:56
cory_fubdx: Mainly because that's what the venv is seeded with16:56
bdx* apt installed charm16:56
cory_fuHrm16:56
cory_fuI see16:56
cory_fuSo yeah, apt package of charm is pretty outdated16:56
bdxyeah, the snap has the pip wheel staticly defined in there16:56
admcleod_so i have a MAAS controller deployed, and ive also manually added an s390x machine to it (lts call that machine 0)17:44
admcleod_in my bundle i have 2 charms, charm-x86 and charm-s390x. i use constraints: arch=s390x for the latter charm17:45
admcleod_when i deploy the bundle, it attempts to request a machine of s390x arch from MAAS, rather than use the manually added machine17:45
admcleod_is this expected behaviour?17:45
=== narindergupta is now known as canonical
admcleod_that behaviour is the same whether i use map-machine=existing or not17:50
admcleod_however, if i just deploy the charm directly, it works.17:50
admcleod_guess ill log a bug17:51
ejathi ...17:53
cory_fuejat: Can you repeat the OpenStack credential error you were getting when trying to use your OpenStack with Juju?17:53
ejatPlease ensure the credentials are correct. A common mistake is17:53
ejatto specify the wrong tenant. Use the OpenStack "project" name17:53
ejatfor tenant-name in your model configuration.17:53
cory_fuadmcleod_: You might need to use the --map-machines option to juju deploy to get it to use the pre-created machine17:54
cory_fuadmcleod_: Otherwise, requesting a new machine for the bundle is the expected behavior17:54
admcleod_cory_fu: yeah, it doesnt work with the bundle17:54
admcleod_cory_fu: with or without map-machines17:54
cory_fuadmcleod_: Odd.  I would have expected --map-machines to do what you want17:55
admcleod_cory_fu: same. bug on its way17:56
cory_fuejat: And, did you add the OpenStack credential using `juju add-credential`, `juju autoload-credentials`, or `conjure-up`?17:57
ejatjuju add-credential17:57
ejatadd cloud 1st then add-credential17:58
cory_fuejat: Hrm.  I don't have an OpenStack to test with, but the error message makes it sound like something was entered incorrectly.  Are you sure you chose the correct auth-type and typed everything in correctly?  You could try using `juju add-credential <cloud> --replace` and type it in again18:06
ejattenant-name == project name ?18:07
ejator using the project ID ?18:07
cory_fuYeah, the message said project name, so I'd try that if you used something different previously18:08
ejatbugs 154326218:08
mupBug #1543262: keystone V3 support needed <openstack-provider> <uosci> <Go OpenStack Exchange:Fix Committed by wallyworld> <juju:Fix Released by wallyworld> <juju 2.1:Fix Released by wallyworld> <https://launchpad.net/bugs/1543262>18:08
ejatits almost the same18:08
ejatbut the bugs is fixed18:08
cory_fuejat: You could check the output of `juju show-cloud openstack` and `juju list-credentials --format=yaml openstack` and see if anything looks odd there18:14
hmlejat:  if you’ve sourced your nova-rc file, juju autoload-credentials sometimes works better for OpenStack18:14
admcleod_ejat: if you are using keystone v3, you need to make sure your novarc is also keystone v318:18
ejatadmcleod_: using novarc is fine18:18
admcleod_ejat: what do you mean18:20
bdxI *think* he means that juju doesn't look for the same environement variables that are set by the novarc for kv318:22
bdxusing autoload-credentials18:22
ejatthanks bdx18:22
bdxI hit it this weekend too18:23
ejatbdx: so how u counter it18:23
bdx1) download novarc from horizon, 2) source novarc on local machine, 3) add openstack cloud in juju (`juju add-cloud myopenstack`), 4) run `juju autoload-credentials` and select the openstack cloud18:24
bdx^ something like that I think18:24
bdxejat: I'll try to to reproduce ^ in the next day or so and get a bug filed18:25
ejatowh let me try18:26
ejatbdx: result still the same18:29
admcleod_ejat: can you pastebin the novarc without passwords etc?18:29
hmlbdx:  what is the difference between the env vars set by novarc for kv3 and the novarc contents downloaded from horizen?18:31
ejatadmcleod_: http://paste.ubuntu.com/p/BGXMWKq6Qr/18:31
admcleod_ejat: ok, thanks, looks fine18:32
ejatanyone can give advise?20:29
thumperejat: sure20:46
ejatthumper: really much appreciate20:46
ejatstill can't auth with openstack :(20:47
thumperpersonally I don't know much about openstack, but others here do20:49
thumperhowever you probably need to give more information20:49
thumperwhich openstack20:49
thumperhow are the creds defined20:50
thumperwhat error are you getting20:50
thumperetc20:50
ejatim using openstack queens bundle with a little bit of customization which to include heat + telemetry20:52
ejatusing MAAS20:52
ejatadded the openstack into the cloud list20:52
ejatthen juju add-credential20:53
ejatthen tried to bootstrap20:54
ejati got this :20:55
ejatERROR authentication failed.20:55
ejatPlease ensure the credentials are correct. A common mistake is20:55
ejatto specify the wrong tenant. Use the OpenStack "project" name20:55
ejatfor tenant-name in your model configuration.20:55
thumperejat: are you able to use those same credentials without juju in the mix and have it work?21:32
ejatthumper: for openstack cli works fine21:32
thumperhml: any ideas around openstack creds and queens?21:36
hmlthumper: no..  i was looking at the nova rc file ejat put it a pastebin earlier21:37
hmlejat: can you give me the results of ‘juju credentials  --format yaml <cloudname>’?21:39
hmlejat:  also run with —show-secrets (dash dash)  and verify your password21:40
ejathml: https://paste.ubuntu.com/p/cxrydwmtmQ/21:42
hmlejat: it looks good - the only thing i see is that domain-name is also set, which mine doesn’t have…. should be okay21:46
hmlejat:  can you get me the output of juju bootstrap —debug please?  (dash dash is auto correcting on me to —)21:47
ejathml: https://paste.ubuntu.com/p/sGQgNDcf9x/21:51
* hml looking21:51
hmlegat: what do you get from ‘wget http://172.15.1.102:5000/v3/auth/tokens'?21:54
hmlejat ^^21:56
ejathml: https://paste.ubuntu.com/p/xQTGQXvTMF/21:59
hmlejat: so it looks like there is something wrong with the credentials as the bootstrap output says…  let me try something on my box…22:00
hmlejat:  it appears that juju doesn’t like domain-name in the credentials…. this is a bug.  please file one!22:02
hmlejat:  i can also give you a work around until it’s fixed22:03
hmlejat:  juju credentials —format-yaml —show-secrets <cloudname> > /tmp/creds.yaml22:11
ejathttps://bugs.launchpad.net/juju/+bug/176455022:12
mupBug #1764550: can't authenticate juju credential with openstack queens <juju:New> <https://launchpad.net/bugs/1764550>22:12
hmlejat:  edit /tmp/creds.yaml to remove ‘local-“ from the first line - and remove the domain-name line as well22:12
ejatcan u help to comment the work around on LP ?22:12
hmlejat: then juju add-credential --replace <cloudname> -f /tmp/creds.yaml22:13
hmlejat: sure22:13
ejathml: thanks a lot .. maybe bdx can refer it too22:13
ejati guess he also facing the same issue22:13
hmlejat: how did you create the juju credentials?  that’d be helpful to know in the bug - as well as which novarc you were using?  from k3 or horizen22:14
bdxejat: I can auth to openstack just fine, mine was a totally different thing I was experiencing with autoload-credentials22:16
ejatbdx: owh sorry22:17
bdxejat you can't just curl or wget the endpoint like you are in that bug22:17
ejatmiss understood you22:17
bdxyou have to get the token using the openstack client etc etc22:17
bdxit is meant to fail if you try to interact with it like you are there22:17
ejathml: from horizon22:17
hmlejat: interesting.22:18
hmlejat:  did you use autoload-credentials, or add-credentials?22:18
hmlejat: i’m EOD for now.. will be online tomorrow though.  i tried the cause and work around myself on an openstack v3 - so hopefully you’re good to bootstrap!22:23
ejatthanks a lot hml22:24
ejatsee u tomorrow22:24

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!