[00:13] <bradm> how do we make maas refresh what it knows about a server?  I have a node that's had memory added to it, and its still showing the old amount
[00:52] <bigjools_> bradm: needs re-commissioning
[00:52] <bigjools_> bradm: let me check if there's a way to edit
[00:54] <bigjools> sadly no
[00:54] <bigjools> you can cheat and use "maas shell"
[00:54] <bradm> bigjools: is that a destructive command, the re-commissioning?
[00:55] <bradm> bigjools: ie, I already have things deployed to it via juju, will that be left alone?
[00:55] <bigjools> bradm: well you can't do it if the node is in use
[00:55] <bigjools> needs to be taken out of rotation
[00:55] <bradm> bigjools: ouch.
[00:55] <bigjools> bradm: as I said you can cheat and use maas shell
[00:56]  * bigjools brb
[00:56] <bradm> bigjools: the use case I'm thinking of is that we've deployed something, found out we need more ram, and add it.  its not the end of the world to not have it updated, but seems like it'd be nice to have a simple way to do it.  I'll look into maas shell and see if that'll do what we need
[00:58] <bigjools> bradm: I'll pastebin an example
[00:58] <bigjools> hang on
[00:58] <bradm> sure, no rush - this isn't a major issue, just something I've noticed while deploying something
[01:08] <bigjools> bradm: ok well it's all Python, so you can use "from maasserver.models import Node" and then Django filters to get the node object you want
[01:09] <bradm> bigjools: right.
[02:15] <ging> how does setting a password for the default user work in maas ? the default sets passwd/user-password-crypted to password ! - i tried a few things with this but not with any luck but it takes me some time to keep retrying it, should i be able to set it to either string password or password md5hash ? ideally i'd rather set it with a hash if possible
[02:15] <bigjools> ging: do not set a password, use ssh public key aith
[02:18] <ging> bigjools: i've not been having much luck with that at the moment, but also we are planning to use it to deploy ubuntu desktop to desktops, the IT department have insisted they have a local admin user they can login directly with which seems reasonable given the usage
[02:18] <bigjools> ging: then use cloud-init to configure special users,  but
[02:18] <bigjools> if they want a password instead of ssh auth they're a bit mad
[02:19] <bigjools> ging: let me know how you get on deploying ubuntu-desktop, since maas is designed to deploy server
[02:21] <ging> bigjools: we are planning on testing it on real desktops in 48hours
[02:28] <ging> bigjools: do you know if replacing the ! from the default value user-password-crypted with the hash out of the shadow file should work to enabled passworded login?
[02:29] <ging> i expected it would but it didn't but now i am wondering if i made a mistake rather than it not working
[03:08] <bradm> bigjools: fwiw, I don't think only ssh key auth is sufficient - what about the times when you need to log into a console to see whats going on?
[03:33] <ging> i'm not sure how much of security advantage there is from having no local login at all, over having a local login with password with ssh restricted to key athentication
[03:38] <bradm> I'd agree, there are plenty of reasons why you might want to log into the console - even as simple as firmware updates you want to apply
[04:04] <lifeless> you need a local OAUTH based user code created for all machines
[04:04] <lifeless> yeah
[04:14] <ging> i've made it work now, by adding the hash where i thought it should go, but by default ssh passworded login is enabled, that is ok for my use at the moment, but would obviously not be for internet facing servers
[04:47] <bigjools> bradm: fair point
[05:01] <ging> can someone explain what should happen when enrolling a node via cd? currently for me they just shutdown after selecting the maas server, and just boot back to the cd again when restarted nothing in the maas logs atall to show they even connected to the maas server
[05:02] <bigjools> ging: not supported, don't do it that way.  It's getting removed in Trusty.
[05:03] <bigjools> as you can see it's broken :)
[05:03] <bradm> wow, how do I actually redeploy a node?  I've deleted it, recomissioned, and told juju to redeploy, and its _still_ the same old filesystem
[05:18] <ging> ok thanks bigjools
[05:24] <ging> i think i am going to make some people cry when i tell them this
[05:51] <ianous> bradm: What do you mean it's the same old filesystem? Didn't it re-install everything from scratch?
[06:02] <bradm> ianous: no, it did not
[06:07] <ianous> Do you have access to the machine to check if it's pxe-booting correctly?
[06:09] <bradm> yeah, its definately pxe-booting
[06:09] <bradm> it seems to go through the motions, but it must just be reinstalling on the same drive, without formatting
[06:11] <bradm> just trying to remove the node completely and redo it
[06:12] <ianous> It doesn't feel like something it should do...At least with the stock preseed_master mine wiped everying out.
[06:26] <bigjools> bradm: it means it didn't pxe boot and is local booting the old install
[06:26] <bigjools> but I should read scrollback more
[06:27] <bigjools> reinstalling without formatting?  wtf!
[06:27] <bigjools> I've never seen that happen and I have done about a million redeployments
[06:29] <ianous> Can't you avoid that with some clever switch in the preseed?
[06:29] <bradm> bigjools: yeah, I definately saw pxebooting, and it didn't seem to format the disk, but I definately saw package installs
[06:29] <bradm> I've removed the node, booted from pxe, which added it back in, and set it going again, seems fine now
[06:29] <bigjools> bradm: using d-i or curtin?
[06:30] <bradm> bigjools: it looks like standard d-i to me, I didn't set this maas server up
[06:35] <bigjools> bradm: well that's mad!
[06:35] <bradm> bigjools: I see you triaged my bug as wishlist :)
[06:35] <bigjools> is this a bug in d-i?
[06:36] <bigjools> yeah I'm being realistic
[06:36] <bradm> for sure, I have no issues with that
[06:36] <bradm> and its not a hugely important issue either, really.
[06:36] <bigjools> aye
[06:36] <bradm> just wanted it documented
[06:37] <bradm> what I'm seeing now after removing the node isn't the same as the d-i screens I'm seeing, so I'm not 100% sure on what was going on
[06:37] <ianous> whic reminds me...has anyone lost the api commands from maas-cli?
[06:38] <bradm> bigjools: its also possible I did something in the wrong order or something, this is my first real lot of MaaS deploys
[06:39] <bigjools> bradm: honestly no idea.  the only reason I can think of for seeing the same filesystem as before is that something local booted.  It is possible to do that after pxe booting, maas can tell it to local boot.
[06:40] <bigjools> d-i really should wipe things
[06:40] <bradm> bigjools: I feel fairly comfortable that it is, it wasn't d-i I saw before
[06:40] <bradm> bigjools: if this works I'm happy to say I was just doing something wrong, basically trying to redeploy without deleting the node
[06:41] <bigjools> ok. you had me worried
[06:41] <bradm> I definately saw some kind of apt install happening in the past, but it wasn't from d-i
[06:44] <bigjools> do you have the fast installer turned on?
[06:44] <bradm> bigjools: I don't think so
[06:45] <bigjools> cloud-init does do a lot of installations
[06:45] <bigjools> maybe you saw its console output
[06:45] <bradm> yeah, could be, its hard to say
[06:45] <bradm> this is looking much nicer, definately a fresh fs
[06:45] <bradm> and juju is deploying as expected
[06:45] <bradm> although I have old units for the machine hanging around dying.
[06:47] <ianous> bradm: I had that annoying thingie... At juju 1.16 you can destroy-machine --force to get rid of it
[06:47] <bradm> ianous: I did hear something about that, but the help didn't say
[06:48] <ianous> when I couldn't see it I just lacked the right version
[06:48] <bradm> ianous: it doesn't work with juju 1.16.0
[06:48] <ianous> 1.16.5 then
[06:48] <ianous> (I had to double-check it)
[06:49] <bradm> I'll likely be redeploying this environment once I'm all sorted with it anyway
[07:18] <bradm> bigjools: aha, I redid the delete node thing, I think I was just seeing part of the enlisting process
[10:57] <rvba> jtv: time for a review? https://code.launchpad.net/~rvb/maas/multiple-dhcp-intf2/+merge/203703
[10:57] <jtv> OK
[11:03] <jtv> rvba: branch reviewed.  I have a WIP here: https://code.launchpad.net/~jtv/maas/allow-multiple-managed-interfaces/+merge/203708
[11:03] <jtv> I still want to add one or two integration tests though.
[11:04] <jtv> I'll take a break first, but that branch should get us there.
[11:05] <rvba> Okay.
[13:27] <tomixxx> hi, @jtv: yesterday, after re-install the maas-server, i was able to add one node to the server. the node is "ready" now :-)
[13:31] <jtv> tomixxx: glad to hear it!
[13:31] <tomixxx> ty, ty for your help :-)
[13:32] <tomixxx> jtv: There is only one question left: How do the node get access to internet? Because I have observed that the node was not able to download various packages while booting.
[13:33] <jtv> They download through a proxy that's running on the region controller.
[13:33] <jtv> It's squid-deb-proxy.
[13:33] <tomixxx> So, you mean the nodes do not need access to the internet?
[13:33] <jtv> That's right.
[13:34] <jtv> Unless you want them to do internetty work, of course!
[13:34] <tomixxx> Next step, i want to deploy juju and openstack.
[13:35] <tomixxx> Theoretically spoken, how is it possible to connect the nodes to the internet?
[13:35] <jtv> Several ways, actually.
[13:36] <tomixxx> The easiest? :D
[13:36] <jtv> Easiest?  Hook up all the nodes to an additional network, which is securely isolated from all the netbooting and stuff, and gets routed to the internet.
[13:36] <jtv> Then there's cheapest.  :)
[13:36] <jtv> Cheapest is to give the MAAS network a route to the internet.
[13:38] <tomixxx> My maas server has access to the internet through another network interface
[13:38] <jtv> Right.  So one thing you can do is set up forwarding in your server's firewall.
[13:39] <tomixxx> So a kind of "bridging" ?
[13:39] <jtv> Yup.  NAT would probably make the most sense — also makes it a bit harder for an attacker to get at the power management.
[13:39] <jtv> You probably don't want strangers shutting down systems remotely just for the fun of it.  :-)
[13:40] <tomixxx> hehe
[13:40] <jtv> I haven't set this up in a long time, so I'd probably be a bad person to ask.  At the time I managed it with iptables, but there's probably much easier ways now.
[13:42] <tomixxx> kk, one thing i wounder about: at the end of the boot, the node printed a list and most of the items were "succeed" but one item "failed". And, i guess the node was not able to download some packages... is this normal?
[13:43] <jtv> If it really was a package install, no, that's not normal and you might want to dig up some proxy logs on the server to see if anything is amiss.
[13:43] <tomixxx> dunno exactly but it was sth with archive.ubuntu.com
[13:43] <jtv> But it's not abnormal for some other things to "fail" during a normal boot IIRC.
[13:44] <tomixxx> ok
[13:44] <jtv> If it was archive.ubuntu.com then yes, that's probably a package download that failed.
[13:45] <jtv> It's possible that it just gets retried though, so if you see it again, it might be worth noting the package name and seeing later if it ended up OK.
[13:46] <tomixxx> Ok, when i processed through the installation guide (http://maas.ubuntu.com/docs/install.html), I had to download the images, but the command $ maas-cli maas node-groups import-boot-images did not work. So i did sudo maas-import-pxe-files
[13:46] <tomixxx> This worked but maybe this is the reason why some package downloads failed or is everyhting ok so far? ^^
[13:48] <jtv> Shouldn't be...  IIRC the only difference is that if you ran the script by hand, it would be a direct download, not using the proxy.
[13:48] <jtv> But the images and the packages are very much separate things.
[13:48] <jtv> When you commission a node, it runs from an image that it downloads from the cluster controller — it'll install just 2 packages or so from the archive.
[13:49] <jtv> Then, when you deploy, it runs an installer image which it also downloads from the cluster controller; and then it downloads more packages from the archive.
[13:49] <tomixxx> hmm ok
[13:49] <jtv> Those package downloads go through the proxy.
[13:49] <tomixxx> the proxy is the maas-server?
[13:50] <jtv> Runs there, yes.  So that you get a bit of cache re-use between downloads.
[13:50] <jtv> For example, every cluster controller needs to download images — but as long as they all do that through the same proxy, it's not so bad.
[13:50] <tomixxx> I understand.
[13:52] <tomixxx> So, maybe everything just work :-)
[13:52] <jtv> Hals— und Beinbruch.  :)
[13:53] <tomixxx> ty :-)
[13:54] <jtv> No worries.  I'll enjoy seeing this come to life!
[13:58] <tomixxx> ok, adding 2nd node now :D
[13:59] <jtv> Once that works, the world's your oyster.  :)
[13:59] <jtv> rvba: my "allow" branch is up for review now.  I think I'll call it a night.
[14:00] <tomixxx> Here i can see: failed to fetch http://security.ubuntu.com/buntunt/dists/precise-security/RElease.gpg Temporary failure resolving "security.ubuntu.com"
[14:01] <jtv> So... DNS trouble.
[14:01] <tomixxx> And then: Some index files failed to download. They have been ignored, or old ones used instead.
[14:02] <jtv> That means that you're probably not getting (some?) security updates.  I can resolve that hostname without problems, so there may be a problem with your DNS.
[14:02] <jtv> (My internet is probably not as good as yours :)
[14:02] <tomixxx> you mean the DNS of the maas-server?
[14:03] <jtv> I think this gets resolved at the proxy, in which case I think it wouldn't be the DNS server that MAAS itself runs, but the "upstream" one.
[14:03] <jtv> But it could be set up either way, and I don't know off the top of my head which it is.  :/
[14:04] <tomixxx> hmm, in my luster controller i set "Manage DHCP and DNS"
[14:04] <tomixxx> however, the node is declared "ready" - like the oder node
[14:05] <jtv> Which is good news.
[14:06] <tomixxx> yeah, iam just a little bit worried because of these download failures...
[14:06] <jtv> The setting means that the region controller runs a DNS server, but I don't know off the top of my head if the proxy running on the region controller will use that for its own DNS lookups.  I'm guessing not.
[14:06] <jtv> Yes, that failure suggests that you're running a slightly outdated version of the OS.
[14:06] <tomixxx> OO
[14:06] <tomixxx> so an old image?
[14:07] <jtv> No, just old packages.
[14:07] <jtv> The hostname that failed to resolve is for the archive that provides the latest updates.
[14:07] <jtv> (Strictly no new features, just urgent bug fixes).
[14:08] <jtv> But AFAIK the system will periodically download the indexes again and install any such updates.
[14:10] <tomixxx> ok
[14:21] <tomixxx> how can i uninstall juju completely? want to re-install it too
[14:23] <jtv> tomixxx: about the most complete you can do is uninstall the package along with all its configuration, using "apt-get --purge remove <package>"
[14:23] <tomixxx> jtv: ty
[14:23] <jtv> Note that for more complex pieces of software, you may have to remove multiple packages.
[14:24] <jtv> After that, the command may tell you that some packages no longer have any use (as far as it knows) on your system.  If so, you can consider whether those need the same treatment.
[14:25] <jtv> Time to go... Good night!
[14:25] <tomixxx> gn8!
[14:25] <jtv> :)
[14:48] <tomixxx> do i have to install juju on the maas-server or on a node?
[14:49] <tomixxx> ah ok it is definitely doing sth on one of my nodes so i guess it works
[16:31] <ticking> hey is there any information on what could cause "Can not apply stage final, no datasource found! Likely bad things to come!"
[16:32] <ticking> I just upgraded to the latest cloud-tools maas and my setup no longer works (worked fine with the latest 2013 release)
[16:44] <ticking> I have to admit, maas has been incredibly frustrating
[18:06] <smoser> ticking, hm..
[18:06] <smoser> what did you upgrade from ?
[18:06] <ticking> smoser: I think the october or november version
[18:06] <smoser> and was that on a deploye'd system (or enlistment)
[18:08] <ticking> smoser: as in production use? or in configured with juju?
[18:10] <ticking> sorry, sloppy internet connectin
[18:10] <ticking> I'm currently reloading all pxe images, maybe this will fix it
[18:11] <ticking> it seems that the problem is with invalid rabbit credentials
[18:11] <ticking> maybe they will get corrected with this :/