[01:01] <Set_Phone> Hello
[01:04] <Set_Phone> Bigjools you around
[01:05] <bigjools> hi
[01:05] <bigjools> you take various guises I see
[01:06] <Set_Phone> So I upgraded to trusty. But now having ipmi enlistment issues
[01:07] <Set_Phone> Yeah on my phone
[01:08] <Set_Phone> Only error I get is "no power type detected"
[02:33] <Lord_Set> Ok I am back. My phone had issues and missed whatever you may have responded earlier Bigjools.
[02:34] <bigjools> could you elaborate with your problems
[02:35] <Lord_Set> So every time I enlist a new node now no ipmi/ilo is detected at all.
[02:35] <bigjools> what package version do you have
[02:35] <Lord_Set> Of which exactly?
[02:35] <bigjools> maas
[02:36] <Lord_Set> Sec
[02:37] <Lord_Set> 1.5+bzr1977-0ubuntu2
[02:39] <bigjools> can you try the package in the daily PPA, it should have fixed this
[02:39] <bigjools> sudo add-apt-repository ppa:~maas-maintainers/dailybuilds
[02:39] <Lord_Set> Sure
[02:40] <bigjools> then you will truly be bleeding edge
[02:40] <Lord_Set> When updating MAAS do you recommend doing a regular upgrade or full-upgrade?
[02:41] <bigjools> you're using aptitude?
[02:41] <Lord_Set> Yes
[02:41] <Lord_Set> I prefer it
[02:41] <bigjools> don't, use apt-get
[02:41] <Lord_Set> Ok
[02:41] <Lord_Set> Why? Just curious
[02:41] <bigjools> aptitude has different conflict resolution rules to apt-get, and the distro team only tests with apt-get
[02:41] <Lord_Set> Ok makes sense
[02:41] <bigjools> so you could end up with a bad installation
[02:42] <bigjools> so apt-get dist-upgrade
[02:42] <Lord_Set> I wish I knew that earlier
[02:42] <bigjools> I never use plain upgrade
[02:43] <Lord_Set> Alright I will try and re-enlist those nodes
[02:55] <Lord_Set> hmm yay... give me a bit. I think I have a server issue now. Restarted the server after the update and ssh isn't responding now.
[03:03] <bigjools> jtv: why is our customised CalledProcessError (ExternalProcessError) doing this?
[03:03] <bigjools>         cmd = u" ".join(quote(self._to_unicode(part)) for part in self.cmd)
[03:03] <bigjools> the base class version just prints cmd as a string
[03:03] <jtv> bigjools: I guess to deal with bytes-shaped command-line args...
[03:04] <bigjools> jtv: well particularly the join I mean
[03:04] <jtv> Oh.  Because self.cmd is a list.
[03:04] <bigjools> no, it's a string :)
[03:04] <bigjools> look at the base class
[03:04] <Lord_Set> What is the release date for 14.10?
[03:05] <jtv> Does CalledProcessError take its command as a string?  I thought it was a list.
[03:05] <bigjools> Lord_Set: April 17
[03:05] <Lord_Set> Thanks. Looking forward to it!
[03:05] <bigjools> jtv: the check_call stuff in PYthon does this:
[03:06] <bigjools>         cmd = kwargs.get("args")
[03:06] <jtv> So "cmd" is a list there.
[03:06] <jtv> And then it converts that to a string..?
[03:07] <bigjools> seems so
[03:07] <jtv> Although actually... we don't normally call it with the command list in kwargs, do we?
[03:07] <jtv> Normally this would make cmd be None.
[03:08] <bigjools> it falls back to cmd = popenargs[0]
[03:08] <jtv> Because we just pass check_call(['command', '--option', 'arg']) without kwargs.
[03:08] <jtv> Ah, so it strips away the arguments and returns just the base command.
[03:08] <jtv> Not ideal if the command is something like sudo!
[03:08] <bigjools> yup!
[03:09] <bigjools> I'll change the code so it provides a better error anyway
[03:09] <bigjools> (fixing the omshell thing)
[03:10] <jtv> Yes, CalledProcessError expects the problem to manifest as a non-zero return code.  What we have with omshell is a different reason to report failure.
[03:10] <jtv> Not CalledProcessError, sorry.  The other one.  Ours.
[03:10] <jtv> ExternalProcessError.
[03:10] <bigjools> jtv: yeah, it exits with zero even if a command fails
[03:11] <jtv> Which...
[03:11] <jtv> Ewww.
[03:11] <jtv> But hey, compared to the problems I've been having with dig lately, this is just run-of-the-mill evil.
[03:11] <jtv> dig prints its errors to stdout.
[03:11] <bigjools> yuuuup
[03:11] <jtv> Which AFAICT we don't get to see when dig fails in tests, as happens sometimes.
[03:12] <jtv> And our enlistment user data fails to check for an error return from dig, so we get error messages being used as hostnames.
[03:27] <roaksoax> bigjools: alright
[03:27] <roaksoax> i'm back
[03:27] <roaksoax> bigjools: so, the problem is that if a user upgrades MAAS
[03:27] <roaksoax> and then tries to enlist or commissioning new nodes
[03:27] <roaksoax> then it will fail
[03:28] <roaksoax> cause trusty images are not available anymore
[03:28] <roaksoax> err
[03:28] <roaksoax> are not available because they haven't been imported yet
[03:31] <bigjools> roaksoax: I don't have a problem with that
[03:31] <bigjools> people need to read release notes and pull images in
[03:31] <bigjools> however I am open to be convinced otherwise
[03:33] <roaksoax> bigjools: yeah but this is not about people reading release notes. This is about supporting backwards compatibility to existing users
[03:33] <roaksoax> bigjools: if you can avoid it, you should not just break them
[03:33] <bigjools> roaksoax: there's nothing that's not backwardly compatible
[03:33] <roaksoax> bigjools: Yahoo will be deploying their cloud in precise
[03:33] <bigjools> import the image, move on
[03:33] <bigjools> and nothing stops that
[03:34] <roaksoax> bigjools: what if they upgrade to new cloud-archive and they hundreds of servers fail to enlist because something silly as defaulkt to only use trust
[03:34] <roaksoax> trusty*
[03:34] <roaksoax> such a silly thing can create big problems
[03:34] <roaksoax> this is my opinion at least
[03:34] <bigjools> ok
[03:35] <bigjools> let's collect some more opinions and see
[03:35] <Lord_Set> Yahoo will be using MAAS to deploy a precise cloud?
[03:35] <roaksoax> bigjools: alright! Tycho also raised his concern on the email IMHO. Not that I'm not against of doing it, I'm just thinking of the implications this might have
[03:37] <bigjools> roaksoax: like I said, I am open, I just want to make sure we're not doing this because we're afraid of moving forwards, it's such a simple thing to get working
[03:38] <roaksoax> indeed
[03:38] <roaksoax> Lord_Set: it was just an example
[03:43] <bigjools> jtv: plz to be reviewing: https://code.launchpad.net/~julian-edwards/maas/omshell-remove-fail-bug-1285244/+merge/208521
[03:50] <jtv> da tovarich
[04:23] <jtv> bigjools: and could you review https://code.launchpad.net/~jtv/maas/prefer-i386-if-arch-unknown/+merge/208525 ?
[04:23] <bigjools> jtv: with pleasure
[04:26] <bradm> this is interesting, every now and again my MaaS server gives me a 401 unauthorized, but if I repeat the command, works fine
[04:27] <bradm> haven't figured out how to produce it on demand yet though
[04:31] <bigjools> bradm: nonce re-use?
[04:31] <bigjools> and I hate that word
[04:33] <bradm> bigjools: this is for simple things like juju status against a maas based juju environment
[04:33] <bradm> bigjools: in the same shell I run it multiple times, sometimes it just says unauthorized
[04:34] <bigjools> bradm: one of two things usually: nonces or time is off
[05:20] <bigjools> jtv: any idea why this is failing? https://bugs.launchpad.net/maas/+bug/1285233
[05:21] <jtv> It was expecting a MAC object, and got a str instead.
[05:21] <bigjools> no shit :)
[05:21] <jtv> MAC is a wrapper which we needed to work around Django's awkward custom-field API.
[05:21] <jtv> Basically, Django doesn't know whether the value it gives you to convert needs converting or not.
[05:21] <bigjools> indeed
[05:22] <jtv> So there _has_ to be a type difference that you can use to figure it out for yourself.
[05:22] <bigjools> so self.mac_address is returning the string, not the MAC
[05:23] <jtv> Looking up the bug...
[05:24] <jtv> That looks like it may be a cleaning problem.
[05:24] <jtv> Where sometimes you get to see the field value in its uncleaned state, sometimes in its cleaned state.
[05:24] <jtv> I'd fix it by making the __unicode__ method capable of dealing with either.
[05:25] <bigjools> yeah, more egregious hacks ...
[05:26] <jtv> Because Django was written to Usually Work Easily instead of provide a solid framework.
[05:33] <jtv> bigjools: https://code.launchpad.net/~jtv/maas/bug-1283918/+merge/208530
[05:48] <bigjools> jtv: given the machinations in MAC.__init__ how is _wrapped ever not a string?
[05:49] <bigjools> IOW why is mac_address itself a string in the bug
[05:50] <bigjools> ah nm
[05:56] <bigjools> jtv: https://code.launchpad.net/~julian-edwards/maas/mac-address-get-raw-bug-1285233/+merge/208537
[06:20] <Lord_Set> I am watching the Ubuntu UDS Q - Next Steps for Hadoop on Ubuntu and it is a great video so far
[06:51] <Lord_Set> So thoughts... for an admin workstation/server should I give Ubuntu Desktop or Server with Gnome installed on it over Windows Server 2012 R2? I am kind of skiddish about it is because I have like all my network administration and other tools all Windows based.
[07:04] <jtv> Lord_Set: you could give those tools a whirl on WINE to scope out the change.
[07:04] <Lord_Set> True, I completely forgot about WINE.
[07:37] <Lord_Set> I swear everytime I import boot images I get the slowest mirror ever
[07:37] <Lord_Set> That caps me at like 10,000kbps
[07:39] <jtv> Poor kid.
[07:39] <jtv> You're serious about the "k" in there, right?
[07:40] <jtv> I mean, I've seen them at 10,000Bps.
[07:41] <Lord_Set> Yes
[07:42] <Lord_Set> I should be getting my full like 60,000 from here!
[07:42] <jtv> Oh dear.  How _do_ you cope?
[07:42] <Lord_Set> I know they must hate me when I download from Switch SuperNAP with our 1gbps line.
[07:43] <Lord_Set> What are the ISP like in Lithuania?
[07:43] <jtv> This is like something I sometimes do in office environments: "Slow?  Let me check... no, I'm downloading all Friday the 13th movies here and I'm getting nearly our full rated bandwidth!"
[07:44] <jtv> Lithuania?  Good question.  I could probably ask someone.
[07:44] <jtv> But I expect the answer: "cold."
[07:44] <Lord_Set> Oh nm. Was just the server you are connected to.
[07:44] <Lord_Set> Where are you from?
[07:44] <jtv> The Netherlands.
[07:45] <Lord_Set> Ahh ok. Good metal bands there.
[07:56] <Lord_Set> So... still receiving "No Power Type Defined" after nodes have enlisted
[07:56] <Lord_Set> What logs would you like?
[09:34] <Lord_Set> I know the MAAS team is most likely busy but anyone want to help me debug and fix the ipmi autodetect function of maas enlistment for trusty using the daily maintainer ppa...
[09:37] <jtv> (LS tried running maas_ipmi_autodetect_tool.py manually on a node and got this error: http://pastebin.ubuntu.com/7004118/ )
[09:50] <rvba> jtv: so
[09:50] <rvba> :)
[09:50] <jtv> Hi once more.  :)
[09:50] <rvba> jtv: the enlistment image was picked at random.  Without even checking if it's there or not.
[09:50] <jtv> Typing in a slow ssh session just hurts the wrists anyway.  :)
[09:50] <rvba> (But the connection seems to work)
[09:50] <rvba> (Which is good news, you can use the lab now :))
[09:50] <Lord_Set> picked at random?
[09:51] <jtv> What I saw in the code I fixed was it picking an image that was actually available, for a given nodegroup, release, and purpose; but arbitrary arch.
[09:51] <jtv> And "arbitrary" meant "first alphabetical," which usually worked because... amd64.
[09:51] <rvba> jtv: right, and amd64 wasn't imported for some reason hence why arm was picked up
[09:52] <rvba> jtv: allenap is there → call
[09:52] <jtv> He's been here for a while!
[09:52] <jtv> Why hasn't he called?
[10:03] <jtv> Done with the meeting.
[10:05] <jtv> Lord_Set: looks as if bmc-config is not present on the system you tried that script on.
[10:05] <jtv> Weird though how that's an OSError, not a CalledProcessError.
[10:06] <jtv> But yup, that's what happens.
[10:06] <jtv> And that's why it's not printing the actual command.  :(
[10:06] <jtv> Lord_Set: can you install freeipmi-tools?
[10:07] <Lord_Set> Yep
[10:07] <Lord_Set> Done
[10:07] <Lord_Set> Did it need the tools to run?
[10:07] <jtv> Yes.
[10:08] <Lord_Set> Oh ok
[10:08] <Lord_Set> Will rerun now
[10:08] <jtv> Please do.
[10:15] <Lord_Set> http://pastebin.ubuntu.com/7004302/
[10:15] <Lord_Set> Same error on 2 servers
[10:15] <jtv> Looking.
[10:15] <Lord_Set> A dell and hp
[10:16] <Lord_Set> both have DRAC/ILO reset to defaults
[10:16] <jtv> Hmm... that sounds familiar.
[10:18] <jtv> jhobbs, do you have any idea what might be the problem here?  Lord_Set is having trouble detecting BMCs, and running detection manually produced http://pastebin.ubuntu.com/7004302/
[10:18] <jtv> Probably too early — gross timezone mismatch IIRC.
[10:18] <Lord_Set> I can post the full debug and verbose output if required.
[10:19] <Lord_Set> Yeah...
[10:20] <Lord_Set> What is the best time to speak with those that are mostly responsible for the power management functions of MAAS?
[10:20] <jtv> Americas.
[10:20] <Lord_Set> Ok
[10:20] <jtv> Which...
[10:21] <Lord_Set> It is 2am PST here
[10:21] <jtv> I sort of guessed.  :)  I meant Americas, _office_ hours.  :-)
[10:21] <jtv> Roughly speaking — we're still in IT.
[10:21] <Lord_Set> lol. Do they work in one of the Canonical offices?
[10:22] <jtv> I suppose it's biological Wednesday for me.  It's getting to be Thursday evening for me.
[10:22] <Lord_Set> Just trying to figure out what time zone
[10:22] <jtv> No, not very office-bound IIRC.
[10:23] <jtv> Wait...
[10:23] <Lord_Set> Oh ok
[10:23] <Lord_Set> Well I guess I will do one more thing here and then continue later today.
[10:23] <jtv> This is embarrassing.  A loop that keeps re-assigning first_unused until the end, and then returns first_unused.
[10:23] <Lord_Set> Or go home and play around more and see if I can get it working but I am just learning Python
[10:24] <jtv> Anyway, it seems that you've run out of user slots.  Might be worth having a look at what users have been defined.
[10:24] <Lord_Set> There are no users defined except for the default 1 currently
[10:24] <jtv> Hmmm
[10:25] <jtv> From the comments, it's also possible that the BMC simply returns an unexpected default name for unused slots.
[10:25] <Lord_Set> Yeah but it would be odd to be doing the same thing with more than one type of ipmi controller.
[10:25] <jtv> Ah, I think I'm beginning to understand that loop.  Why do people not hate complexity?
[10:26] <jtv> Well if any of them already had the right user registered, the autodetect code would detect that and re-use the slot.
[10:26] <Lord_Set> Also, each of these controllers, well all 3 that have failed so far have a max of 10 slots
[10:26] <Lord_Set> The most amount of users I have ever configured is like 3
[10:27] <jtv> Let me just see where the detection code gets its list of possible slots...
[10:28] <jtv> Could you maybe paste me the output of "bmc-config -L"?
[10:28] <Lord_Set> Sure
[10:29] <Lord_Set> http://pastebin.ubuntu.com/7004355/
[10:30] <jtv> Okay, I think it would pick up the User<number> slots.
[10:30] <jtv> It does make me wonder actually how it could ever find and re-use an existing slot.
[10:31] <jtv> In the autodetect code, list_user_numbers scans this output for "^(User\d+)$".
[10:31] <jtv> That result then gets used for pick_user_number_from_list.
[10:31] <jtv> It skips "User1".
[10:32] <jtv> It iterates over the rest.
[10:32] <Lord_Set> hmm ok
[10:32] <jtv> For each, it queries the existing user.
[10:32] <jtv> If that matches the user name it wants, it's done.
[10:33] <jtv> Otherwise, it picks the first slot where the returned user was either None or "(Empty User)" (case-sensitive exact match).
[10:33] <jtv> If that fails too, you get what you see here.
[10:35] <jtv> Could you give me, for example, the output of "bmc-config --checkout --key-pair=User5:Username"?
[10:35] <Lord_Set> Sure
[10:35] <jtv> The question is whether it matches  r'^\s*Username(?:[ \t])+([^# \t\r\n\v\f]*[^\n]+)$'
[10:35] <jtv> but you knew that.  :)
[10:36] <jtv> Obvious, right?  Simple short regex like that.
[10:36] <Lord_Set> I did
[10:36] <jtv> I wonder if there's any variability in that whitespace...
[10:37] <Lord_Set> root@ADMINWRK:/home/daniel# bmc-config --checkout --key-pair=User5:Username
[10:37] <Lord_Set> Section User5
[10:37] <Lord_Set>         ## Give Username
[10:37] <Lord_Set>         Username
[10:37] <Lord_Set> EndSection
[10:37] <jtv> OK
[10:38] <jtv> So... empty username.
[10:39] <jtv> And so I think bmc_user_get() would have returned None...
[10:39] <Lord_Set> Which doesn't explain the error sadly
[10:40] <jtv> In fact, it doesn't mesh with the error at all.
[10:40] <jtv> Maybe you could edit the autodetect tool and do some printf debugging?
[10:40] <Lord_Set> Unless there is an issue with how the string is being interpreted making it think all user slots are taken
[10:40] <jtv> Inserting some print() in pick_user_number_from_list could tell us a lot.
[10:41] <Lord_Set> I can do that for sure. Why not make one for me and I can put it on my MAAS controller and run it against all the servers I am trying to test deploy.
[10:41] <jtv> If we knew for each iteration in the loop in pick_user_number_from_list what user_number and username were, I think that'd pinpoint the problem.
[10:41] <jtv> Sure.  Coming up.
[10:41] <Lord_Set> Thanks
[10:42] <jtv> One server at a time would be fine for me actually.  Why buy trouble?  :)
[10:42] <Lord_Set> i just don't want to mess it up and waste time
[10:42] <Lord_Set> True
[10:42] <Lord_Set> I can do one server at a time
[10:42] <jtv> By the way, I think you'll come out of this knowing and loving Python!
[10:43] <Lord_Set> lol yeah. I have to learn it anyways for Cisco Nexus stuff.
[10:43] <Lord_Set> Cisco got the awesome idea of integrating a full python scripting engine into their Nexus datacenter switches.
[10:44] <Lord_Set> Which is why I think it would be awesome if MAAS played with Nexus as well as an option. The possibilities are endless and amazing to think about with switch configuration automation.
[10:44] <jtv> Critical network infrastructure.  Turing complete scripting.  What could go wrong?  :)
[10:44] <jtv> Updated script: http://paste.ubuntu.com/7004413/
[10:44] <lifeless> jtv: welcome to openflo
[10:44] <jtv> But yes, actually it does sound very cool.
[10:45] <jtv> Hi lifeless!
[10:45] <lifeless> jtv: o/
[10:45] <Lord_Set> Like being able to deploy for example 5 servers from bare metal, bring up an openstack cluster automatically with Juju and configure all the VM specific networking and place all the servers in either a private vlan or a virtual switch on the switch segemented from everyone else for a customer
[10:45] <Lord_Set> It is all super possible with the Nexus line
[10:46] <jtv> We just implemented the basics of VLAN support.  I do wonder what the dividing line between "configure network" and "describe network" will look like.
[10:47] <Lord_Set> I love the vlan support
[10:47] <Lord_Set> Have you played with Openstack at all?
[10:47] <lifeless> jtv: Neutron :)
[10:47] <Lord_Set> Neutron is amazing. I can't wait for the Nexus 1000V vswitch for Ubuntu
[10:49] <Lord_Set> jtv: http://paste.ubuntu.com/7004440/
[10:49] <jtv> That does tell us something.
[10:49] <Lord_Set> Going to run it on an HP server now
[10:49] <jtv> It looks like those empty slots all belong to a user named ' '.
[10:50] <jtv> I don't see how just a blank could have matched that regex though.
[10:51] <jtv> Ahhhh
[10:51] <jtv> Zero or more of [^# \t\r\n\v\f]* — probably zero in this case.
[10:51] <jtv> Followed by one or more [^\n]
[10:51] <jtv> — which would include the space!
[10:52] <jtv> Lord_Set: I think this version would give a different (and hopefully better) answer... http://paste.ubuntu.com/7004457/
[10:53] <Lord_Set> Hmm interesting. It just worked on this server. I wonder if the file on the maas controller is different from the one being tested now.
[10:54] <jtv> I'm filing a bug.
[10:55] <Lord_Set> Running the new version on the Dell server
[10:55] <Lord_Set> Going to test it on a different HP
[10:55] <Lord_Set> That worked for the Dell
[10:57] <Lord_Set> I just noticed something that would be beyond nice for this script... Well as an option for MAAS in general. Users should have the option to specify a static IP range for IPMI assignment. I know you can enable DHCP for the IPMI but that also opens up decent risks as well security wise.
[10:59] <Lord_Set> Anyways, nice work jtk. Fixed that bug as far as I can tell right now.
[11:01] <Lord_Set> err jtv
[11:02] <jtv> Lord_Set: https://bugs.launchpad.net/maas/+bug/1285607
[11:02] <Lord_Set> Awesome thanks
[11:02] <jtv> We're moving away from caring too much about IPMI IP addresses.
[11:02] <jtv> We'll use MACs instead.
[11:02] <jtv> Look up IPs on the fly.
[11:03] <Lord_Set> That works as well
[11:03] <jtv> I guess you could put the IPMI on a separate network, if you want good separation.
[11:03] <Lord_Set> But if a IPMI is already configued with an erroneus ip address from an old deployment it won't resolve in the new network
[11:04] <jtv> AIUI we'll do a fresh lookup every time we need it, and that will actually override the old configured IP address.
[11:04] <Lord_Set> Especially if it configured for vlan tagging
[11:05] <Lord_Set> Like for example that Dell server is on a 10.10.10.0/24 network but the DRAC/IPMI is configured for the 10.87.89.0/27 network...
[11:06] <Lord_Set> The rest of the IPMI are currently just on the 10.10.10.0/24 as well for testing currently but in production they will be on a separate network in their own dedicated management/ipmi vlan.
[11:06] <jtv> Right.
[11:13] <Lord_Set> Anyways I am going to head home. It is 3am here and I have to be back for a meeting at 10:30.
[11:13] <Lord_Set> yay
[11:13] <jtv> Sleep harder!
[11:13] <jtv> nn
[11:13] <Lord_Set> Sleep is a rare commoditiy most days it feels like. Has been super crunch time trying to get things running and deployed these past few weeks.
[11:14] <Lord_Set> We gotta get our software developers working...
[11:50] <Settite_666> So where is the autodetect file location
[14:34] <Settite> Anyone around?
[14:34] <Settite> This is Lord_Set
[14:36] <Settite> I found an interesting issue with upgrading from 13.10 to 14.04 and upgrading MAAS along with it
[14:42] <roaksoax> Settite: here!
[14:42] <roaksoax> what issue did you find?
[14:44] <Settite> Awesome. So during the upgrade from 13.10 to 14.04 SSH keys seem to be regenerated
[14:44] <Settite> This obviously causes an issue when trying to authenticate with MAAS nodes that were spawned with a different ssh key that doesn't exist anymore.
[14:51] <roaksoax> robbiew: ^^
[14:51] <roaksoax> err
[14:52] <roaksoax> robbiew: sorry :)
[14:52] <roaksoax> rvba: ^^^
[14:53] <robbiew> lol
[14:56] <rvba> robbiew: it's becoming a classic :)
[14:58] <rvba> Settite: what SSH keys exactly?  Because MAAS only knows about the keys that you import.  It doesn't (re)generate them.
[15:04] <Settite> Correct. MAAS didn't regenerate the keys... Ubuntu did during the upgrade from 13 to 14. MAAS and the deployed nodes do not get updated based off of the key change.
[15:06] <rvba> Settite: I'm curious to know which keys were regenerated during an upgrade… ?
[15:08] <Set_Phone> The rsa pub and private keys I generated previously
[15:09] <rvba> You mean a public/private key pair in your home environment?
[15:10] <Set_Phone> Yes
[15:10] <Set_Phone> The only key pair I generated on the maas cluster controller
[15:10] <rvba> roaksoax: Why on earth would an upgrade touch these? ^
[15:11] <Set_Phone> I have no idea
[15:43] <Settite_666>  Does the MAAS team ever have community events or a podcast or regularly released videos or even a blog?
[15:49] <rvba> Set_Phone: The main community event for MAAS is UDS.
[15:49] <Set_Phone> Didn't know if you guys did anything more regular or not.
[22:46] <manjiri> hello! Is there a way to commission machines with custom image files?
[23:05] <bigjools> manjiri: you would need to replace the images in the TFTP path
[23:05] <bigjools> there's no easy way of doing this right now but it will get sorted out RSN
[23:06] <manjiri> bigjools: is there a detailed description of "how to" ?
[23:10] <bigjools> manjiri: 'fraid not
[23:11] <bigjools> the /var/lib/maas/ephemerals contain the images
[23:11] <bigjools> iirc
[23:12] <manjiri> bigjools: I am trying to understand the difference between "ephemerals" and "pxe files"
[23:12] <bigjools> manjiri: pxe files are the kernel and initd that the machine downloads to be able to net boot
[23:12] <bigjools> initrd, I mean
[23:13] <bigjools> ephemerals are the environment that is copied to tmpfs and mounted as root after booting
[23:13] <bigjools> or mounted with iScsi
[23:15] <manjiri> bigjools: Can you help me correlate that with an ISO for say, Precise 12.04.3 ?
[23:15] <bigjools> there are no isos involved here
[23:16] <bigjools> but a rough correlation would be that the iso is the equivalent of the ephemeral, and the pxe files are taken out of the iso so they can netboot the machine
[23:17] <manjiri> bigjools: yes, what I meant was, if I have an ISO, does it contain directly or indirectly the pxe files and ephemerals?
[23:17] <bigjools> have a look at the maas-import-pxe-files and maas-import-ephemerals scripts in maas
[23:17] <bigjools> indirectly it does, I think
[23:20] <manjiri> bigjools: I will take a look. Thanks for your help. (You can ignore the email I had sent earlier.)
[23:20] <bigjools> heh ok
[23:23] <manjiri> bigjools: on second thoughts, if you could send me a reply, I can tell my boss that it has been confirmed that this is not officially supported. (I assume you are an authority?)
[23:23] <bigjools> you assume correctly
[23:26] <bigjools> manjiri: thinking about it, maas uses the simplestreams library to download ephemerals, so you could just write a simplestreams source to serve up custom images
[23:29] <manjiri> bigjools: My interest primarily stems from the fact that my software includes a kernel module which is build against a particular kernel. I would like to make sure that kernel is the one that maas uses.
[23:29] <roaksoax> bigjools: /win 7
[23:29] <roaksoax> err
[23:29] <roaksoax> :)
[23:30] <bigjools> roaksoax: I would never use Windows 7
[23:30] <roaksoax> lol
[23:31] <manjiri> bigjools: Why so partial towards Windows 8 ?? j/k
[23:31] <bigjools> don't even joke about it :)
[23:39] <manjiri> bigjools: :-) My understanding of the ephemerals vs pxe files needs to be refined before I can tell whether simplestreams library will be of use. I am still not sure which will allow me to pin down the kernel module compatibility.