[00:20] hi friends, I have doubts concerning the nodes maas, the documentation does not make clear what procedure to be performed after the MAAS set the IP SERVER, NODE in the installation, after which it shuts the machine automoticatimente and does not proceed to installation of the NODE . [00:21] Grateful for help [00:21] rmiguel: hi [00:21] Hi [00:22] the node goes through different states: [00:22] Starts life as "declared". When you hit "accept" it will transition to "commissioning" and turns on, does some tests, and shuts off, then goes to "Ready" [00:23] When it's in the "Ready" state it will become available as a resource for clients. When you hit "start" in the UI, or it gets used by Juju, its state changes to "allocated" [00:23] at that point an OS is installed [00:23] and it reboots after installation [00:23] does this help? [00:26] yes, the name is in another virtual machine. I'm using vmware virtualizer [00:26] *node [00:28] My station node in state commissioning [00:28] my nodes are in state commissioning [00:29] which and the procedure to be done now. [00:31] rmiguel, are you sure they started to run , how do ypu make them start in the power on config ? [00:33] you have to be sure the wm will net boot on the corntroler node [00:34] * chris38home__ away [00:36] a question which this service dhcp documentation guides to do, is essential for the operation of nodes? [00:38] In my setup it did not set, I'm using my network cards in NAT. [00:45] rmiguel: you must have DHCP set up correctly [00:45] maas will not work without it [00:46] http://maas.ubuntu.com/docs/install.html#configure-dhcp [00:48] OK Bigjools, I'll make the necessary settings in case you need to ask questions back. [00:48] Thank you for your attention. [00:50] rmiguel: no problem === freeflying is now known as freeflying_away [03:10] roaksoax: I did an FFE https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1281881 [03:10] Launchpad bug 1281881 in MAAS "FFE: maas support for third party hardware drivers" [Critical,Triaged] === freeflying_away is now known as freeflying [04:20] jtv: which migration had the vlan tag !null change? [04:21] I think it was 66, but lemme look. [04:22] ('vlan_tag', self.gf('django.db.models.fields.PositiveSmallIntegerField')(unique=True, null=True, blank=True)), [04:22] Yup. [04:22] so it was applied locally [04:22] I think what may have happened is: [04:22] vlan_tag | smallint | not null [04:22] WTF [04:22] 1. You installed a development version with revision 66, which creates that table. [04:23] 2. I wrote a migration that made the column nullable. [04:23] 3. You told me to merge my new migration into migration 66. [04:23] I don't use dev versions on this box [04:23] It could still have produced a daily build, wouldn't it? [04:23] oh, yes [04:23] quite probably [04:23] ok [04:24] And so you already have schema version 66, but it's the old version of version 66. [04:24] ok [04:24] One feature I would still have loved to add for networks is bulk actions. [04:24] "Connect all these nodes to network: " [04:25] "Disconnect all selected nodes from: " [04:25] Since we know how to do that kind of thing now. === freeflying is now known as freeflying_away [04:26] maasdb=# alter table maasserver_network alter column vlan_tag drop not null; [04:26] Yes, that should do it. [04:27] Assuming that's the only other change that got merged into that schema migration. [04:27] yeah [04:27] You see why I like to keep those migration steps separate even if it gets messy. [04:32] I do [04:32] but the damage is limited to daily PPA users [04:32] and it's advertised as dangerous to use [04:32] so I don't care so much [04:33] Just a stupid time sink. Surprising that it still bites you so long after. [04:33] Daily-build installs probably need regular fresh reinstalls. [04:35] jtv: the commissioning script display is excellent work dude [04:35] Thanks! [04:36] I was chuffed to bits with Gavin's review, apologetic though he was about it. [04:36] It really wasn't so nice to look at before that. [04:36] I am sending an email with my review of the latest UI work [05:49] bigjools: finally back [05:50] roaksoax: long trip! [05:50] bigjools: ok so the maas-enlis change makes sense? [05:50] yes [05:50] I have another suggestion for you [05:50] shoot [05:50] I think we should get rid of the packaging branch and put debian/ in upstream [05:51] the silence is deafening :) [05:51] bigjools: nope [05:51] bigjools: :) [05:51] is that a "nope, don't do it?" [05:52] bigjools: normally... when upstream ships its own packaging we 1. remove it and provide our own. 2. improve it and remove it from the source and use our improved one [05:52] ok [05:52] but we are both here :) [05:52] ok let me ask this another way [05:52] I want to make a simple makefile target, in upstream code, to build a package [05:53] the location of the packaging branch becomes an issue [05:54] bigjools: right. So let me think about this becausd we normally w ship both separately regardless of us being upstream (unless policies have changex) [05:55] also there's a damn bug in bzr builddeb which makes this a PITA [05:55] bigjools: but im not fully agaisnt it... im just talking with my packager hat [05:55] whats the bug? [05:55] otherwise, combining the branches and a bzr db --split would have DTRT [05:55] it always looks for upstream tarballs before considering the fact I told it to look for a local branch [05:56] I found the code with the bug, considering submitting a patch [05:56] bigjools: how do you build? [05:56] I was trying to use: [05:56] i mean whT command? [05:56] bzr bd --export-upstream=../mybranch --export-upstream-revision=NNNN --merge [05:57] or if debian/ is local you can just use --split [05:57] rright [05:57] and it's supposed to create a tarball from the local branch [05:57] right [05:58] but bzrlib/plugins/builddeb/cmds.py at line 417 should be insert, not append [05:58] so i dont have strong objections to it ... but normLly packaging should go outside the code itself [05:58] yeah - I don't care honestly, I just want this to work :) [05:59] bigjools: so let me dig into this and i'll get back to you on that. Lets just make this happen post 10.04 if possible [05:59] I can *assume* that packaging is always at ../packaging/debian/ [05:59] for now, anyway [05:59] ok cool [06:00] bigjools: but anyway. ameetp was looking pn major dofferences between 12.04 maas and 14.04 maas... can you put something together? [06:00] roaksoax: it's all in the changelogs [06:00] bigjools: he wants major features tho [06:00] oh pre-13.10 is not [06:01] roaksoax: he can look at LP milestones [06:01] it's all there [06:01] ok [06:01] roaksoax: btw can you can iscpy packaged before the deadline? And in main? [06:02] it's needed for this command you wanted to run from packaging to insert the forwarders [06:03] bigjools: i thought the forwarders were already being inserted...? [06:04] bigjools: i can try to take care of it tomorrow bit wven if i do is up to a archive admin to review the package and accwpt it in the archives and it might not make it in time [06:04] roaksoax: shit [06:04] can we file ffe? [06:04] the forwarders file is created but we need to modify named.conf.options to have an include statement [06:05] bigjools: btw... i'm gonna upload maas tomorrow my morning before feature freeze. will i be able to upload lateat trunk? or what rev? [06:05] the config for named is a fucking PITA [06:05] best to check with the guys at the time [06:05] we have quite a lot of stuff left to land [06:06] bigjools: ok i'll try to make it happen by tomorrow (not the MIR though, that would require FFe) [06:07] roaksoax: ok cheers. We definitely need FFE for it then. [06:07] yup [06:07] sorry for leaving this so late, there was so much other stuff to do :( [06:08] yeah i can imagine [06:08] alright then. i'll test the maas-enlist thing tomorrow and land it if everything works as expwctex [06:09] and release maas [06:09] sweeet [06:09] alrighty then. Off to bed. Have a gpod rest of the day! [06:11] roaksoax: cheers, sleep well [06:14] jtv: there? [06:23] bigjools: here [06:23] jtv: we missed our call, want one? [06:23] politics intervened for a while [06:23] Oh! Call! Forgot all about that, what with all the !@#$^ going on. Yes I do. [06:23] ok [06:23] give me 2 mins to get a drink [06:23] will call you [06:24] OK === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away === CyberJacob|Away is now known as CyberJacob [08:12] gmb: are you available for a tiny review? https://code.launchpad.net/~rvb/maas-test/always-update/+merge/207105 [08:12] rvba: Sure [08:12] Thanks. [08:13] rvba: LGTM. [08:35] bigjools: you might like https://code.launchpad.net/~jtv/maas/dbshell/+merge/207108 [08:42] bigjools: could you please review https://code.launchpad.net/~rvb/maas-test/fix-maas-admin/+merge/207111 ? [08:42] yep [08:43] Ta [08:43] rvba: ummm lol [08:43] oh dear [08:43] :) [08:44] bigjools: the original paste I gave you was broken so it's only fair that this comes back to me :) [08:44] well I missed that too [08:51] jtv: + subprocess.check_call( [08:51] + ['sudo', '-u', 'postgres', 'psql', database]) [08:51] did that actually work? [08:52] oh you're doing it differently to how I did it earlier, never mind [08:53] rvba: is it wrong of me to find it hilarious that you continually get caught out by the "additional revisions" tarmac message? :) [08:53] bigjools: it is, indeed, wrong of you :). [08:54] rvba: so why is maas-test qa complaining about bin/pip? [08:54] Well, I'd be happy to know. Like I said, I can't reproduce it locally or on canonistack. [08:55] let's just fix the damn makefile [08:55] bin/python -m pip [08:55] I tried but one of the lines starting .deps/bin/pip confused me [08:57] bigjools: do we have enough information to implement the card "Node MACs must be linked to their networks" to your satisfaction? [08:58] jtv: I think the card says it all [08:58] AFAICS we only have that information for NICs that are on the MAAS-managed network. [08:58] So... only one MAC per node linked, and only if DHCP management is enabled? [08:58] yeah we need to link MACAddress with network [08:58] We can't. [08:58] we need to :) [08:59] We can link MACAddress with NodeGroupInterface. [08:59] no [08:59] that's not the same thing [08:59] That's why I said it. [08:59] this is manual input [08:59] So... additional schema, additional UI. [08:59] not auto [08:59] yes :( [08:59] And API changes. [08:59] yes [09:00] otherwise users won't know which NIC can access which network [09:00] we need to think carefully about the UI [09:00] might need some JS === freeflying_away is now known as freeflying [10:41] Hi rbasak, I just got a pretty confusing error from uvt-kvm. Looks related to the data it got from simplestreams but you might know better: http://paste.ubuntu.com/6959216/ [11:01] jtv: time for a review? https://code.launchpad.net/~rvb/maas/network-mac-rel/+merge/207135 [11:02] rvba: that's a WIP [11:02] jtv: not anymore [11:02] Saved by the bell! [11:02] Sorry, I made promises, remember? :-) [11:03] gree [11:03] grrrr* even [11:03] Sorry! [11:03] If it doesn't get reviewed, I can just branch off it — no biggie. [11:03] nn! [11:03] nn === freeflying is now known as freeflying_away === mwhudson is now known as zz_mwhudson === zz_mwhudson is now known as mwhudson === mwhudson is now known as zz_mwhudson === zz_mwhudson is now known as mwhudson === freeflying_away is now known as freeflying