[00:53] <axw> veebers: do you have an example you can show me with the tests that fail due to lack of "virsh"? I ran all the tests yesterday locally, after removing libvirt-bin
[00:53] <axw> (and they passed)
[00:55] <axw> veebers: also, latest s390x run on 2.3 looks much better. thanks for picking up that error: http://qa.jujucharms.com/releases/6156/job/run-unit-tests-xenial-s390x/attempt/2313
[00:55] <axw> still a few errors, but not completely hosed
[01:03] <veebers> axw: can do, one moment while I grab th right url. awesome great to see the s390x improved
[01:07] <veebers> axw: you'll need the vpn connected: http://10.125.0.203:8080/job/RunUnittests-amd64/182/testReport/ (github.com/juju/juju/container/kvm.Test)
[01:07] <axw> veebers: thanks
[01:08] <veebers> axw, babbageclunk would it be fair to say to run the unit tests you need lxd installed and setup (i.e. you need to be in the group etc.), that's out of the scope of the test itself
[01:09] <axw> veebers: I'm not sure if there are any tests that run lxd things directly. wouldn't surprise me
[01:10] <axw> veebers: not sure what you mean about scope sorry
[01:10] <veebers> axw: I ask because there are test failures occuring and I'm pretty sure it's due to them being run within fresh lxd containers each time now (i.e. no long running setup, installs)
[01:11] <axw> veebers: IMO, if you've run "make install-dependencies", then you should be able to run the tests. I don't know what the reality is though
[01:15] <veebers> axw: install-deps doesn't install lxd :-\ so if it's actually needed by the tests is assuming its installed and setup. I'll dig further and pester you later on :-)
[01:15] <axw> okey dokey
[02:07] <axw> veebers: FYI: https://github.com/juju/juju/pull/8292. skips live tests when virsh is missing. I had other errors when trying to run them - pretty sure nobody is running them, since they only work when run as root
[02:09] <axw> anastasiamac: thanks
[02:12] <veebers> axw: Interesting, I'm just looking now that the unit tests in lxd containers get run as root (and changing that so it's ubuntu user instead)
[02:13] <anastasiamac> axw: nws, was curious :D
[02:13] <axw> veebers: sounds good, that will also fix the kvm test issue
[02:17] <veebers> axw: appears it will fix the lxd test errors too
[02:17] <axw> veebers: cool :)
[06:15] <thumper> wpk_: ping
[07:32] <tasdomas> morning
[07:32] <tasdomas> anastasiamac, ping?
[07:46] <anastasiamac> tasdomas: ? :D
[07:47] <anastasiamac> tasdomas: i saw u landing ur PR in 2.3, so assumed that u do not need any other reviews... generally, staright forward ports r self-approved
[07:57] <tasdomas> anastasiamac, does https://github.com/juju/juju/pull/8290 look alright as a forward port?
[08:05]  * anastasiamac looking
[08:08] <anastasiamac> tasdomas: i *think* so :) lgtm'ed
[08:18] <tasdomas> anastasiamac, thanks
[10:06] <kjackal> Hi, is there support for availability zones in openstack?
[10:11] <axw> kjackal: yes there is. is something not working for you?
[10:26] <kjackal> axw: we are suposed to use openstack as a cloud provider
[10:26] <kjackal> this openstack deployment has 3 availability zones
[10:27] <kjackal> is it possible to use a constraint to request certain applications to be spread accross all availability zones?
[10:27] <kjackal> is there a zone constraint
[10:27] <kjackal> axw: ^
[10:28] <axw> kjackal: all applications will (should) be spread across AZs without you having to do anything extra
[10:29] <axw> i.e. "juju deploy -n 3 foo" should give you a unit in each AZ
[10:29] <kjackal> ok, can I request a certain availability zone for a unit?
[10:29] <axw> there is no zone constraint. there is zone *placement*, if you want to assign specific units to a zone
[10:30] <kjackal> ok, where can I read about this?
[10:30] <kjackal> juju docs?
[10:30] <axw> kjackal: https://jujucharms.com/docs/2.3/charms-deploying looks to be the most appropriate link
[10:30] <axw> kjackal: see "--to zone="
[10:33] <kjackal> axw: ok, cool
[10:33] <kjackal> axw: is the "--to" available from a bundle as well?
[10:35] <axw> kjackal: I don't think so
[10:42] <kjackal> axw: hm... it gives me an "invalid placement" error
[10:42] <axw> kjackal: what command did you use?
[10:43] <kjackal> axw: placement works from command line but I need it to be part of a bundle
[10:44] <kjackal> so in the "-to: " of the bundle I tried "zone=nova" or just "nova"
[10:46] <axw> kjackal: that doesn't make for a very portable bundle. what do you think about supporting --to on the CLI for bundles, so you'd do something like "juju deploy bundle.yaml --to ubuntu/0:zone=nova --to ubuntu/1:zone=super"
[10:48] <axw> kjackal: anyway, probably best to file a bug/feature request on launchpad - I'm past EOD, going to head off in a moment
[11:01] <kjackal_bot> axw: thank you for your help
[11:01] <kjackal_bot> yes you are right the bundle will not be portable. It would be too essoteric
[11:58] <thumper> babbageclunk: giving audit logging demo tomorrow morning here
[11:59] <thumper> babbageclunk: what is the current status of the outstanding items we had on audit logging?
[12:02] <thumper> ah.. 1am, you won't see this
[15:52] <balloons> hml, ping