=== CyberJacob is now known as CyberJacob|Away === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away === matsubara-afk is now known as matsubara === menn0_ is now known as menn0 [11:01] Hi ! [11:03] I use MAAS 1.7 and juju [11:03] All work fine, it's magic :) [11:03] i have one machine with maas, and one node bootstrapped by juju [11:04] and all work fine [11:04] i want to add a new node now. Maas can show it, and the commissioning is fine [11:04] did u know how can i add it to juju now ? [11:05] i don't find it when i lauche "juju status" [11:05] launch* [11:06] if i start "juju add-machine negligible-band.maas", i got " error: malformed container argument "negligible-band.maas"" [11:07] and for "juju add-machine ssh:negligible-band.maas", i got : " ERROR rc: 255 (ssh: Could not resolve hostname negligible-band.maas: Name or service not known) " [11:42] ok i found. Just "juju add-machine" and boot it :) === plars is now known as plars-afk [14:07] Slaan: glad you figured it out, let me know if you have any other questions === jfarschman is now known as MilesDenver === plars-afk is now known as plars [17:44] anyone have experience running maas with HP blade nodes? I can't seem to get maas to recognize the logical drives from the hp smart array [18:13] Nobody? [18:55] sbtechcom, MAAS supports HP iLO but not sure about HP smart array [18:58] gotcha, so that pretty well rules out all HP blades and enterprise servers... [18:59] If I update a user provided preseed in the format of "{prefix}_{node_architecture}_{node_subarchitecture}_{release}_{node_name}", should those changes be reflected immediately within the maas GUI by viewing that node's preseed? [18:59] to my understanding anyways.. have to check to see if they have a direct controller that doesn't do raid [19:00] sbtechcom: is this hpvsa or hpdsa or something? [19:03] it's using hpwdt driver right now [19:04] nm [19:04] that's the ilo... still looking [19:05] cciss driver is being used on the controller array. This is all default MaaS. I have a feeling I need to do some modifications to load the correct drivers to talk to lvm but am really not sure now to go about doing it [19:17] this any help as to what is happening? Stderr: u'lsblk: /dev/cciss!c0d1: not a block device\n' [19:18] looks like some sort of enumeration error when listing out devices from the cciss driver === CyberJacob|Away is now known as CyberJacob [19:30] does anyone have a few minutes to help me figure out why my user provided preseeds aren't working in MAAS 1.7? [19:31] designated: you may need to restart apache, i don't recall [19:31] sbtechcom: where would lvm be coming into play? [19:33] designated: looks like the pattern is now {prefix}_{osystem}_{node_arch}_{node_subarch}_{release}_{node_name} [19:35] jhobbs: where did you find that documentation? http://maas.ubuntu.com/docs1.7/development/preseeds.html shows something different [19:35] in the code :( [19:35] doc is out of date, submitting a patch right now [19:36] great...bitten again by shitty documentation. :/ [19:36] jhobbs: thank you for your help. [19:37] gotcha, so I used the debian installer to deploy a node and I don't get that error so I am not sure if it actually relates to how the information is discovered by maas [19:38] sbtechcom: where exactly are you seeing that error? and when? [19:38] designated: you're welcome [19:39] jhobbs: do you know the syntax for {osystem}? [19:39] i think it's just 'ubuntu' [19:39] ubuntu [19:39] jhobbs: that error occurs when acquiring and starting a node using the fast installer, using the debian installer I don't get the error. [19:39] blake_r: ^^ ? [19:41] real issue here is that MaaS does not see two disks so the openstack installer in landscape won't accept the nodes as valid [19:45] Hey, where's the documentation on adding custom images? I've been looking at the CLI reference at mass.ubuntu for trunk and 1.7 and can't find anything [19:47] jhobbs: once I have ubuntu loaded on the node Ubuntu (on the actual node) sees both disks just fine, MaaS still does not list them however and lists that same error in the installation log [19:49] Hey guys, I'm having a very weird problem comissioning some servers into our cluster. [19:49] if anyone is interested, I finally got the user provided preseeds to update in MAAS 1.7 by using the following: preseed_master_ubuntu_amd64_generic_trusty_{hostname}.{domain} [19:51] commissioning or enlist no longer appear to be valid prefixes [19:51] but I may be wrong about that one, it didn't work for me [19:52] Our whole cluster is connected to a dedicated switch. Most of our machines are comissioned just fine, but two of them fail every time. However, if they're connected *directly* (that is, not by the switch, but directly NIC to NIC by a single cable) they comission just fine. We tried different cables and switch ports, but it didn't work. What mystifies me the most is that the other machines work. What could be causing this? [19:53] thebozz: does you switch have STP enabled? [19:54] thebozz: sometimes it delays a port coming up long enough to prevent pxe boot from working [19:54] ^^ but in that case they also wouldn't enlist, right? [19:54] yeah i don't see why it'd be different for commissioning vs enlistment [19:55] maybe they enlisted manually [19:55] oh that may be... [19:55] Dunno the answer to that, let me ask. [20:03] jhobbs: with STP you mean 'spanning tree protocol'? [20:04] yea [20:04] Yep, it's enabled. [20:04] i bet that's the problem [20:05] you can either configure the nodes to only pxe boot, and to retry after a failure [20:05] Alright! I'll turn it off and try again. [20:05] in their bios [20:05] or yeah turn it off or enable portfast [20:05] sbtechcom: so i'm not really sure what's going on for you- can you file a bug? [20:07] Haha same suggestion I'm getting at ##networking. [20:07] Which would be best? [20:08] jhobbs: I can, thanks for your help! [20:12] thebozz: hehe that's probably a question for your network admin, if he needs STP, then you need to configure the retry. If STP is not needed, disabling it would be easier as there's no per-node config to do [20:13] I will talk to him then, and check what he thinks is best. The switch is dedicated to the cluster, so whatever we do won't affect the rest of the network anyway. [20:19] STP is funny like that - if it's disabled and you create a loop it can very well bring down the rest of the network [20:19] * jhobbs has done it before [20:23] It worked! jhobbs, you da man! [20:25] thebozz: hooray! [20:32] BTW, we're having another issue with how MAAS detects hard drives... it only shows the capacity of the first drive on each machine. We set each drive on a single-drive RAID0... did we mess up? [20:33] thebozz: what version of MAAS are you using? even very recent MAAS versions have issues detecting storage correctly [20:37] 1.7.0 [20:38] yeah so - 1.7.1 should fix that [20:39] BTW, what does it mean if it doesn't detect the storage size correctly? Will we not be able to use that storage? [20:39] thebozz: it is just an issue of display, not really underlying [20:40] will it be an issue if you want to deploy to a node with X storage (juju deploy --constraints="disk=XXX") and maas doesn't think the node fits the constraint? [20:40] Alright, seems we're good to go. [20:41] roadmr: yeah that too [20:41] one can work around it by setting storage size for nodes manually though [20:41] yes, that's true [20:41] yup [20:41] but after upgrade to 1.7.1 [20:41] you should just be able to recommission [20:41] and that's it [20:41] I'll be releasing 1.7.1rc1 in ~30 mins [20:43] \o/ cool! [20:43] Last question: is it acceptable to just put every disk in its own single-drive RAID0? We couldn't get some machines to detect the drives unless we did that. [20:46] thebozz: that should be fine [21:24] jhobbs, are you still there? I need your magic powers again... [21:24] hi thebozz [21:24] Hi, long time no see, haha. [21:26] So we comissioned the whole cluster without a hitch, then tried to deploy OpenStack on top of it. My boss says he used the automatic deployment (whatever that means, I wasn't involved in the installation). After a while, it says "A fatal error has occurred: Problem with juju bootstrap." The commands.log file says this about it: http://pastebin.com/JFC02xyn [21:28] Sorry, forgot to enter the captcha before sending the link. If you couldn't open it try now. [21:30] thebozz: that node should have an install log in MAAS - can you have a look at it there and see what it says? [21:30] thebozz: also i'd recommend trying out deploy nodes manually with maas before using juju/openstack installer, just to make sure the maas layer is working fine [21:31] The log doesn't contain any errors, but I copied it anyway: http://pastebin.com/zKi32etS [21:34] can you ssh into the system yourself? [21:37] Nope, seems it turned itself off. [21:38] Yeah, the server's off. [21:39] so if i were you i would check maas by itself first - make sure you can deploy nodes and ssh into them [21:40] then check juju & maas - make sure you can bootstrap with it [21:40] then move onto openstack [21:46] Nope. I tried acquiring and starting two nodes - the one from before and another, and I can't SSH into any of them. [21:48] The first one shows pretty much the same install log as before. The second one, however, says this: http://pastebin.com/p8ufNY2L [21:54] Gotta go now. I'll take a better look at this tomorrow and check if I can understand this better. [22:04] Hello, I don't see boot-sources anymore in the 1.7 maas. [22:04] what was this replaced with? [23:40] Does anyone know what I need to put in the preseed to answer NO to "The partition table format in use on your disks normally requires you to create a separate partition for boot loader code. This partition should be marked for use as “Reserved BIOS boot area” and should be at least 1 MB in size." === CyberJacob is now known as CyberJacob|Away