[04:35] <jtv> smoser, could you help me with this?  I need maas to retrieve some settings that are debconf'ed by the maas-dhcp postinst script.
[04:40] <jtv> roaksoax maybe?
[08:22] <jtv> rvba: if we have dev_fixture.yamls and initial_data.yamls, a dev setup will load both and a production setup will only load the latter, right?
[08:24] <jtv> Oh no, please tell me this is not true.
[08:24] <jtv> User.email must be unique, even if it's blank.
[08:24] <jtv> What #$@% use is that?
[08:25] <rvba> jtv: How would dev_fixture.yamls be loaded by the dev service?
[08:25] <jtv> I thought a demo run has all the data from dev_fixture.yaml..?
[08:26] <rvba> jtv: no, make sampledata loads dev_fixture.yaml
[08:26] <jtv> Well that's what you do for a demo run, so a dev setup will load both, right?
[08:27] <rvba> Yes.
[08:27] <jtv> Well that exactly answers my question.  :)
[08:27] <rvba> initial_data.yamls is loaded automatically but not dev_fixture.
[08:27] <rvba> Ok then :).
[08:27] <jtv> Unfortunately I'm running up against this weirdness where we can't have two built-in users with email address '', even though we can have one.
[08:28] <rvba> I thought we "fixed" that... let me have a look at the code and refresh my memory.
[09:28] <jtv> Yes, South, I'm making a field nullable.  And, since you seem to insist, specifying a default value of None.  Now, honestly, what do you think I want the default to be?  Do you still need to stop because you don't know?
[09:41] <jtv> Ah.  Thank you internet.  This is South's way of saying: what if I ever want to _reverse_ this migration?
[10:24] <jtv> rvba: I don't think we have the email-may-be-empty-but-must-still-be-unique problem solved.  :(
[10:25] <rvba> jtv: really?  IIRC we wanted to use that only to be able to create a system user with an empty email address.
[10:25] <jtv> Yes
[10:25] <jtv> That's what I'm trying to do.
[10:26] <jtv> But we already have one with an empty email address.
[10:26] <jtv> I have a feeling that the solution we found at the time was to use a blank string, and leave the rest of the problem for the future.
[10:26] <jtv> Providing a null violates a not-null constraint, providing an empty string violates a unique constraint.
[10:27] <jtv> Ahhh looks like django 1.4 makes the email address optional.
[10:28] <jtv> Or maybe that's only in the check that creates it, rather than in the database.
[10:28] <rvba> But unfortunately we have to be compatible with Dj 1.3.
[10:28] <jtv> I'm not even sure 1.4 solves it anyway.  :(
[10:28] <jtv> What I found was about create_user:
[10:28] <jtv> “The username parameter is now checked for emptiness and raises a ValueError in case of a negative result.”
[10:28] <jtv> And by a negative result in this case they mean a positive result.
[10:28] <jtv> Off-by-True error.
[10:30] <jtv> What's the system username we create?  Just maas?  I could just use maas@localhost.
[10:30] <jtv> Although… what do we do for the _next_ system user?  I'll just make it a full description of the user, and a nonexistent address. TFB.
[12:17] <roaksoax> jtv: sure, how do you want to retrieve them?
[12:17] <jtv> roaksoax: never mind, I think I'll just leave that as a packaging job, something postinst can do.
[12:18] <roaksoax> jtv: cool
[12:19] <roaksoax> rbasak: howdy! this is what we need to do in setup.py: http://bazaar.launchpad.net/~andreserl/maas/maas_updates_bzr745/revision/56
[12:20] <roaksoax> errr
[12:20] <roaksoax> rvba: ^^
[12:20] <roaksoax> rbasak: sorry worng person :)
[12:20] <rbasak> np
[12:20] <roaksoax> rvba: debian/rules mainly
[12:21] <rvba> roaksoax: looking.
[12:21] <roaksoax> rvba: override_dh_auto_build
[12:22] <roaksoax> rvba: i just figured it was faster and less painfull for me to build it in package build time rather than copy it manually. But we need to handle it in the setup.py
[12:23] <rvba> roaksoax: looks all right time.
[12:24] <rvba> roaksoax: looks all right to me.
[12:24] <rvba> :)
[12:24] <roaksoax> rvba: :)
[12:42] <roaksoax> jtv: so now that maas-import-isos references are being erased, does this mean that we are now using MAAS own PXE server?
[12:42] <jtv> Not quite there yet.
[12:42] <jtv> For that we need to assume control of DHCP.
[12:43] <jtv> Or the administrator needs to configure their DHCP for MAAS.
[12:43] <jtv> Currently we still use Cobbler.
[12:43] <roaksoax> jtv: right, ok then. So do you have an ETA of when this would happen (getting rid of cobbler)?
[12:44] <jtv> We're working on it… the devil is very much in the details.
[12:44] <jtv> To a large extent the plan unfolds as we execute it.
[12:44] <jtv> It's the price we pay for getting a quick start using Cobbler.
[12:45] <roaksoax> hehe
[12:46] <roaksoax> jtv: alright, I was just wondering so that I can do the appropriate packaging updates then, and not now :)
[12:47] <jtv> I'm afraid we're going to go through some stages of brokenness before we come out the other end working but without Cobbler.
[12:52] <roaksoax> i guess that's fine.
[12:53] <roaksoax> I just want to be aware when cobbler is not longer being used so I don't release broken stuff
[15:13] <roaksoax> allenap: how would you describe the fixes for python-tx-tftp?
[15:15] <allenap> roaksoax: It adds tsize support; it already has timeout support, so this should make it fully comply with RFC 2349.
[15:15] <allenap> pxelinux requires tsize support.
[15:16] <roaksoax> allenap: ok cool, just updating patch description :)
[15:19] <allenap> roaksoax: Fwiw, here's the pull request: https://github.com/shylent/python-tx-tftp/pull/5
[15:21] <roaksoax> thanks
[17:06] <cropalato> Hi, is there some documentation about configure maas with a external dhcp?
[17:16] <guimaluf> cropalato, iis the same thing. the difference is allow the dhcp to redirect the pxe server:
[17:16] <guimaluf> allow bootp;
[17:16] <guimaluf> allow booting;
[17:16] <guimaluf> class "pxeclients" {
[17:16] <guimaluf>         match if substring(option vendor-class-identifier,0,9)="PXEClient";
[17:16] <guimaluf>         # Servidor de PXE
[17:16] <guimaluf>         next-server 150.164.3.236;
[17:16] <guimaluf>         server-name "brontes";
[17:16] <guimaluf>         filename "pxelinux.0";
[17:16] <guimaluf> }
[17:23] <cropalato> guimaluf, thanks
[19:16] <burnbrighter> It appears in the latest release of maas, the default route needs to be set manually? Is that a bug or by design?
[19:16] <burnbrighter> latest apt-get release rather
[19:48] <roaksoax> smoser: ping
[19:48] <roaksoax> smoser: https://bugs.launchpad.net/ubuntu/+source/cobbler/+bug/858867/comments/5
[19:48] <roaksoax> burnbrighter: what's your issue?
[19:49] <roaksoax> burnbrighter: what do you mean by default route?
[19:56] <burnbrighter> roaksoax: on enlist, it appears the default route isn't being configured
[19:58] <roaksoax> burnbrighter: you mean it is no enlisting?
[19:59] <burnbrighter> on pxe boot, the default route is not being sent
[20:00] <burnbrighter> maybe its cobbler not sending the info correctly
[20:00] <burnbrighter> or setting up the configuration?
[20:00] <burnbrighter> this worked in my previous maas release
[20:01] <roaksoax> burnbrighter: so if machines are not PXE booting, it is a matter of configuring the DHCP correctly.
[20:02] <roaksoax> burnbrighter: if they are PXE booting but not enlisting, maybe the IP address the MAAS server has is not the one in the configuration
[20:02] <burnbrighter> it PXE boots, but then it's not picking up the default route
[20:02] <burnbrighter> so as it does its initial configuration and is doing the install
[20:02] <burnbrighter> its not getting a default route via dhcp
[20:02] <burnbrighter> it gets an IP address, but no default route
[20:03] <roaksoax> burnbrighter: ah so that's a problem of the DHCP server or even of the installer itself
[20:03] <burnbrighter> correct - but that's configured by maas
[20:03] <burnbrighter> right?
[20:03] <burnbrighter> or maas -> cobbler
[20:03] <roaksoax> burnbrighter: maas attempts to configure it, and tells it to cobbler
[20:04] <burnbrighter> ok, so something broke there
[20:04] <roaksoax> burnbrighter: so what's the pastebin from /etc/cobbler/dnsmasq.template
[20:04] <roaksoax> q1
[20:05] <burnbrighter> sure, hang on
[20:05] <burnbrighter> sorry, what is ubuntu's pastebin?
[20:05] <burnbrighter> url
[20:06] <roaksoax> pastebin.ubuntu.com
[20:06] <roaksoax> burnbrighter: you can install pastebinit
[20:06] <roaksoax> and run: pastebinit /etc/cobbler/dnsmasq.template
[20:07] <burnbrighter> http://paste.ubuntu.com/1097228/
[20:07] <roaksoax> burnbrighter: is this your default gateway? dhcp-option=3,172.16.100.11
[20:08] <burnbrighter> yes
[20:08] <roaksoax> burnbrighter: run sudo cobbler sync and pastebin the output please
[20:10] <roaksoax> burnbrighter: so maas has a caching server, would you be hitting it maybe?
[20:10] <burnbrighter> sorry - need to step away for a bit , will be back
[20:11] <roaksoax> sure
[20:42] <guimaluf> i give up of this maas stuff!!! past one week I couldnt make it work!
[20:42] <guimaluf> i've sync the clocks. changed ephemeral images. raw configs. nothing works!
[20:47] <roaksoax> guimaluf: i would say otherwise, I have had various deployments of MAAS working
[20:47] <roaksoax> guimaluf: what are your issues anyway?
[20:48] <guimaluf> (0x7f33b5f30700):ZOO_ERROR@handle_socket_error_msg@1579: Socket [127.0.0.1:47231] zk retcode=-4, errno=111(Connection refused): server refused to accept the client
[20:48] <roaksoax> guimaluf: that seems to be juju issue, not maas
[20:48] <guimaluf> this time. I've pass so many things... everytime clock problem.
[20:49] <guimaluf> but maas cant deploy the ssh-key properly
[20:50] <roaksoax> guimaluf: edit /var/lib/cobbler/kickstarts/maas.preseed and search for the passwrod line and remove the ! and set your password there
[20:50] <roaksoax> guimaluf: then you would be able to ssh in an debug the problem of why the keys are not being installed
[20:50] <guimaluf> it install the os but I needed to include a default password by myself and even after deploy the sshkey by hand i got this juju problem
[20:50] <guimaluf> I check everything on web, and the problem is the same. time sync oauth clock problem
[20:51] <guimaluf> your maas deployments are working properly? deploy sshkeys and everything else?
[20:51] <roaksoax> if that's the issue then would be matter of making maas' server clock the same as the clients. We are currently working on trying to get that fixed
[20:52] <roaksoax> guimaluf: yes my maas deployments work fine. I've tested the ssh key inyection in various escenarios as well
[20:52] <guimaluf> roaksoax, I fix it in many ways.
[20:52] <guimaluf> maybe the problem occurs because the maas server isnt the dhcp server
[20:52] <roaksoax> smoser: ^^ oauth issues causing ots of pain, is there a recommended fix?
[20:53] <guimaluf> now even with the keys set properly this juju thing dont work :/
[20:53] <guimaluf> i'm really tired :( whole week just for this.
[20:53] <guimaluf> i've installed so many times, so many times!
[20:53] <smoser> work around is described in comment 5 at http://paste.ubuntu.com/1097303/
[20:53] <smoser> err.
[20:53] <smoser> comment 5 at https://bugs.launchpad.net/maas/+bug/978127
[20:54] <guimaluf> sorry my whinning
[20:54] <roaksoax> guimaluf: https://bugs.launchpad.net/maas/+bug/978127/comments/5
[20:54] <roaksoax> that's the work around for the issue you are having
[20:54] <roaksoax> smoser: btw... did you read the cobbler stuff?
[20:54] <smoser> roaksoax, i did.
[20:54] <roaksoax> smoser: any thoughts?
[20:55] <guimaluf> roaksoax, I allready did that. :/
[20:55] <roaksoax> guimaluf: is the juju client accessible to the nodes via DNS ?
[20:56] <guimaluf> yes, I put the node address in /etc/hosts
[20:57] <smoser> roaksoax, just commented in bug.
[20:58] <roaksoax> guimaluf: well I think we'd need logs in order to determine what is wrong
[20:58] <guimaluf> roaksoax, which ones?
[20:58] <roaksoax> smoser: ok ;)
[20:58] <roaksoax> guimaluf: in the bootstrap node, we'd need cloud-init logs, juju logs
[20:59] <smoser> guimaluf, roaksoax is right. if you can get to the bootstrap node (via ssh), then we need to see what went wrong.
[20:59] <smoser> i suspect there are errors in /var/log/cloud-init-output.log if you pastebin that
[21:00] <guimaluf> smoser, I can ssh the node just because I've put the keys by hand. :/ anyway. i'm pasting, just a sec
[21:01] <smoser> (just in case you were unaware, guimaluf there is a tool called 'pastebinit' that pastes to paste.ubuntu.com from file or stdin)
[21:01] <guimaluf> smoser, yes, ofcourse :)
[21:05] <guimaluf> cloud-init: http://pastebin.ubuntu.com/1097316/
[21:05] <guimaluf> juju -v status: http://pastebin.ubuntu.com/1097319/
[21:05] <smoser> guimaluf, /var/log/cloud-init-output.log ?
[21:06] <smoser> your maas server seems to have given empty user-data to cloud-init.
[21:06] <guimaluf> smoser, there's no file with this name
[21:06] <smoser> (as evidence by 'Unhandled non-mlutipart userdata '')
[21:06] <smoser> right.
[21:06] <smoser> lok.
[21:06] <smoser> (duh, it wouldn't be there... you didn't get any cloud-config user data to tell it to write it :)
[21:06] <smoser> so now, your issue is that that node is not geting to the maas server.
[21:07] <guimaluf> but this user is set in the maas.preseed?
[21:07] <smoser> user?
[21:07] <smoser> ok. i have to run
[21:07] <guimaluf> which user are you talking about?
[21:08] <smoser> you said "this user"
[21:08] <smoser> i didn't know what that meant.
[21:08] <smoser> ah. user-data.
[21:08] <guimaluf> sorry, poor english :/
[21:08] <smoser> so, to debug from here.
[21:08] <smoser> the issue is that cloud-init does not get data from the maas server
[21:08] <roaksoax> guimaluf: can you pastebin /etc/maas/maas_local_settings.py?
[21:08] <smoser> so you need to debug that
[21:08] <smoser> roaksoax, i have to run
[21:08] <smoser> but there should be files in /etc/cloud.cfg.d
[21:08] <roaksoax> smoser: alright thanks for the input
[21:08] <smoser> that have Maas config info
[21:09] <smoser> and /usr/share/pyshared/cloudinit/DataSourceMAAS.py is a maas user-data client of sorts
[21:09] <guimaluf> smoser, thanks alot man! :) I will bother roaksoax a little more!
[21:09] <smoser> python /usr/share/pyshared/cloudinit/DataSourceMAAS.py --config /etc/cloud/cloud.cfg.d/91*.cfg crawl <htat-url>
[21:10] <smoser> find which file has "maas" in it in /etc/cloud/cloud.cfg.d (grep would work)
[21:10] <smoser> open it.
[21:10] <smoser> it has a url in it
[21:10] <smoser> and do like the above
[21:10] <guimaluf> roaksoax, http://pastebin.ubuntu.com/1097339/
[21:10] <smoser> that will show you an error, or at least trigger one hopefully
[21:10] <smoser> later.
[21:11] <roaksoax> guimaluf: I think I found the issue
[21:11] <roaksoax> guimaluf: is this DEFAULT_MAAS_URL = "http://150.164.3.236/" the IP address for the local network?
[21:11] <roaksoax> MAAS's IP address for the local network?
[21:11] <guimaluf> yes
[21:13] <roaksoax> guimaluf: can you pastebin apache's log? (/var/log/apache2/error.log and /var/log/apache2/access.log)
[21:13] <burnbrighter> roaksoax: sorry, now back - here is the pastebin you requested: http://paste.ubuntu.com/1097349/
[21:15] <roaksoax> burnbrighter: are the client machines precise or quantal?
[21:15] <guimaluf> roaksoax, http://pastebin.ubuntu.com/1097352/
[21:16] <guimaluf> invalid consumer :/
[21:17] <roaksoax> guimaluf:
[21:17] <roaksoax> 150.164.3.240 - - [17/Jul/2012:17:37:22 -0300] "GET /MAAS/metadata//2012-03-01/meta-data/public-keys HTTP/1.1" 404 230 "-" "Python-urllib/2.7"
[21:17] <roaksoax> 150.164.3.240 - - [17/Jul/2012:17:37:22 -0300] "GET /MAAS/metadata//2012-03-01/user-data HTTP/1.1" 404 242 "-" "Python-urllib/2.7"
[21:17] <roaksoax> that seems to be an issue
[21:18] <roaksoax> guimaluf: So, nodes have enlisted, they have commissioned, and they were ready to deploy ebfore using juju?
[21:18] <guimaluf> roaksoax, but my ssh is there in the root preferences
[21:19] <roaksoax> guimaluf: what it seems is that no cloud-init meta-data or user-data have been generated, as if the node hasn't commissioned
[21:19] <guimaluf> but every step occurs properly.
[21:20] <guimaluf> the node is enlisted, comissioned and ready
[21:20] <guimaluf> now is Allocated to root
[21:20] <burnbrighter> roaksoax: precise
[21:20] <roaksoax> burnbrighter: that's strange then, it might be an issue with dnsmasq
[21:21] <burnbrighter> it appears something broke between the latest release and the last because this worked with out problems before
[21:22] <roaksoax> burnbrighter: when was the last time you upgraded quantal's maas version?
[21:23] <burnbrighter> today - I had been not working on things for about two weeks
[21:24] <roaksoax> burnbrighter: can you sudo apt-get update && sudo apt-get install python-txtftp and see if an update gets installed
[21:25] <roaksoax> guimaluf: uhmm so the problme seems to be the fact that the client is not getting the meta-data / user-data from the MAAS server. Config file seems just fine
[21:25] <guimaluf> roaksoax, is not a problem of time syncronization. what else can be?
[21:25] <roaksoax> guimaluf: would be helpful if you juju bootstrap and pastebin the error/access log from apache while the node is PXE booting and installing, and what happens after install
[21:26] <roaksoax> guimaluf: and check whether the node is complaining about not being able to reach the meta-data server (client node)
[21:27] <guimaluf> roaksoax, i think the Invalid Consumer in the error.log happen when I was installing the nodfe
[21:28] <roaksoax> guimaluf: ok, so do you have physical access to the client maas node?
[21:28] <guimaluf> yes
[21:28] <roaksoax> guimaluf: do you have a screen connected to it?
[21:28] <guimaluf> yep
[21:29] <guimaluf> should I flush maas db again and reinstall the node?
[21:29] <guimaluf> I did that 1208397198237 times xD
[21:30] <roaksoax> guimaluf: ok, so, juju bootstrap, after installation finishes it will reboot. Once it boots into logging prompt, it should show that 1. either is failing to get meta-data or 2. it is being able to obtain meta-data. If yo could see what shows there and let me know, that would be very helpful
[21:30] <roaksoax> guimaluf: or 3. when you fluished the db, you might have flashed node information that has the cloud-init meta-data
[21:31] <guimaluf> roaksoax, I didnt flushed the db this time
[21:31] <guimaluf> I start from scratch again
[21:31] <guimaluf> was my last try before "give up"
[21:32] <roaksoax> guimaluf: so the screen output should tell if something wrong is going on
[21:32] <roaksoax> it will 1. either obtain the user-data and do stuff with it (cloud-init). 2. or cloud-init will complain about not being able to reach the maas-server
[21:32] <guimaluf> roaksoax, so I should reboot my node right now and check what happens before the login prompt?
[21:32] <roaksoax> guimaluf: reinstall the node please
[21:32] <guimaluf> ok
[21:33] <guimaluf> there's a secure way for removing the node?
[21:33] <guimaluf> I always do cobbler system delete and maas shell Node.objects.all().delete()
[21:33] <roaksoax> guimaluf: yeah I guess that would work. however, before you do that
[21:34] <roaksoax> guimaluf: could you pastebin: sudo cobbler system getks --name node-XYZ
[21:34] <roaksoax> where node-XYZ is the node-XYZ from sudo cobbler system list
[21:34] <roaksoax> that is your bootstrap node
[21:34] <guimaluf> sure :)
[21:35] <guimaluf> roaksoax, http://pastebin.ubuntu.com/1097392/
[21:36] <roaksoax> cloud-init   cloud-init/maas-metadata-url  string http://150.164.3.236/MAAS/metadata/ -->that seems right, its telling that it should contact the MAAS server for meta-data
[21:37] <roaksoax> guimaluf: please proceed with the reinstall
[21:37] <guimaluf> ok
[21:37] <guimaluf> removing nodes...!
[21:38] <guimaluf> wow, I can delete the node from the UI it isnt allocated to root!
[21:38] <roaksoax> yeah
[21:38] <guimaluf> :)
[21:38] <guimaluf> good sign!
[21:39] <guimaluf> roaksoax, I should keep eye on "meta-data" information right?
[21:40] <roaksoax> guimaluf: yes, it should appear right on the screen after the installation proices, after the reboot (before/after showing the logging prompt)
[21:40] <guimaluf> after comissioning right?
[21:42] <roaksoax> guimaluf: 1. enlist. 2. accept & commission. (turn on the node and allow it to commission) 3. juju bootstrap. 4. wait installation to finish and reboot. 5. watch :)
[21:42] <guimaluf> juju bootstrap?
[21:43] <guimaluf> juju bootstrap runs on the node?
[21:43] <roaksoax> guimaluf: yes
[21:43] <roaksoax> guimaluf: it runs the bootstrap node which is juju
[21:43] <roaksoax> guimaluf: it runs the bootstrap node which is juju's zookeeper
[21:43] <roaksoax> guimaluf: you always need that node to deploy with juju
[21:44] <guimaluf> but I dont run manually right?
[21:44] <roaksoax> if juju bootstrap doesn't start a node automatically, then you need to start it manually
[21:44] <guimaluf> juju bootstrap is for the local machine?
[21:45] <roaksoax> guimaluf: make sure your .juju/environments.yalm is also correctly configured
[21:45] <guimaluf> roaksoax, in my maas server right?
[21:45] <roaksoax> guimaluf: if you are running juju ocmmands from your maas server, then yes
[21:45] <roaksoax> juju bootstrap will take 1 node from the maas pool of servers
[21:46] <guimaluf> there is a error
[21:46] <guimaluf> util.py
[21:46] <roaksoax> huh?
[21:47] <roaksoax> pastebin
[21:47] <guimaluf> util.py[WARNING] 'addres.../metadata/DATE/meta-data/instance-id' failed http error [403]
[21:47] <guimaluf> I cant pastebin this one
[21:47] <roaksoax> that;s commissioning
[21:47] <guimaluf> yes
[21:47] <roaksoax> guimaluf:  that's oauth issue then i thjink
[21:48] <roaksoax> please apply the patch as above
[21:48] <guimaluf> which patch?
[21:49] <guimaluf> still commissioning. if I reboot the node it will commit
[21:49] <roaksoax> err work around for the ephemeral iomage
[21:49] <roaksoax> https://bugs.launchpad.net/maas/+bug/978127/comments/5
[21:49] <guimaluf> its done already
[21:49] <roaksoax> maybe the image iupdateed by the cron job that's why it failed
[21:51] <guimaluf> I rebooted the node, it will be commissioned now.
[21:53] <guimaluf> roaksoax, after the commissioning many py errors showed up on the screen, but I couldnt get it
[21:54] <roaksoax> guimaluf: can you show the log from apache? error and access please
[21:54] <guimaluf> error.log is the same
[21:56] <guimaluf> roaksoax, http://pastebin.ubuntu.com/1097427/
[21:57] <roaksoax> guimaluf: so does the MAAS Web UI say the node is ready?
[21:57] <guimaluf> roaksoax, strangely now it is allocated to root
[21:57] <roaksoax> there's an error there: 150.164.3.240 - - [17/Jul/2012:18:55:55 -0300] "GET /MAAS/metadata//2012-03-01/meta-data/instance-id HTTP/1.1" 403 239 "-" "Python-urllib/
[21:57] <guimaluf> yes, the same error.
[21:57] <guimaluf> reboot and goes normal
[21:57] <roaksoax> so it seems ot be failing commissioning
[21:58] <guimaluf> now it is installing
[21:59] <roaksoax> ok so lets wait and see :)
[21:59] <guimaluf> this python-urllib is happening everytime, then I reboot and everything runs as expected
[22:03] <roaksoax> but after it installed ubuntu
[22:04] <roaksoax> before/after logging pronmt onreboot after installatio n
[22:04] <roaksoax> it should show cloud-init trying to do some work
[22:06] <guimaluf> no instance data found in start-init
[22:07] <roaksoax> yeah that's what's failing
[22:07] <roaksoax> i need to run for a bit now
[22:07] <guimaluf> ok
[22:07] <guimaluf> any glue or tip?
[22:07] <guimaluf> any glue or hint?
[22:08] <guimaluf> i'll search for that
[22:08] <guimaluf> thank you very very much for everything
[22:08] <guimaluf> worked!
[22:08] <guimaluf> :D
[22:08] <guimaluf> AEUhaUEhaUEHA
[22:08] <guimaluf> LOL
[22:08] <guimaluf> it works!
[22:09] <guimaluf> but maybe it is because I put the authorized_keys inside the /home/ubuntu/.ssh/ of the node
[22:09] <guimaluf> and i think the juju bootstrap before the installation process helped alot!
[22:09] <guimaluf> roaksoax, thanks man! really thanks! :D
[22:26] <burnbrighter> roaksoax: http://paste.ubuntu.com/1097463/