[07:03] <jam> mwhudson: poke, what channels do you usually sit in so I know where to find you?
[07:34] <lifeless> jam: #dunedintech? :)
[09:28] <rvba> Tiny branch up for review https://code.launchpad.net/~rvb/maas-test/ppa-rename/+merge/196501
[09:30] <jtv> I'll take it.
[09:30] <rvba> Thanks jtv.
[09:58] <jtv> Looks like we need to stop dhclient before we can grab the bootp port and discover DHCP servers.
[10:03] <jtv> Right now we don't specify the IP address we want to bind on yet, and doing so might soften the blow a bit.
[10:05] <bigjools> jtv: dhclient should not be running on a maas cluster controller anyway
[10:05] <bigjools> it needs to have a static ip
[10:06] <jtv> The problem is that we wanted to do this early on, before firing up a cluster controller...  I suppose we could do it after firing up the VM.
[10:06] <jtv> And inside the VM.
[10:07] <jtv> Then we can bind to the bridged interface, and probe from there.
[10:07] <bigjools> rvba: can I add a parameter in NodeGroupInterfaceHandler.update() that's not presented in DISPLAYED_NODEGROUPINTERFACE_FIELDS ?
[10:08] <rvba> bigjools: yes you can :)
[10:08] <bigjools> rvba: my first test has the field getting completely ignored
[10:08] <rvba> bigjools: weird, it should work all right.
[10:09] <rvba> bigjools: did you, by any chance, mark your field non editable?
[10:09] <bigjools> rvba: I did
[10:09] <rvba> That's the problem then.
[10:09] <bigjools> does that preclude its use from forms?
[10:09] <rvba> Yes
[10:09] <bigjools> crap
[10:09] <bigjools> ok
[10:24] <jtv> rvba: this MP may make you feel a little better... https://code.launchpad.net/~jtv/maas-test/maas-enums/+merge/196508
[10:25] <bigjools> rvba: so having corrected that I can see the right data in the form, which validates, but form.save() doesn't, ummm, save it...
[10:26] <rvba> jtv: nice!  Thanks for doing that.
[10:27] <jtv> May it brighten your days a little bit.  :-)
[10:28] <rvba> bigjools: did you add the field to the list of fields in odeGroupInterfaceForm.Meta?
[10:28] <rvba> NodeGroupInterfaceForm.Meta*
[10:28] <rvba> jtv: thanks for that ;)
[10:28] <jtv> My pleasure.  Seriously.
[10:29] <rvba> bigjools: if the answer to that question is "yes", I'll need to see your code :).
[10:29] <bigjools> rvba: urgh :)
[10:29] <bigjools> so many things to change
[10:30] <rvba> Just the model and the form.
[10:30] <bigjools> my sarcasm was too subtle :)
[10:32] <rvba> Yep, went way over my head :).
[10:38] <jtv> "That joke went right under my feet..."
[10:38] <jtv> More hnyargh: netifaces is not available in python 3?
[10:43] <bigjools> jtv: hence the code ...
[10:43] <jtv> But we're using netifaces elsewhere, aren't we?
[10:55] <bigjools> I wasn't aware at the time
[11:37] <rvba> Anyone up for a really tiny review? https://code.launchpad.net/~rvb/maas-test/add-virtualenv/+merge/196524
[12:07] <rvba> rbasak: btw (I know you're busy right now, so I'm happy if you give me a reply later), I tried installing uvtool on precise from https://launchpad.net/~uvtool-dev/+archive/trunk and I get http://paste.ubuntu.com/6473492/ (this is on a canonistack instance).  Is there another PPA I should add for uvtool to be installable?
[12:09] <rbasak> rvba: you need the cloud-tools pocket. "sudo add-apt-repository cloud-archive:tools". More at: https://wiki.ubuntu.com/ServerTeam/CloudToolsArchive
[12:10] <rbasak> rvba: I've added this to the uvtool PPA description. Thanks!
[12:55] <jam> rvba: I had a question about the "agent_name" stuff that was put together. Do you know (a) can you manually set it via maascli during acquire and (b) what version of MaaS was it released in ?
[13:00] <jam> the bug https://bugs.launchpad.net/maas/+bug/1239488 seems to indicate it was fixed in "saucy"
[13:00] <rvba> jam: Hi… a) yes, that's what juju does, it simply passes 'agent_name' as a parameter to 'acquire'. b) it was committed in revision 1710
[13:01] <jam> but the revno in cloud-tools archive looks to be bzr1639 which is older than 1706.2.1 that is where you landed it
[13:01] <rvba> Yeah, something seems wrong here.
[13:02] <rvba> jam: I suspect the fix was put in the packaging, as a patch.
[13:03] <rvba> jam: yeah, that's what https://bugs.launchpad.net/maas/+bug/1239488/comments/10 says.
[13:04] <jam> rvba: yeah, apt-get source gives me content that has agent_name
[13:06] <natefinch> rvba: I'm trying to set up virtual maas on  node in garage-maas, using this script: http://bazaar.launchpad.net/~virtual-maasers/charms/precise/virtual-maas/trunk/view/head:/README-nojuju.txt  however, calling ./register-node maaslocal   says that maaslocal is not a valid choice
[13:08] <rvba> natefinch: what's the error exactly?
[13:09] <natefinch> shared@maas:~$ sudo MEM=$((1024*1024)) ~/maas-libvirt-utils/register-node maaslocal
[13:09] <natefinch> usage: /usr/lib/python2.7/dist-packages/maascli/__main__.py [-h] COMMAND ...
[13:09] <natefinch> /usr/lib/python2.7/dist-packages/maascli/__main__.py: error: argument COMMAND: invalid choice: u'maaslocal' (choose from u'list', u'login', u'logout', u'refresh', u'admin', u'gavin', u'root', u'smoser', u'ubuntu')
[13:09] <natefinch> failed to talk to maas-cli
[13:10] <rvba> Looks like 'maaslocal' is the name of a profile that does not exist.
[13:12] <rvba> natefinch: you know that maascli has this notion of 'profile' right?
[13:12] <natefinch> rvba: no :)
[13:13] <natefinch> rvba: or rather, I do now
[13:13] <rvba> :)
[13:13] <rvba> So, when you log in, you give maascli credentials plus a profile name.
[13:13] <natefinch> rvba: can I just create a new profile?
[13:13] <rvba> And then, you can just that profile by running: maascli profilename <commands>
[13:14] <rvba> This allows you to have multiple profiles talking to (potentially) different maas servers.
[13:14] <rvba> In the list above ('list', 'login', etc) list, login, logout, refresh are commands.
[13:14] <rvba> The others are profiles.
[13:15] <rvba> So yes, creating a profile is probably the way to go.
[13:15] <rvba> natefinch: does that make sense?
[13:17] <rbasak> mgz, rvba: I've found the root cause for bug 1248283 I think; explained in the bug. It's caused by juju doing "service networking restart".
[13:19] <rvba> rbasak: nice sleuthing!
[13:19] <natefinch> rvba: sure, how do I create a new profile?  Also, I'm not sure what
[13:20] <rvba> natefinch: maascli login -h will tell you ;)
[13:20] <natefinch> rvba: login == create profile  ok... not obvious naming :)
[13:20] <rvba> Yeah :/
[13:21] <rvba> maascli profile-name url cred:en:tials
[13:21] <natefinch> rvba: I'm just on  whatever machine ssh maas.mallards gives me, should I be somewhere else doing this?
[13:22] <rvba> No, the presence of other profiles indicates you're not the first one doing this :).
[13:22] <natefinch> ok :)
[13:22] <rvba> natefinch: it's definitely confusing, would you mind filing a bug about the login/create profile issue.  It's mostly a doc issue I reckon but we're trying to improve the documentation as a whole and those little problems are really worth fixing.
[13:24]  * rvba lunches
[13:34] <rbasak> roaksoax: can we coordinate a Saucy SRU for bug 1250388, please? Do you have any other fixes that you need to SRU?
[13:34] <rbasak> roaksoax: I'd also appreciate your comment on that bug. Valid?
[13:35] <rbasak> roaksoax: also, it looks like we need to fix Trusty before the SRU.
[13:53] <roaksoax> rbasak: sure! please feel free to prepare the package. I'll upload the latest trunk to trusty later today
[13:54] <rbasak> roaksoax: OK, thanks. I'll prepare the SRU now then.
[13:54] <roaksoax> rbasak: thanks!
[13:54] <rbasak> roaksoax: on second thoughts, perhaps I should wait for other midway enablement SRUs and then bundle them together to save on verification effort.
[13:55] <roaksoax> rbasak: yeah that would be ideal
[13:57] <rbasak> roaksoax: OK I'll hold it for now, then. Please let me know if you have anything else to SRU though, and I'll bundle it in with that. Otherwise I'll try and coordinate all midway SRUs together.
[14:41] <natefinch> rvba: if you're back from lunch, I need some help with setting up this virtual maas.
[14:41] <rvba> natefinch: I'm back.
[14:43] <natefinch> rvba: so first.... when I ssh into maas.mallards.. is that a random node on garage maas, or is that like a root node?  I presume if it's the root node that I should go somewhere else to set up this virtual maas environment.
[14:44] <natefinch> rvba: I know I sorta asked that before, but those profiles mostly seem to be against garage maas itself, not individual virtual maas environments
[14:44]  * natefinch does not want to muck up garage maas.
[14:45] <rvba> natefinch: I /think/ (I don't use garage maas, I use our lab) maas.mallards is like a special node where MAAS itself is installed.
[14:46] <rvba> natefinch: yeah, I don't see why you would create a profile there talking to another MAAS :)
[14:46] <natefinch> rvba: I'd be happy to do this on the lab instead if that makes things easier.  I just need like 4 nodes in a virtual maas
[14:47] <natefinch> rvba: or not virtual, also fine
[14:47] <natefinch> rvba: we're testing backup and restore of the mongo database, testing out some fixes to a bug where it goes horribly wrong
[14:48] <natefinch> rvba: specific customer is using MAAS, so we want to verify the fix on maas
[14:48] <rvba> natefinch: the garage seems like a good place to test this (the lab is still being worked on due to the recent changes in the datacenter).
[14:49] <natefinch> rvba: cool
[16:19] <natefinch> rvba: what's the default login on virtual maas?
[16:19] <rvba> natefinch: you mean right after MAAS gets installed?
[16:19] <natefinch> rvba: yeah
[16:20] <rvba> natefinch: there is no default login, Once MAAS is installed, you'll need to create an administrator
[16:20] <rvba> account::
[16:20] <rvba>   $ sudo maas createadmin --username=root --email=MYEMAIL@EXAMPLE.COM
[16:22] <natefinch> rvba: awesome, thanks
[19:00] <natefinch> rvba: you still around
[19:14] <natefinch> anyone able to give help with maas and juju?  getting 401 unauthorized when I try to bootstrap
[19:18] <natefinch> ahh nevermind.... he maas key actually extends past the end of the text box it's in
[19:27] <natefinch> hmm... except that I can't bootstrap since I get back a 409 conflict now.... all my nodes seem to be stuck in "commissioning" for some reason. I'm sure that's not good.
[20:05] <natefinch>  bigjools: got a second?
[23:14] <bigjools> roaksoax: around?
[23:15] <bigjools> need your assistance in fixing the trusty recipe, dpkg changes broke it