=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
=== freeflying is now known as freeflying_away
[07:37] <MAASSIVE> hello all
[07:37] <MAASSIVE> rvba thanks alot
[07:37] <MAASSIVE> it worked
[07:38] <MAASSIVE> I just had to assign which distro
[07:38] <MAASSIVE> and worked fine
[07:38] <MAASSIVE> now Im getting this error with juju
[07:39] <MAASSIVE> http://paste.ubuntu.com/6560024/plain/
[07:45] <jtv> MAASSIVE: empty environment name?  That doesn't sound right.  Do you have your juju environment configured on the machine you're doing that on?
=== CyberJacob|Away is now known as CyberJacob
[08:06] <MAASSIVE> yes I didn configure it
[08:06] <MAASSIVE> but one thing I noticed
[08:06] <MAASSIVE> I ran juju bootstrap
[08:06] <MAASSIVE> then it got interrupted
[08:07] <MAASSIVE> tried again
[08:07] <MAASSIVE> I started getting this error
[08:08] <MAASSIVE> I tried juju destoy-environment
[08:09] <rvba> jtv: could you please have a look at https://bugs.launchpad.net/maas-test/+bug/1259972
[08:09] <ubot5> Ubuntu bug 1259972 in maas-test "maas-test errors when the interface given on the command line has no IP address " [High,Triaged]
[08:09] <rvba> ?
[08:10] <MAASSIVE> I got this http://paste.ubuntu.com/6560108/plain/
[08:11] <MAASSIVE> also just to note that I installed juju
[08:11] <MAASSIVE> then added juju-core
[08:11] <MAASSIVE> and removed juju
[08:11] <MAASSIVE> kept juju-core
[08:11] <jtv> MAASSIVE: I think the "conflict" error means that Juju tries to deallocate a machine when it's in a state where that makes no sense...  I think there's a known bug about that.
[08:12] <rvba> MAASSIVE: can you give us the version of maas and juju?  (apt-cache policy maas / apt-cache policy juju-core)
[08:12] <jtv> rvba: that bug looks pretty easy (provided all you want is a better error).
[08:13] <rvba> jtv: well, not really a better error.  The check must not fail in this case… and it does.
[08:13] <jtv> Why?  The interface must have an IP address for the tests to work.
[08:15] <rvba> Well, the check is about detecting DHCP servers on the network.  In my case, the NIC is connected to a completely unconfigured network.  And the interface connected has no IP yet.  So I'd expect the check to let maas-test run instead of blowing up in my face.
[08:16] <MAASSIVE> http://paste.ubuntu.com/6560133/plain/
[08:16] <jtv> rvba: it's a bit awkward if we can't do the DHCP check at all, but we could log a warning about it...
[08:17] <MAASSIVE> that was output for apt-cache policy maas / apt-cache policy juju-core  / apt-cache policy juju
[08:17] <rvba> jtv: I think that would be better than blowing up.  Again, in my case, there is no DHCP server at all.  The check is just unable to perform the detection, which is fine, but this should not prevent me from running maas-test.
[08:18] <jtv> Then we can check for the result from get_interface_IP().
[08:21] <rvba> MAASSIVE: yeah, like jtv said, you're hitting some bugs that where present in the package released in precise.  As stated in the documentation (http://maas.ubuntu.com/docs/install.html), you should really use the cloud-archive:tools ppa on precise.
[08:21] <rvba> MAASSIVE: see the "Note" on that doc page.
[08:23] <MAASSIVE> ???
[08:23] <MAASSIVE> A more up-to-date MAAS is available for the most recent Ubuntu LTS release in the Canonical cloud archive. You can activate the archive with sudo add-apt-repository cloud-archive:tools. Using packages from this archive is recommended as it contains important fixes and new features that are not always available in the Ubuntu archive.
[08:24] <MAASSIVE> shall I just run sudo add-apt-repository cloud-archive:tools
[08:24] <rvba> MAASSIVE: yes
[08:24] <MAASSIVE> then re-install juju-core
[08:24] <rvba> And maas
[08:24] <MAASSIVE> ?
[08:26] <rvba> The ppa in question contains backported versions of maas and juju-core.  i.e. versions from later releases backported into precise.
[08:26] <MAASSIVE> what do u mean by and Maas?
[08:26] <rvba> So, you need to run the add-apt-repository, then 'sudo apt-get update' to refresh your local cache, then install juju-core and maas (and you should see them being downloaded from that ppa)
[08:27] <rvba> You need to reinstall maas as well.
[08:27] <rvba> Once the ppa is set up.
[08:27] <MAASSIVE> apt-get install maas ?
[08:27] <rvba> Yeah
[08:28] <rvba> MAASSIVE: http://paste.ubuntu.com/6560199/
[08:30] <MAASSIVE> juju-core didnt change
[08:30] <MAASSIVE> http://paste.ubuntu.com/6560202/plain/
[08:30] <MAASSIVE> output of the commands
[08:30] <MAASSIVE> shall I now bootstratp?
[08:35] <rvba> Yeah, it should be fine.
[08:35] <rvba> The ppa from which you installed juju-core contains a very up-to-date version of juju-core.
[08:35] <rvba> That's why it did not get upgraded.
[08:36] <MAASSIVE> shall i do $ juju bootstrap --upload-tools
[08:36] <MAASSIVE> or $ juju bootstrap
[08:39] <jtv> rvba: by the way, does your branch for creating zones include an edit form for zones?
[08:40] <rvba> jtv: let me check… (doing so many things in parallel I'm a bit confused right now)
[08:40] <jtv> Understandable.
[08:40] <rvba> jtv: http://paste.ubuntu.com/6560244/
[08:40] <jtv> I just didn't want to implement my own and then discover that we had massive conflicts.
[08:41] <rvba> jtv: your branch seems to be more advanced than mine (in fact, I just started working on it).
[08:41] <MAASSIVE> which command is the correct one
[08:41] <MAASSIVE> $ juju bootstrap
[08:41] <jtv> I guess that form you just posted would be enough if we change the foreign key?
[08:41] <rvba> jtv: yes
[08:41] <MAASSIVE> or $ juju bootstrap --upload-tools
[08:42] <rvba> MAASSIVE: this has been changed very recently so I'm not sure if the version of juju you're using requires '--upload-tools' or not… hang on.
[08:44] <rvba> MAASSIVE: you should be fine without '--upload-tools'.
[08:46] <rvba> MAASSIVE: the "uploading of the tools" step is not done with "juju --sync-tools".
[08:47] <rvba> s/not/now
[08:47] <rvba> oops :)
[08:47] <MAASSIVE> oops
[08:47] <MAASSIVE> ERROR environment is already bootstrapped
[08:48] <MAASSIVE> lbgmaas@lbgmaas1:~$ juju bootstrap ERROR environment is already bootstrapped
[08:48] <MAASSIVE> shall destroy
[08:48] <MAASSIVE> ???
[08:48] <rvba> Yes.
[08:49] <MAASSIVE> ERROR gomaasapi: got error back from server: 409 CONFLICT
[08:49] <MAASSIVE> after tryung to run destroy-env
[08:52] <rvba> Can you go to the MAAS UI and "release" the allocated node(s)?
[08:54] <MAASSIVE> oops here is the strange thing, I wen tot MAAS I fond two nodes being off
[08:54] <MAASSIVE> just powered them
[08:54] <rvba> After that, re-destroy the env (it should work this time).
[08:54] <MAASSIVE> dunno how they got powered off
[08:54] <rvba> In what state are your nodes?
[08:54] <MAASSIVE> shall I destoy or bootstrap  first
[08:56] <rvba> If the IPMI is configured correctly, you shouldn't have to power your nodes up or down manually. At all.
[08:56] <rvba> So, destroy first.  If it work, bootstrap.
[08:56] <rvba> works*
[09:18] <MAASSIVE> ooops
[09:18] <MAASSIVE> destroy give this
[09:18] <MAASSIVE> ERROR gomaasapi: got error back from server: 409 CONFLICT
[09:21] <MAASSIVE> this is strange
[09:21] <MAASSIVE> when I try to destroy I get the error : ERROR gomaasapi: got error back from server: 409 CONFLICT
[09:21] <MAASSIVE> and my nodes get powered off
[09:38] <MAASSIVE> ??
[09:39] <rvba> We need to know in what state your nodes are to help you.
[09:39] <MAASSIVE> here is a more strange one
[09:41] <MAASSIVE> one of my nodes keep on reverting to install mode
[09:41] <MAASSIVE> as if its the 1st time
[09:41] <MAASSIVE> this happened after I added the new repo
[10:00] <MAASSIVE> rvba: i think the update has messed maas
[10:00] <MAASSIVE> everytime I try to power on a node it reverts to the install mode
[10:01] <MAASSIVE> as if its doing it fresh
[10:01] <MAASSIVE> any clue why this behaviour?
[10:01] <MAASSIVE> when destroying the juju, one node gets powered off
[10:01] <MAASSIVE> ERROR gomaasapi: got error back from server: 409 CONFLICT
[10:02] <MAASSIVE> do you recommend that I start from scratch?
[10:02] <rvba> MAASSIVE: can you tell me in what state the nodes are when you run the juju destroy-env command?
[10:03] <MAASSIVE> one of them goes to ready
[10:03] <MAASSIVE> it was allocated to root then goto ready
[10:05] <MAASSIVE> so it reverts to ready.
[10:05] <MAASSIVE> is this normal?
[10:05] <rvba> So all the nodes are ready when you run the command?
[10:05] <MAASSIVE> yes
[10:05] <MAASSIVE> but I get ERROR gomaasapi: got error back from server: 409 CONFLICT
[10:06] <rvba> This is really weird, if all your nodes are ready, you shouldn't get that.
[10:06] <rvba> MAASSIVE: I'm sorry, I'll have to recommend that you delete all the nodes from MAAS and re-enlist/re-commission them.
[10:07] <jamespage> allenap, is the task for pymongo on bug 1237615 still valid?
[10:07] <ubot5> bug 1237615 in pymongo (Ubuntu) "python-bson-ext does not encode binary in Apache with mod_wsgi" [Undecided,New] https://launchpad.net/bugs/1237615
[10:09]  * allenap looks
[10:10] <allenap> jamespage: Are you wondering if it’s been fixed in saucy by a recent upload?
[10:11] <jamespage> allenap, I was trying to figure out whether it was a configuration issue or an actual bug
[10:13] <allenap> jamespage: I’m not actually sure which side of the fence this falls on. I’m inclined to say that the pymongo task can be marked invalid.
[10:13] <jamespage> allenap, done
[10:13] <jamespage> thanks
[10:13] <allenap> jamespage: Cool :)
[10:19] <allenap> MAASSIVE: By any chance did you allocate the nodes to yourself in MAAS before using Juju?
[13:29] <MAASSIVE> rvba: I did delete all nodes and added one node now
[13:29] <MAASSIVE> still same issue
[13:30] <MAASSIVE> allenap: pls explain more on allocating to myself
[13:44] <ticking> hey is there a workaround of the maas-import-pxe-files bug?
[13:45] <ticking> I have the latest maas on a 13.10
[14:47] <ticking> how comes that the latest version is basically unusable out of the box without manual fixes? Does everybody use 12.x or is the userbase so small?
=== freeflying_away is now known as freeflying
[15:17] <MAASSIVE> Hi there
[15:17] <MAASSIVE> sorry if I missed something
[15:22] <stokachu> any know if bug 1238390 will be addressed by 14.04?
[15:22] <ubot5> bug 1238390 in maas (Ubuntu) "maas-region-controller debconf config has a non-existent 'dbc_go'" [Low,Triaged] https://launchpad.net/bugs/1238390
[15:23] <stokachu> i think its purely cosmetic
=== freeflying is now known as freeflying_away
=== matsubara_ is now known as matsubara
[21:47] <lazypower> So, correct me if i'm wrong, but you can use MAAS to provision LXC containers on a single server?