[04:08] <jtv> Hi bigjools — I have some documentation updates ready for the multiple networks per cluster, but what I'm still missing is a clear designing-your-network document.
[04:08] <bigjools> jtv: g'day
[04:08] <bigjools> jtv: I think some examples would be good but we don't want to be prescriptive do we?
[04:09] <bigjools> it's not like serious users will take notice anyway :)
[04:10] <jtv> I'm thinking not so much of an if-all-else-fails-rtfm thing, or a "how to unpack your ipod: 1. do not unpack under water or near impending nuclear explosions"
[04:11] <jtv> More "the things you'll want to know before you start with this"
[04:11] <bigjools> jtv: sounds good
[04:11] <jtv> Something that sets the expectations for what you can do with maas, and what you're going to need.
[04:12] <jtv> If you think it's useful for me to write up a first stab at such a document, I can put my current branch up for review first.
[04:14] <jtv> Ah.  Last night I put up a small branch to remove NodeGroup.get_any_interface(), which thank Kibo we no longer needed.  Raphaël not only approved it (his review notes being just "Scary!") but landed it before I changed my mind.  :-)
[04:22] <bradm> has anyone found any useful docs on getting maas to talk ipmi to hp proliant kit?  its not obvious to me after a reasonable search, and if someone could shortcut figuring it out, it'd be great :)
[04:23] <jtv> I think that's the same ilo as the microservers, right bigjools?
[04:24] <bradm> I've mostly got ilo3 and ilo4, the kit is hp proliant dl380 g6/7/8s, or there abouts
[04:24] <jtv> Some of us have that — g7 I think.  So it shouldn't be hard to get that documented.
[04:25] <jtv> With luck it's merely one of those situations where "yay it works" gives people the signal that they're done, and it's just a matter of getting them to write it down.
[04:26] <jtv> I do recall that there were some IPMI things it just won't do — such as a serial console.
[04:26] <bradm> yeah, thats fine, I think all I care about is the ability to power on / off the servers
[04:26] <bradm> the ilos work well for just about everything else
[04:26] <jtv> Hmm that ought to be standard fare...
[04:26] <bradm> well, they can power on and off the servers too, but I want MaaS to do it for me
[04:26] <bradm> its entirely possible there's something wrong with my ipmi setup, too
[04:27] <jtv> Yes, and that should work, right?
[04:27] <bradm> doesn't seem to
[04:27] <bradm> I've been having to manually power cycle things, over the ilo
[04:27] <jtv> :/
[04:27] <jtv> Have you tried it from the command line using ipmitool?
[04:27] <bradm> I've got 25 nodes in this maas cluster, it'll be more soon
[04:27] <jtv> Because the MAAS configuration should be very similar to that.
[04:27] <bradm> hm, no, I haven't
[04:28] <bradm> I wasn't even sure if that should work without config on the ilo side of things
[04:28] <jtv> MAAS needs to know the ilo's address, and IPMI login credentials.
[04:28] <bigjools> bradm: how do you have it set up right now?
[04:28] <bigjools> is it configured in maas and just doesn't work?
[04:28] <bigjools> or something else?
[04:29] <bradm> bigjools: in maas I have a power type of ipmi, driver auto detect, with the user and password
[04:29] <bigjools> bradm: can you see the power_on task appearing in the celery log?
[04:30] <bradm> bigjools: yes
[04:30] <bigjools> bradm: and it just fails then?
[04:30] <bigjools> as in doesn't turn it on?
[04:30] <bradm> bigjools: yeah
[04:31] <bigjools> bradm: did you try changing the driver type?
[04:32] <bigjools> bradm: you need 2.0 for proliant
[04:32] <bigjools> https://bugs.launchpad.net/maas/+bug/1086162
[04:32] <bradm> bigjools: not yet, I had a quick search and really didn't find much to explain how it should be done
[04:32] <ubot5> Ubuntu bug 1086162 in MAAS "IPMI based power management default to IPMI 1.5 based authentication" [High,Triaged]
[04:32] <bigjools> bradm: just edit the node
[04:32] <bradm> bigjools: yeah, but more as in what the next steps are, I can see how to change the driver :)
[04:32] <bradm> bigjools: is there some way to change the default for the maas server?
[04:32] <bigjools> well just try that
[04:33] <bigjools> not really
[04:33] <bigjools> the idea is that when the hardware enlists, its power type is set
[04:33] <bigjools> there is no sane default
[04:33] <bigjools> did you manually enlist these nodes or do a boot-enlist?
[04:33] <bradm> right, I thought there just might be a config setting
[04:33] <bradm> so that you could override what the default was
[04:33] <bigjools> there used to be a config but I ripped it out :)
[04:33] <bradm> it was a boot-enlist
[04:34] <bigjools> makes no sense in non-heterogeneous environs
[04:34] <bradm> so us heterogeneous folk have to suffer for it? :)
[04:34] <bigjools> ok so the bug is that the power type is not detected in the enlistment code
[04:35] <bigjools> bradm: does this help https://bugs.launchpad.net/maas/+bug/1086162/comments/6
[04:35] <ubot5> Ubuntu bug 1086162 in MAAS "IPMI based power management default to IPMI 1.5 based authentication" [High,Triaged]
[04:36] <bradm> bigjools: it, uh, could?  although I'm not exactly sure why you need something installed on the server if I'm talking ipmi to the ilo
[04:37] <bigjools> that's just a quick hack to make it use 2.0 on the cluster controller
[04:37] <bradm> oh, so it should be on the maas server?  I don't even have that directory
[04:37] <bigjools> you can also use maas shell to mass-edit the Node rows in the DB
[04:38] <bigjools> bradm: oh ignore me
[04:38] <bigjools> we don't use freeipmi any more
[04:39] <bradm> whew :)
[04:39] <bradm> ok, so I'll try setting the IPMI version to 2.0 for my next install, shouldn't be too long
[04:39] <bigjools> bradm: just edit one node to use LAN_2_0 and see if it works
[04:40] <bradm> a default setting for the ipmi type would be mighty useful
[04:40] <bradm> any time you have to set something manually is an opportunity for error
[04:43] <bradm> oh, bah, the only free node I have doesn't have network for whatever reason, but it does have ilo
[04:54] <bigjools> bradm: well the point is that the enlistment should work in the first place.  Defaults are workarounds.
[04:54] <bigjools> jtv: hahaha.  The iLO web interface for the N40L has a "use this tagged vlan" setting
[04:55] <bradm> bigjools: right, thats true.  but bugs do exist in software, and its nice to be able to tweak things to work around them.
[04:55] <bigjools> bradm: there's nothing stopping you from tweaking the setting
[04:55] <bradm> bigjools: and having to do it to every single server, and then remembering to do it every time I add a new one..
[04:58] <bradm> any sysadmin who's told they have to tweak a setting for every single server will say "Why isn't the default configurable?"
[04:59]  * jtv flashes bigjools an angry look
[04:59]  * bigjools bats eyelids at jtv
[05:00] <bigjools> bradm: even if you had a default power type, you still need to set the credentials
[05:00] <bigjools> it makes no sense for this at all
[05:32] <bradm> bigjools: hmm, I'm not sure I agree - its another thing that whoever sets it up will have to remember to reset - its obvious you have to do IP, username and password, but I could easily see the fact that it needs to be overridden overlooked by someone.
[05:32] <bradm> bigjools: but its not a huge deal
[05:32] <bigjools> bradm: you have to remember to set the credentials anyway
[05:32] <bigjools> if you['re doing it manually
[05:33] <bigjools> you're just asking for a workaround for a weird bug here, I'd rather fix the bug!
[05:33] <bigjools> if we set defaults for power types then it makes it harder to flag to the user that the power was not configured yet
[05:36] <bradm> bigjools: mmm, yeah, I guess.  I just find it frustrating when software makes me have to set values on things that could have a default.  I'm not sure how often someone would need to change this
[05:37] <bigjools> bradm: exactly, it needs setting once, correctly, when enlisting.   you're having to set it because of a bug, not because it has no default
[05:39] <bradm> bigjools: I have to wait for someone in the UK to wake up and start work before I can really test this, I've got openstack deployed to this maas server right now
[05:39] <bigjools> bradm: ok let me know when you can
[05:39] <bigjools> bradm: I think roaksoax will be interested in this, I though ipmi detection worked better on proliant
[05:40] <bigjools> thought*
[05:43] <bradm> bigjools: I wouldn't rule out some kind of misconfiguration here, I don't really know what I'm doing and am randomly clicking buttons. Plus I was handed over an existing setup :)
[05:43] <bigjools> bradm: heh ok
[05:43] <bradm> this ipmi type stuff isn't really documented anywhere obvious that I've seen
[05:49] <bradm> I'd kind of expected at least a mention of it in http://maas.ubuntu.com/docs/nodes.html, maybe
[05:57] <bigjools> bradm: ok
=== CyberJacob|Away is now known as CyberJacob
=== mwhudson is now known as zz_mwhudson
[10:17] <melmoth> hola. I have been asked how to tell maas to use a specific preseed file for a given node
[10:17] <melmoth> according to https://maas.ubuntu.com/docs/development/preseeds.html#user-provided-preseeds  it s possible
[10:17] <melmoth> but i dont undertsand how to get a list of valid value for all the "macro" defined {prefix}_{node_architecture}_{node_subarchitecture}_{release}_{node_name}
=== zz_mwhudson is now known as mwhudson
=== mwhudson is now known as zz_mwhudson
[11:09] <gmb> rvba, allenap, jtv: If you have a second, https://code.launchpad.net/~gmb/maas/bug-1274871/+merge/204195 is up for review.
[11:21] <rvba> gmb: lgtm
[11:22] <gmb> Ta
[11:32] <allenap> melmoth: I’m looking into that...
[11:39] <allenap> melmoth: So, if you look in /etc/maas/preseeds there are several files. To override curtin_userdata for an amd64 node named fred on which you want to run precises, for example, you’d create a file called curtin_userdata_amd64_generic_precise_fred.
[11:39] <allenap> melmoth: It’s a bit clumsy, I grant you, but perhaps you could explain what you need to do and I can see if there’s another way to do it?
[11:56] <melmoth> allenap, a customer (i m doing support) wants to generate per host preseed file, and i need to tell him how to do that
[11:57] <melmoth> so i have been given the url with the user-provider preseed, and i m just wondering what he should put in place of the {settings} to get a preseed that match a given node
[11:58] <allenap> melmoth: Okay. Generally, our advice would be: if the machine boots without customising the preseed, wait until it’s up then use, say, Juju or another tool to customise it at that point.
[11:59] <melmoth> what he wants is to install stuff on a given disk , so it needs to change that in the preseed
[11:59] <allenap> melmoth: Also, the templates are Tempita templates, so you can use any construct that they support, including embedding arbitrary Python. http://pythonpaste.org/tempita/
[12:02] <allenap> melmoth: In other words, you could customise an existing preseed and get it to lookup rules in a separate file according to node name. The node object is passed into the template, so you can use node.name, iirc.
[13:39] <gmb> allenap, rvba, jtv: Another wee branch for you to give some love to: https://code.launchpad.net/~gmb/maas/bug-1274912/+merge/204234
[13:40] <jtv> gmb: I'll take it.
[13:40] <gmb> Thankee
[13:41] <jtv> gmb: kindly COMMENT this kind of magic!  In fact I would say this kind of magic is far too vague.  Future generations will scratch their heads and be afraid to change the logic.
[13:42] <jtv> Can't get_effective_power_type() just return None for "none" or something?
[13:42] <gmb> jtv: Sure; I just did the same thing as start_power_nodes does because I was being lazy.
[13:42] <jtv> !?
[13:42] <gmb> I'll go fix it the *right way* :)
[13:43] <gmb> jtv: Seriously, go look :)
[13:43] <jtv> Suppressing a wildly generic error from a function somewhere else that might, now or in the future, raise it for unrelated reasons... <shudder>
[13:43]  * jtv goes look
[13:43] <jtv> start_power_nodes..?
[13:43] <gmb> er
[13:43] <jtv> Who is start_power_nodes?
[13:43] <gmb> start_nodes()
[13:43] <gmb> Sorry.
[13:44] <gmb> power mad.
[13:44] <jtv> Let's try to keep the golden middle between power mad and power hungry.
[13:45] <jtv> Argh.  So... repeating the same nonobvious try/except around the same function in multiple places...  If only we had a mechanism for writing code just once and then invoking it from multiple places!
[13:46] <gmb> jtv: So, I'm guessing this raising of a ValueError (which is, as you say, weirdlybollocks) is to do with this:
[13:46] <gmb> 458     # For strings, Django insists on abusing the empty string ("blank")
[13:46] <gmb> 459     # to mean "none."
[13:46] <gmb> 460     power_type = CharField(
[13:46] <gmb> 461         max_length=10, choices=POWER_TYPE_CHOICES, null=False, blank=True,
[13:46] <gmb> 462         default='')
[13:46] <gmb> So basically you're not allowed to have no power type
[13:47] <jtv> Might be, yes.  Django hasn't really embraced the null.
[13:47] <jtv> IIRC null=False means "do not go to the extreme measure of representing a null value as a null in the database."
[13:47] <rvba> Yes, that's what it means.
[13:48] <gmb> Yes.
[13:48] <jtv> Whereas blank=True means "this field may be left null, but we may store it as an empty string."
[13:48]  * jtv giggles insanely
[13:48] <gmb> You're not allowed a power type, unless we actually want to use the power type you don't have, in which case we don't worry about the fact that you don't have one.
[13:48] <jtv> So we may have an "if power_type is None" somewhere that should be an "if power_type == ''"
[13:48] <gmb> s/not allowed a/not allowed not to have a/
[13:49] <jtv> For a moment you sounded like my government.
[13:49] <gmb> jtv: No, I don't think so, but I'll check.
[13:50] <gmb> jtv: However, we treat '' as the node saying "I don't know what power type I have"
[13:52] <jtv> Ahhhh, get_effective_power_type deliberately raises that ValueError, but documents it as "an error."
[13:53] <jtv> One approach that's easy in Python and works well for these situations is to create an ad-hoc exception class, and document the function as raising that.
[13:58] <gmb> jtv: Right, I'll do that. Makes sense.
=== CyberJacob is now known as CyberJacob|Away
[14:58] <allenap> $Obligatory_rant_about_Django
=== freeflying is now known as freeflying_away
=== CyberJacob|Away is now known as CyberJacob
=== charles_ is now known as Guest79245