[02:48] <SimplySeth> how does one define a custom interface in metadata.yaml ? I see interfaces like mysql and http, but don't know where these are defined.
[03:03] <lazyPower> SimplySeth: interfaces are kind of arbitrary - think of them as loosely coupled contracts
[03:03] <lazyPower> i gave a talk over this, let me find the slides
[03:04] <lazyPower> https://speakerdeck.com/chuckbutler/service-orchestration-with-juju?slide=24
[03:05] <lazyPower> SimplySeth: an important thing to remember about your interfaces as you start to design your relationship models - its a bi-directional communication cycle between the two services, you can have any number of different relations that consume the same interface but behave differently, and if you send for example - 3 data points on one of the relationship over that interface, every time the interface is used the same 3 data poitns should be
[03:05] <lazyPower> exchanged.
[03:05] <lazyPower> if you're changing teh data handoff, the interface should change.
[03:05] <lazyPower> ergo: you'll se interfaces like db, and db-admin
[03:10] <SimplySeth> * goes to read
[03:12] <SimplySeth> mesos communicates on 5051 and 5050 and 2181
[03:13] <lazyPower> that very well could be modeled as 3 independent relationships
[03:13] <lazyPower> or, if all of those have the same concern, you can encapsulate that as a single relationship - i'm not really familiar with how mesos talks to its minions
[03:14] <lazyPower> what i typically do when i'm speccing out a charm - is i break down the concerns, get a mental data model on paper and start to sketch how that looks between services - pencil and paper are good tools for this - or a whiteboard if you ahve one
[03:14] <lazyPower> once you've got a decomposed service diagram, you then name them, and define your data exchange between the services, and have a good representation to stuff in your metadata.yaml
[08:08] <marcoceppi> bodie_: re: iptables, you could probably achieve a similar affect with an iptables subordinate
[08:45] <Muntaner> good morning to everyone!
[08:48] <Muntaner> having problems with bootstrap... can anyone help me?
[08:49] <Muntaner> I'm trying to use juju with an openstack in a private cloud
[08:49] <Muntaner> when I try to bootstrap
[08:49] <Muntaner> Juju successfully creates the VM on the openstack
[08:50] <Muntaner> seems to be able to communicate with this instance
[08:50] <Muntaner> but... at a certain point, bootstrap fails
[08:50] <Muntaner> with this log:
[08:52] <Muntaner> http://paste.ubuntu.com/10139228/
[08:57] <Muntaner> hi dimitern
[08:57] <dimitern> hi Muntaner
[08:58] <Muntaner> I'm having some bootstrap problems... may you help me?
[08:58] <dimitern> Muntaner, can you remind me - were you having issues behind a proxy?
[08:59] <Muntaner> no dimitern no proxies issues :)
[08:59] <Muntaner> well, simply I can't bootstrap juju over a private OpenStack cloud
[08:59] <Muntaner> logs: http://paste.ubuntu.com/10139228/
[09:02] <dimitern> ah ok
[09:04] <dimitern> Muntaner, it seems you can't fetch the tools
[09:05] <Muntaner> dimitern: need environments.yawl?
[09:05] <dimitern> Muntaner, nope, let me check something first
[09:05] <dimitern> Muntaner, have you tried running juju sync-tools before bootstrap?
[09:06] <Muntaner> I'll try now
[09:06] <dimitern> Muntaner, wait a sec
[09:07] <Muntaner> ok dimitern, tell me what to do :)
[09:07] <jam> hey dimitern, aren't you off today?
[09:07] <dimitern> Muntaner, try following this guide https://juju.ubuntu.com/docs/howto-privatecloud.html
[09:08] <dimitern> jam, hey, yes - officially, just checking how things are going
[09:09] <Muntaner> dimitern: maybe I need to create this metadata on the server?
[09:09] <Muntaner> 'cos actually, I'm trying to use juju with my laptop on the openstack server via LAN (10.0.0.0/24)
[09:09] <dimitern> Muntaner, yes, it seems bootstrapping finds the correct image to start, but the juju tools metadata is missing
[09:10] <Muntaner> aw ok dimitern, I can't get the workaround btw :(
[09:10] <dimitern> Muntaner, so try juju metadata generate-tools -d $HOME/juju-tools (create that dir as well beforehand); then juju bootstrap --metadata-source $HOME/juju-tools
[09:11] <Muntaner> dimitern: all of this in my laptop, right?
[09:12] <Muntaner> dimitern: having some strange debug messages in this command, want to check this?
[09:13] <Muntaner> mike@mike-PC:~$ juju metadata generate-tools -d /home/mike/juju-tools --debug
[09:13] <Muntaner> -> http://paste.ubuntu.com/10139486/
[09:13] <Muntaner> but, in the folder, it created some jsons
[09:14] <Muntaner> com.ubuntu.juju:released:tools.json, index.json, index2.json
[09:15] <dimitern> Muntaner, that's fine, try bootstrapping now with --metadata-source
[09:15] <Muntaner> dimitern: I get an earlier error :(
[09:16] <Muntaner> http://paste.ubuntu.com/10139519/
[09:17] <Muntaner> maybe... I need to upload tools?
[09:18] <dimitern> Muntaner, no, just --metadata-source
[09:19] <dimitern> Muntaner, ha!, ok
[09:20] <Muntaner> dimitern: what should I try now?
[09:20] <dimitern> Muntaner, you'll need juju metadata generate-image -d <same dir> -i <image id from your openstack glance image list>
[09:21] <Muntaner> ok, gonna do that and give feedback
[09:21] <dimitern> Muntaner, you can run this multiple times - one per image (e.g. trusty amd64, i386, etc.); then run juju metadata validate-images (check that page I sent and the commands --help)
[09:22] <dimitern> Muntaner, the idea is to have a bunch of images and tools metadata in that metadata dir so that at bootstrap juju can find you images and tools
[09:23] <Muntaner> dimitern: all of this should happen on my laptop, right?
[09:28] <Muntaner> dimitern: got a new error :)
[09:29] <Muntaner> http://paste.ubuntu.com/10139639/
[09:30] <dimitern> Muntaner, did you try validate-images and validate-tools successfully before trying to bootstrap? please do that
[09:31] <Muntaner> dimitern: I did validate images - not validate tools, will try it now
[09:32] <dimitern> Muntaner, yeah, if both are successful you've a better chance of bootstrapping ok
[09:35] <Muntaner> dimitern: same errors
[09:35] <dimitern> Muntaner, with validate-tools?
[09:35] <Muntaner> seems like juju can't find /home/mike/juju-tools/tools/releases/juju-1.21.1-trusty-amd64.tgz
[09:36] <Muntaner> in fact, I don't have that file
[09:36] <dimitern> Muntaner, hmm ok, then let me ask someone what we're missing here
[09:36] <Muntaner> yep - with both validate-tools and validate-image
[09:38] <Muntaner> ok dimitern, thanks
[11:59] <Mmike> Hi, guys and gals.
[11:59] <Mmike> How do I check which charm version has deployed my services/units? Is that info displayed in 'juju status' ?
[12:10] <jamespage> Mmike, it should be yes
[12:11] <Mmike> jamespage: found this: http://juju-docs.readthedocs.org/en/latest/internals/charm-store.html#charm-revisions
[12:12] <Mmike> but not sure how to link charm revisions with bzr revisions
[12:12] <jamespage> Mmike, you can't
[12:13] <jamespage> Mmike, charmstore revisions are created when the bzr source branch is automatically imported
[12:13] <jamespage> cs:trusty/swift-storage-92 for example
[12:13] <jamespage> but there is not direct correlation with bzr versions
[12:14] <jamespage> its an intentional decoupling to avoid tying charm authors to a single vcs
[12:16] <hazmat> those docs should get taken down, they are the ancient pyjuju impl docs
[12:16] <Mmike> hazmat: heh... but they reveal some of the internals
[12:16] <Mmike> which is a good thing
[12:17] <hazmat> Mmike: we have internal docs for the current version in the source tree as well
[12:17] <hazmat> covering different topics.. but also useful for lighting up internals.. https://github.com/juju/juju/tree/master/doc
[12:18] <hazmat> the old docs are are hit or miss, especially the internals which may no longer apply
[12:20] <hazmat> actually almost none of those docs on internal apply anymore
[12:20] <hazmat> from juju-docs.readthedocs.org site
[12:39] <Mmike> hazmat: how can I get the internal docs, are they on launchpad somewhere?
[12:40] <Mmike> actually what I need is to test upgrade path for some charm - so I see the bzr commit that was merged into 'trunk' (main?) and I'd like to deply that particular 'commit' - how do I figure out what charm revision that was?
[12:49] <marcoceppi> Mmike: there's no correlation to bzr commit and charm revision. You could probably figure that out with some API queries but it's not apparent
[12:49] <marcoceppi> hazmat: I agree, any idea on who setup that site?
[12:53] <Mmike> marcoceppi: ack, thnx. I'll try to figure it out manually.
[12:54] <hazmat> marcoceppi: not sure, maybe brendan?
[12:54] <hazmat> er.. i mean brandon
[12:55] <hazmat> Mmike: that github link above has the current internal docs
[12:56] <Mmike> hazmat: missed that one, thnx! :D
[12:56] <hazmat> Mmike: nutshell you can use query the bzr version of a particular charm store revision, but there's no mapping from bzr rev to charm store rev. effectively the charm store rev, is a monotonically increase integer managed by the store, in response to pushes/puts of a charm.
[12:58] <hazmat> ie. something like https://api.jujucharms.com/v4/mongodb/meta/extra-info
[12:58] <Mmike> i see
[12:59] <Mmike> thnx, lads
[12:59] <hazmat> Mmike: actually this is a bit better https://api.jujucharms.com/v4/mongodb/meta/revision-info
[13:00] <hazmat> rick_h_: are there public docs on the store api?
[13:01] <hazmat> Mmike: fwiw, docs on the store api https://github.com/juju/charmstore/blob/v4/docs/API.md
[13:04] <urulama> hazmat: rick_h_ is out today, swap days. But yes, that are the store API.
[13:04] <hazmat> urulama: danke
[13:05] <urulama> Mmike: there is a /meta/extra-info endpoint in CS that holds BZR digest information for a given revision. You can always check the correlation between charm revision and BZR revision.
[13:05] <urulama> Mmike: if you need a hand, let me know which charm you're interested in
[13:32] <Mmike> urulama: it's percona-cluster... current revision is -15, and I'd like to know what charm revision was at branch revno 40
[13:36] <urulama> Mmike: ok, revision 15 has bzr revision 44, looks like percona-cluster-12 had bzr revision 40, but there is no such revision in the system.
[13:37] <urulama> Mmike: have to check a bit what happened to all revisions < 13
[13:37] <marcoceppi> Mmike: you can just cook up a new revision if you want to deploy rev 12 (bzr 40) of the charm
[13:37] <marcoceppi> branch it, reset to revision 40, deploy charm
[13:37] <Mmike> urulama: that's fine, thnx, don't bother. I'll try both 12 and 13 (that is, upgrade 12->15 and 13->15)
[13:37] <Mmike> marcoceppi: or that, indeed! thnx!
[13:38] <Mmike> I did all those tests before 15 got public, I just want to double-check now that its merged.
[14:22] <ayr-ton> hatch: hatched, is you?
[14:29] <hatch> ayr-ton: it is
[14:29] <hatch> assuming you're talking about github :)
[14:30] <ayr-ton> hatch: Ahahaha. So sorry about forget your issue. Working on this right now /o\
[14:33] <hatch> ayr-ton: haha no problem at all :) I was just going through the issues and adding some features the other day and I thought I'd add a note to that bug
[14:33] <hatch> s/bug/enhancement
[14:33] <ayr-ton> hatch: Do you want me to use in the charm the JUJU_DEV_FEATURE_FLAG=actions for early adoption?
[14:34] <hatch> ayr-ton: yeah I'd be ok with using new features for this functionality - using a config option feels pretty hacky to do this
[14:37] <ayr-ton> hatch: Okay. Just a sec.
[14:41] <Muntaner> hi :)
[15:09] <ayr-ton> marcoceppi: https://github.com/ayr-ton/zabbix-charm | https://code.launchpad.net/~ayrton/charms/trusty/zabbix/trunk
[15:09] <ayr-ton> it is working
[15:10] <ayr-ton> just some bugs when depart a db relation, but I'm already working in fix this.
[16:24] <gadago> could anyone help me with the ubuntu openstack installer?
[16:24] <gadago> no matter what install type i choose (Autopilot, Multi, Single) I can't get passed "Bootstrapping Juju"
[16:25] <gadago> MAAS start the installer, etc, etc, seems to create network bridge for Juju, all seems to okay, but then just sits there at the login prompt
[16:25] <gadago> the openstack installer just continues to say "Bootstrapping Juju"
[16:25] <gadago> no idea what I'm doing wrong
[16:27] <gadago> I've been following this guide here http://www.ubuntu.com/download/cloud/install-ubuntu-openstack
[16:39] <marcoceppi> gadago: what architecture/hardware specs are the machines in maas, and how many machines do you hvae? do any machines ever appear allocated in the maas UI?
[16:40] <lazyPower> mbruzek: you can file bugs against jujucharms.com here => https://github.com/CanonicalLtd/jujucharms.com
[16:41] <gadago> marcoceppi, I have two virtual machines (As nodes in maas), plus a third physical node
[16:41] <gadago> the virtual machines currently only have one NIC each (I can add more of course), the physical node has six
[16:42] <marcoceppi> CPU/memory?
[16:42] <gadago> virtual have 2 cpus, 4gb ram
[16:42] <gadago> physical is 24 cpus 48gb ram
[16:43] <marcoceppi> that should be enough, are they x86 arch?
[16:44] <marcoceppi> I know at one point the minimum server requirement was like 8 machines, but that was a while ago. I'm not versed in all the new offerings
[16:44] <gadago> x86 (amd64)
[16:44] <marcoceppi> you're unable to bootstrap a machine this means there is a juju -> maas issue
[16:44] <marcoceppi> So, this typically boils down to one of two things
[16:45] <marcoceppi> 1) credentials issue
[16:45] <marcoceppi> Either you hvae the wrong credentials, or the wrong server hostname for maas (or you can't actually talk to maas from where you're running the installers)
[16:46] <marcoceppi> that last part is technically not a credentials issue, but we're just going to lump it in there
[16:46] <gadago> marcoceppi, could be the second I feel
[16:46] <gadago> by mass server is on 192.168.255.10 with my deployment network being 10.0.14.0/24
[16:47] <gadago> default gateway is 10.0.14.10 (other IP on maas server)
[16:47] <marcoceppi> 2) You don't have a machine that juju expects to find. By default juju uses a set of constraints to request a machine: 1 CPU, 700MB RAM, x86_64. Juju asks MAAS for a machine that meets this minimum requirement and MAAS says "OKIE DAY! here you go" or 409 CONFLICT
[16:47] <marcoceppi> gadago: so, from where you're running these isntaller commands, can you ping the MAAS server?
[16:48] <gadago> I'm running the openstack-install command on the maas serer
[16:48] <gadago> I'm using this guide http://www.ubuntu.com/download/cloud/install-ubuntu-openstack
[16:48] <marcoceppi> gadago: well, that's not going to be much of an issue then
[16:48] <marcoceppi> gadago: in the maas web ui, can you see a machine allocated after running the insaller?
[16:49] <gadago> marcoceppi, under nodes, it shows as "Allocated to root"
[16:49] <marcoceppi> gadago: do all of them say that?
[16:50] <gadago> no just the one at the moment
[16:51] <marcoceppi> gadago: interesting
[16:51] <marcoceppi> gadago: that machine that's allocated to root
[16:51] <marcoceppi> can you ping it? does it have an address?
[16:51] <gadago> that one has PXE booted, rebooted then ran the cloud-init script and setup a juju-br0 device on the 10.0.14.0/23 network
[16:51] <gadago> I can ssh to it
[16:52] <gadago> but that's as far as it goes
[16:52] <marcoceppi> yeah, so it bootstrapped
[16:52] <marcoceppi> gadago: do you have a jujud process running?
[16:53] <gadago> no jujud, but there is a curl process of curl -sSfw tools from %{url_effective} downloaded: HTTP %{http_code}; time %{time_total}s; size %{size_download} bytes; speed %{speed_download} bytes/s  --retry 10 -o /var/lib/juju/tools/1.21.1-trusty-amd64/tools.tar.gz https://streams.canonical.com/juju/tools/releases/juju-1.21.1-trusty-amd64.tgz
[16:54] <marcoceppi> gadago: ah, does this maas install have outside access?
[16:54] <marcoceppi> I wonder if the http proxy isn't setup correctly
[16:54] <marcoceppi> which would cause it to fail to download the juju binary, which would result in aa hung bootstrap
[16:55] <gadago> marcoceppi, the one odd thing I have had with this test maas setup is that I have to set the gateway on the network for the maas config to the maas server itself, if I actually set the gateway to the network gateway, dns fails and the server wont pxe properly
[16:55] <gadago> so in, short if I try to ping google.com, no reply
[16:55] <marcoceppi> gadago: yeah, maas wnats to run both DNS and networking
[16:55] <marcoceppi> well DNS and DHCP/Networking
[16:57] <marcoceppi> so what you could/should do. Create an internal netowrk (sounds like you did 10.0.14.0/23) then setup iptables to forward that br device to the main eth device on maas server
[16:57] <gadago> my maas server is of of course not a gateway
[16:57] <marcoceppi> then setup dns forwarding from the maas server to an external dns server
[16:57] <marcoceppi> that's the only way I've run MAAS, I'm not sure how to do it so it just runs DNS
[16:57] <gadago> I already have dns forwarding sorted (google.com resolves on the node)
[16:57] <marcoceppi> there's a drop down in the maas admin panel to switch it to DNS only
[16:58] <marcoceppi> but you'd want to ask in #maas about dns only (non dhcp) maas setups
[16:58] <marcoceppi> once that's all sorted, and you can wget/curl from within a node, bootstrap should work
[16:59] <gadago> thanks marcoceppi, at least that's a bit of progress :)
[16:59] <gadago> #maas has for some reason become an invite only channel
[17:00] <gadago> so no help there
[17:00] <marcoceppi> gadago: yeah, MAAS is pure awesome, but setting it up on less than 5 nodes in a network it doesn't own can take a bit of jumping since it's designed to manage multiple datacenters and racks of servers :)
[17:00] <marcoceppi> gadago: that's, what, let me find someone to fix that
[17:03] <gadago> marcoceppi, any ideas why maas does not work when not using it as the gateway? I know it's a dns issue, but I find that quite bizzare
[17:04] <marcoceppi> gadago: I don't have enough experience. When I do MAAS testings my setup has an Intel NUC on it's own gigabit switch and the maas master works as the gateway
[17:04] <marcoceppi> I'm not home at the moment so I can't try it out with DNS only setup
[17:05] <gadago> marcoceppi, np
[18:17] <gadago> marcoceppi, finally got the nodes routing through the maas server (with iptables forwarding), but still not luck :(
[18:18] <marcoceppi> gadago: can you curl a payload when ssh'd on the node?
[18:19] <gadago> not tried curl, but internet access on the node is now fine, adn can ping the maas controller on the other subnet just fine
[18:20] <gadago> even getting a /var/lib/juju/tools/1.21.1-trusty-amd64/jujud process now
[18:20] <gadago> mongod seems to be doing something to
[18:20] <gadago> should this be a long process?
[18:23] <gadago> "Install OpneStack in minutes" lol
[18:24] <gadago> the openstack installer on the maas server has hung as well
[18:25] <gadago> maybe not enough grunt?
[18:27] <marcoceppi> gadago: well, is maas set to use the fast installer?
[18:27] <marcoceppi> if not, it's going to take like 10 mins to get the node up alone
[18:27] <marcoceppi> then about 2-3 mins for juju to bootstrap itself
[18:27] <marcoceppi> but if you've got jujud you're on your way
[18:27] <marcoceppi> do you have anything in /var/log/juju ?
[18:27] <gadago> using the fast installer
[18:27] <gadago> maybe I'm just being impatient then
[18:28] <gadago> the elapsed time on the openstack installer stop counting up that's all, and the little blue/purple graph stops moving
[18:31] <gadago> I'll check the log in a moment
[18:35] <marcoceppi> gadago: well clock stopping is never a good sign
[18:36] <gadago> :)
[18:36] <gadago> WARNING juju.cmd.jujud machine.go:602 determining kvm support: INFO: Your CPU does not support KVM extensions
[18:36] <gadago> this one is a VM
[18:38] <gadago> maybe I should try the Multi option for the installer
[20:49] <bdx> I've a concern reguarding the ceph charm. It seems when the config ceph-cluster-network is specified in the ceph charms config, and is different from the specified ceph-public-network, the charm will fail deployment because a second network interface is not brought up on the ceph-cluster-network.
[20:50] <nicopace> hi guys... one question... how can i destroy my local lxc environment, without using 'juju destroy-environment local' (it is not responding, as i got out of disk space :S)
[20:50] <bdx> Does anyone know a way around this?
[20:51] <travis_> hi all
[20:51] <travis_> i am suffering here with a maas environment, trying to get juju to bootstrap
[20:52] <travis_> i keep getting this curl failed
[20:52] <travis_> Attempt 1 to download tools from https://streams.canonical.com/juju/tools/releases/juju-1.21.1-precise-amd64.tgz...
[20:52] <travis_> curl: (7) Failed to connect to streams.canonical.com port 443: No route to host
[20:52] <travis_> tools from https://streams.canonical.com/juju/tools/releases/juju-1.21.1-precise-amd64.tgz downloaded: HTTP 000; time 2.711s; size 0 bytes; speed 0.000 bytes/s Download failed..... wait 15s
[20:52] <travis_> though i can ping streams.canonical.com from the maas box
[20:53] <travis_> any thoughts
[20:54] <travis_> hi all i am suffering here with a maas environment, trying to get juju to bootstrap i keep getting this curl failed Attempt 1 to download tools from https://streams.canonical.com/juju/tools/releases/juju-1.21.1-precise-amd64.tgz... curl: (7) Failed to connect to streams.canonical.com port 443: No route to host tools from https://streams.canonical.com/juju/tools/releases/juju-1.21.1-precise-amd64.tgz downloaded: HTTP 000; time 2
[20:54] <travis_> .711s; size 0 bytes; speed 0.000 bytes/s Download failed..... wait 15s though i can ping streams.canonical.com from the maas box any thoughts
[21:03] <lazyPower> nicopace: have you tried juju destroy-environment local -y --force ?
[21:04] <nicopace> lazyPower: let's see what happens with that command...
[21:04] <lazyPower> nicopace: if that doesn't work, the next step woudl be to lxc-destroy a container or two - and then triage the environment accordingly (juju wont be aware that you've puled the rug out o n those containers)
[21:05] <nicopace> lazyPower: nothing happens
[21:06] <lazyPower> nicopace: sudo lxc-ls --fancy, find a running machine or two that you can destroy
[21:06] <nicopace> so... you say i have to destroy some of the lxc containers by hand?
[21:06] <lazyPower> the destroy-environment --force should have nuked it from orbit
[21:06] <lazyPower> but if the containers are still running and you have no disk space left - lets try removing one and seeing if we can get the env to respond
[21:06] <nicopace> there is no output
[21:06] <lazyPower> there wont be
[21:06] <nicopace> they are all stopped
[21:06] <lazyPower> and juju status should say teh environment is no longer bootstrapped
[21:06] <nicopace> sudo lxc-ls --fancy
[21:06] <nicopace> NAME                       STATE    IPV4  IPV6  AUTOSTART
[21:06] <nicopace> ---------------------------------------------------------
[21:06] <nicopace> juju-precise-lxc-template  STOPPED  -     -     NO
[21:06] <nicopace> juju-trusty-lxc-template   STOPPED  -     -     NO
[21:06] <nicopace> ubuntu-local-machine-48    STOPPED  -     -     YES
[21:07] <lazyPower> interesting... you have a local machine of id 48, that is hanging around.
[21:07] <nicopace> juju status
[21:07] <nicopace> ERROR Unable to connect to environment "local".
[21:07] <nicopace> Please check your credentials or use 'juju bootstrap' to create a new environment.
[21:07] <nicopace> Error details:
[21:07] <nicopace> cannot connect to API servers without admin-secret
[21:07]  * lazyPower blinks
[21:07] <lazyPower> well thats a new error message on me re: admin-secret
[21:07] <lazyPower> do you have a local.jenv file in ~/.juju/environments/ ?
[21:08] <nicopace> i just want to nuke everything up
[21:08] <nicopace> no
[21:08] <nicopace> but i had some minutes ago
[21:08] <nicopace> !
[21:08] <lazyPower> ok, so its supposedly gone then, without a jenv, there is no environment as far as juju is concerned
[21:08] <nicopace> but juju doesn't respond
[21:09] <nicopace> ok... i can bootstrap a new env
[21:09] <lazyPower> sudo initctl list | grep juju
[21:09] <lazyPower> do you see any juju services running?
[21:09] <nicopace> nothing
[21:09] <nicopace> no
[21:09] <lazyPower> ok, good - your state server and api are gone
[21:09] <nicopace> (i've destroyed the recently created env first)
[21:09] <lazyPower> you have one hanging machine that i suggest you remove unles that machine is important to you
[21:10] <nicopace> no
[21:10] <lazyPower> sudo lxc-destroy -n ubuntu-local-machine-48
[21:10] <nicopace> so how i destroy it?
[21:10] <lazyPower> after that you should be g2g to run `juju bootstrap`
[21:10] <nicopace> ok
[21:10] <nicopace> and what about the other two?
[21:11] <nicopace> those are just templateces lazyPower
[21:11] <nicopace> ?
[21:11] <lazyPower> nicopace: you can leave the templates around, unless you want to fetch the 200mb cloud image and wait for them to be recreated again
[21:11] <nicopace> no
[21:11] <nicopace> ok
[21:11] <lazyPower> those are created when you request a deployment for the series on the local provider.
[21:11] <nicopace> so... now i should be ok to start again
[21:11] <nicopace> thanks lazyPower
[21:11] <nicopace> !
[21:11] <lazyPower> correct
[21:12] <lazyPower> np nicopace, lmk if you have any further issues
[21:12] <nicopace> (y)
[21:12] <lazyPower> keep up the good work and reports on teh list :)
[22:05] <sinzui> wwitzel3, how goes bug 1417875? I think I will postpone it to 1.21.3 as I don't think a fix will be available in a few hours
[22:05] <mup> Bug #1417875: ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate signed by unknown authority <canonical-bootstack> <logging> <regression> <juju-core:Triaged by wwitzel3> <juju-core 1.21:Triaged by wwitzel3> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1417875>
[22:12] <wwitzel3> sinzui: sadly I don't think I'll have a fix in the next few hours no
[22:12] <sinzui> okay, thank you wwitzel3