[07:26] <jtv1> bigjools: let me just look up the change that's needed...
[07:26] <rvba> jtv1: bigjools: Did you guys manage to run the script end-to-end?
[07:26] <bigjools> jtv1: thank you sir
[07:26] <jtv1> rvba: I'm running it now.
[07:27] <bigjools> rvba: I think jtv did, I have been out all day so only just getting up to speed
[07:27] <jtv1> It's actually imported an image already.
[07:27] <jtv1> It takes a while, obviously.
[07:27] <rvba> jtv: are you using the int-fix-boot-imgs patch?
[07:28] <jtv> No, not yet.
[07:28] <jtv> Wanted to see the "before" state first.
[07:28] <rvba> Okay.
[07:28] <jtv> bigjools: edit mirror_info_for_path
[07:28] <jtv>     policy = policy_read_signed
[07:28] <jtv> becomes:
[07:28] <jtv>     policy = lambda content, *args, **kwargs: content
[07:28] <bigjools> thanks
[07:28] <jtv> That'll teach it.
[07:29] <bigjools> now I get ValueError: No JSON object could be decoded
[07:29] <jtv> Hwrg
[07:30] <jtv> Source URL is http://maas.ubuntu.com/images/ephemeral-v2/daily/streams/v1/index.json ?
[07:30] <jtv> I should get used to calling it "source path" really.
[07:30] <bigjools>     - path: "http://maas.ubuntu.com/images/ephemeral-v2/daily/streams/v1/index.json"
[07:31] <jtv> release "trusty", arch "i386", subarches "generic"?
[07:31] <bigjools> well it has * * * at the moment
[07:31] <jtv> All as strings?
[07:32] <jtv> Because we originally had subarches: ['*'] in the example, but it should be a string.
[07:32] <jtv> Double-quoted, I think.
[07:32] <jtv> (Not that it's likely to matter)
[07:32] <rvba> subarches is a list.
[07:32] <bigjools> all strings
[07:32] <bigjools> doesn't make any different
[07:33] <bigjools> I am running straight from the integration branch here, you must have other changes
[07:34] <jtv> Nope.  But I did have that error earlier...  I wonder if it's just its way of saying "I didn't find anything matching your requirements."
[07:34] <jtv> Try setting arch/subarches/release.
[07:35] <jtv> rvba: did subarches become a list?  In the integration branch as I have it (pulled earlier today) it was still a comma-separated string.
[07:35] <bigjools> ok how are you running the script?
[07:35] <bigjools> I use bin/py scripts/maas-import-pxe-files
[07:36] <rvba> jtv: AFAIK, it's been a list since the beginning of the week… let me check…
[07:36] <bigjools> it's currently not a list
[07:36] <jtv> bigjools: ah-HAH.  That'll import the globally installed maas modules, won't it?
[07:36] <jtv> Try running sudo PYTHONPATH=./src scripts/maas-import-pxe-files
[07:37] <jtv> rvba: no, the pserv.yaml in the branch used to say "[*]" but that didn't actually work.
[07:37] <rvba> Him, something is wrong then.
[07:37] <rvba>  subarches = Set(if_missing=['*'])
[07:37] <rvba> That's how it's defined.
[07:37] <rvba> s/Him/Hum/
[07:38] <jtv> When you pasted examples for Julian yesterday, you had subarches as a single comma-separated string.
[07:38] <bigjools> jtv: I don't have globally installed modules :)
[07:42] <bigjools> rvba, jtv: ok so I am not sure what else I need to do here to get the script working
[07:42]  * bigjools dist-upgrades
[07:42] <jtv> Careful!
[07:43] <jtv> Remember the old and new pserv.yaml are mutually incompatible.
[07:43] <jtv> If you have an old pserv.yaml with a new codebase, or vice versa, the upgrade hangs.
[07:43] <bigjools> jtv: I am not using any packages
[07:43] <jtv> OK
[07:43] <bigjools> this is completely from branch
[07:43] <bigjools> on a fresh canonistack instance
[07:45] <jtv> Not promising it'll help me understand, but do you have a traceback?
[07:45] <bigjools> jtv: http://paste.ubuntu.com/7129350/
[07:45] <jtv> thx
[07:45] <bigjools> looks like it barfs on the index
[07:45] <jtv> Most likely, yes.
[07:45] <rvba> bigjools: I'm running the script now…
[07:46] <jtv> For me it completed the download, then broke because it didn't have the int-fix-boot-imgs branch yet.
[07:46] <jtv> Which I'm trying now.
[07:46] <jtv> bigjools: that looks like a failure I had earlier.
[07:46] <jtv> And I'm pretty sure I fixed it by changing pserv.yaml.
[07:46] <bigjools> I am going to have to break for a bit shortly, I am home alone with twins
[07:46] <bigjools> there's only so much kids tv that will sate them
[07:48] <rvba> Script running okay thus far (here is my pserv.yaml http://paste.ubuntu.com/7129354/)
[07:48] <rvba> Okay, it failed in the end because I don't have the changes from int-fix-boot-imgs.
[07:48] <rvba> jtv: same as what you got.
[07:48] <jtv> bigjools: the "boot" part of my pserv.yaml is http://pastebin.ubuntu.com/7129356/
[07:49] <jtv> Now going to try with the new branch, which includes some label stuff so it'll find a new reason to break.
[07:51] <rvba> Running the int-fix-boot-imgs branch (plus Scott's fixes which are only in trunk)…
[07:52] <rvba> uec2roottar running…
[07:52] <rvba> Script finished running without errors.
[07:52]  * rvba checks the output…
[07:52] <bigjools> so I have a pristine int branch with rvba's pserv.yaml and I get the json decode error
[07:53] <jtv> And then... commissioning, deploying with fpi, and deploying without fpi!
[07:53] <jtv> bigjools: what about the policy patch?
[07:53] <bigjools> I have that
[07:53] <bigjools> that's it
[07:53] <bigjools> you guys must have other changes
[07:53] <jtv> Did you try the pserv.yaml segment I pasted?
[07:53] <bigjools> I used rvba's
[07:54] <bigjools> who said his was working
[07:54] <rvba> Output looks sensible but I don't see the label in the images' path http://paste.ubuntu.com/7129368/
[07:54] <bigjools> it was the same as mine
[07:54] <jtv> I have similar results, basically what I expected.
[07:54] <jtv> Now to work the label in there, and make sure it's not "daily".
[07:55] <rvba> Well, it should be whatever is in simplestreams' data.
[07:55] <bigjools> eventually yes but it's broken ATM
[07:56] <jtv> Actually, in the simplestreams data I'm seeing paths like precise/amd64/di/20101020ubuntu136.15/raring/generic/di-initrd
[07:57] <jtv> ...which are nothing at all like what we have.
[08:05] <jtv> bigjools: I remember the weird thing when I got that error was that the JSON was not empty.
[08:05] <rvba> jtv: the new list_boot_images() in int-fix-boot-imgs seems to work.  Of course, right now it returns the empty list because the label is not yet part of the path.  But I did  manual test (adding the label as part of the images' path manually) and list_boot_images returned something sensible.
[08:06] <jtv> That's good.  I'm having some more trouble getting mine to work.  :(
[08:07] <jtv> Looks like I'm missing an update somewhere...  simplestreams looks for <url>/index.json/streams/v1/index.sjson
[08:07] <jtv>  — so it's not doing the "URL to the index plesae" yet.
[08:08] <jtv> Merging update from latest integration branch.
[08:10] <jtv> Success!
[08:15] <rvba> With that diff (it includes a couple of changes from the int-fix-boot-imgs branch) I get the layout we want: http://paste.ubuntu.com/7129439/
[08:16] <jtv> "this"
[08:17] <jtv> Do you get "release" and "alpha-2" as the labels?  Or always "daily"?
[08:18]  * rvba checks
[08:19] <rvba> I downloaded only trusty/amd64/generic and for that image the label is daily.
[08:19] <jtv> Yay!
[08:19]  * rvba includes saucy, re-runs the script.
[08:19] <jtv> We'll need to hard-code that to "release"
[08:20] <jtv> But that's fine — the important thing is that the label is in the dir structure.
[08:20] <rvba> I don't understand… shouldn't we just expect Scott to fix that?
[08:21]  * jtv invites rvba to ponder that option for a bit
[08:21] <rvba> saucy→daily
[08:22] <jtv> Yeah.
[08:22] <jtv> If it gets fixed before release, then yes, we can just pretend "daily" is a workable label.  But otherwise...
[08:26] <jtv> For some reason memory usage seems to have jumped.  My little server is getting really slow.
[08:31] <jtv> Review needed: supporting both the old and the new config items, to avoid upgrade breakage.  https://code.launchpad.net/~jtv/maas/support-new-pserv-config-items/+merge/212110
[08:36] <rvba> jtv: why do you want to make that part of trunk MAAS now?  Shouldn't we land this with the rest of the int. branch… if and when we do so?
[08:37] <jtv> It can complicate testing.  I want to land it in both.
[08:41] <rvba> New diff with the tgt_entry() method fixed http://paste.ubuntu.com/7129525/
[08:42] <rvba> err: http://paste.ubuntu.com/7129527/
[08:48] <jtv> rvba: does that include my int-fix-boot-imgs branch by the way?
[08:49] <jtv> My version adds "label" in one more place.
[08:49] <rvba> Weird, this should include the changes you made in your int-fix-boot-imgs branch.
[08:49] <rvba> You say you see something missing?
[08:52] <rvba> jtv: btw, subarches should really be a list.  It works with '*' only because a string happens to be an iterable.
[08:52] <jtv> Christ.
[08:52] <jtv> But then why does "generic" work?
[08:54] <rvba> It should work (as in, not crash) but not download anything.
[08:54]  * rvba tries
[08:56] <rvba> Hum, looks like the config does something funky: if I set 'subarches: "generic"' in pserv.yaml, I get 'filter['subarches']=['generic']'
[08:56] <rvba> If I use a list in the config, I get the same list in filter['subarches'].
[08:57] <rvba> I guess that's a feature.
[08:59] <jtv> Heaven protect us from features.
[09:26] <bigjools> help, jtv, rvba.  What are you two doing differently with your branches to mine such that I get that json error?
[09:29] <rvba> bigjools: I don't know really… can I get access to your canonistack instance?
[09:30] <bigjools> rvba: one sec
[10:00] <rvba> jtv: when you're done with testing the diff I sent you, would you mind also getting the most recent changes from the int. branch into your int-fix-boot-imgs branch?  This way, we will be able to build a package from it and test the package.
[10:03] <rvba> jtv: oh, looks like you did that already :)
[10:03] <jtv> :-P
[10:10] <allenap> Merging trunk has resolved the ### INVALID STRING ### stuff, but the region-worker Celery keeps spawning.
[10:11] <rvba> jtv: Are you integrating my diff or should I create another branch on top of yours?
[10:12] <jtv> rvba: I'd make it a separate branch.
[10:13] <rvba> jtv: all right, I'll do it.
[10:13] <jtv> Now, why does that diff not apply?
[10:13] <jtv> (I was briefly distracted by travel stuff)
[10:16] <rvba> jtv: this one will probably do: http://paste.ubuntu.com/7129865/
[10:18] <rvba> jtv: https://code.launchpad.net/~rvb/maas/use-labels-in-import-script/+merge/212125
[10:18] <jtv> looking...
[10:18] <jtv> "patch" is taking forever on my test machine.
[10:18] <jtv> The performance really dropped quite dramatically.
[10:20] <allenap> Arg, it’s python-librabbitmq. It causes a seqfault when starting region-worker.
[10:20] <allenap> segfault even.
[10:20] <jtv> Ouch.
[10:21] <bigjools> allenap: didn;t we replace that package with another one?>
[10:21] <bigjools> we did
[10:21] <bigjools> it's not installed here
[10:22] <bigjools> allenap: uninstall it and see what happens
[10:25] <allenap> Everything works :)
[10:26] <allenap> I have a branch to forbid that package: https://code.launchpad.net/~allenap/maas/forbidden-deps/+merge/212128
[10:26] <bigjools> reviewing
[10:28]  * bigjools AFK for 10m
[10:55] <rvba> jtv: +1 on https://code.launchpad.net/~jtv/maas/int-fix-boot-imgs/+merge/212082
[10:55] <jtv> Thanks.
[10:55] <jtv> I'm already trying from a package, by the way.
[10:55] <rvba> jtv: https://code.launchpad.net/~rvb/maas/use-labels-in-import-script/+merge/21 is officially up for review
[10:56] <rvba> jtv: Same here :)
[10:56] <jtv> Not having much luck pxe-booting though.
[10:56] <rvba> I'm just getting the lab ready.
[10:59] <jtv> By the way, when landing into the integration branch, don't forget to mark the branches (as opposed to the MPs) as merged.
[10:59] <jtv> I'll review your branch.
[10:59] <rvba> Ta.
[11:01] <jtv> I have high hopes for the simplestreams cache...
[11:02] <jtv> I'm re-running the import script after wiping all of my boot-resources directory — *except* the cache.
[11:02] <jtv> Yup.  Nice & fast!
[11:05] <bigjools> jtv: where and what is caching?
[11:05] <jtv> bigjools: images get dowloaded into /var/lib/boot-resources/cache
[11:05] <jtv> ...and the rest is extracted from there.
[11:07] <jtv> rvba: are you getting the following error?
[11:07] <jtv> [2014-03-21 18:06:20,750: ERROR/MainProcess] Task provisioningserver.tasks.report_boot_images[27842890-96bb-4543-8263-1a8ef4dfdff4] raised unexpected: TypeError('<itertools.chain object at 0x7f65809c5b10> is not JSON serializable',)
[11:07] <jtv> I thought I'd fixed one of those, but...
[11:07] <jtv> Anyway, I'll write up a fix.
[11:08] <strikov> Guys, i just built maas packages with 'make package' and cluster-controller depends on 'shim-signed' package which is provided only for amd64.
[11:08] <bigjools> fuck
[11:09] <rvba> uh-oh
[11:09] <rvba> jtv: ta, branch is landed.
[11:09] <jtv> I hope that merely means that a build failed..?
[11:09] <rvba> strikov: make sure you pull the latest version of the integration branch, we just landed 2 branches.
[11:19] <jtv> allenap: thank you once more for fixing the pserv tests.  Unless you were the one who broke them, in which case, I hate you.  :)
[11:19] <allenap> jtv: Hehe, no I didn’t break them :)
[11:19] <rvba> jtv: didn't see that error… but I didn't get that far yet.  I know where the problem is… but so do you :)
[11:19] <jtv> Yup.  This is what happens when you play with itertools!
[11:19] <rvba> heh
[11:20] <bigjools> allenap: your opinion required.  Blake's branch seems amd64 only.
[11:21] <bigjools> it uses shim-signed which is only on amd64
[11:21] <allenap> bigjools: The UEFI one? It only works for amd64, indeed.
[11:21] <bigjools> allenap: yeah, does it check for amd64 before using it?
[11:21] <bigjools> it's in m-i-p-f
[11:21] <allenap> bigjools: Ah, I hope so.
[11:21]  * allenap checks
[11:22] <bigjools> allenap: it doesn't
[11:22] <allenap> Dammit.
[11:22] <bigjools> yup
[11:22] <bigjools> allenap: I don;t know how to do an arch-specific dependency in packaging but I am going to learn quickly :)
[11:23] <allenap> bigjools: I’m losing you now. Why does this impact packaging?
[11:23] <bigjools> allenap: we (where we is probably you at this point) should change mipf to check even though we're going to get rid of that script.
[11:24] <bigjools> allenap: I added a dependency on shim-signed but that makes the package unbuildable on i386
[11:24] <bigjools> and it's an arch-indep package which only builds on i386
[11:24] <allenap> s/i386/amd64/ ?
[11:24] <bigjools> so the packaging should only depend on it if installing on amd64
[11:25] <bigjools> no i386 intentional
[11:25] <rvba> jtv: I'm landing a change to pserv.yaml to make subarches a list.
[11:25] <rvba> (that's a feature we shouldn't hide)
[11:25] <jtv> Very well.
[11:25] <allenap> Huh? This makes no sense to me.
[11:25] <bigjools> allenap: the arch indep builders are all i386
[11:25] <bigjools> but the package now needs amd64
[11:25] <bigjools> even though it's technically arch indep
[11:25] <allenap> Why does the package need amd64?
[11:26] <bigjools> because shim-signed is a binary package that only exists on amd64
[11:26] <allenap> Can we change that?
[11:26] <bigjools> I added it as a cluster controller dependency
[11:26] <allenap> It’s just a blob.
[11:26] <allenap> Afaik.
[11:26] <bigjools> yeah I need to make it arch dependent
[11:26] <bigjools> it is
[11:27] <jtv> rvba: pushed a fix to the json bug.
[11:28] <allenap> bigjools: Do you mean arch *in*depedent? Or arch dependent for building, so that binaries can be prepared for each arch?
[11:28] <rvba> jtv: ta. I see you've removed the call to chain()…  without removing the import.
[11:28] <jtv> Ah.  So I forgot to check for lint.  :-)
[11:28] <rvba> jtv: I'll do it in the branch I'm working on now.
[11:29] <jtv> Ta.
[11:29] <jtv> Now, where is this boot images UI?
[11:29] <jtv> I want my list of boot images!
[11:30] <bigjools> allenap: I mean to make it so that it only depends on shim-signed if you are installing on amd64
[11:31] <bigjools> otherwise the dependency cannot be fulfilled
[11:31] <strikov> allenap, bigjools: I see this issue while trying to install package on armhf: https://pastebin.canonical.com/106925/
[11:31] <bigjools> strikov: can you use public paste
[11:31] <bigjools> allenap: that paste is the result of this problem
[11:31] <bigjools> thank you strikov
[11:32] <strikov> bigjools, allenap: sorry, here it is: http://pastebin.ubuntu.com/7130103/
[11:32] <allenap> bigjools: That’s fixing the wrong thing, though I grant it’s probably the path of least resistance right now. There’s no reason why MAAS installed on i386 can’t netboot an amd64 system using UEFI.
[11:33] <bigjools> allenap: very true
[11:33] <rvba> allenap: the path of least resistance would be to include that blob in MAAS' tree and remove the dependency, wouldn't it?
[11:35] <allenap> rvba: Ah, yes, though we may find that our sticky-out bits are at risk from the scythes of the security team.
[11:35] <rvba> Hum, good point.
[11:36] <allenap> blake_r’s original approach was to download from the archive. Perhaps we need to reconsider that?
[11:37] <bigjools> he was downloading the source package
[11:37] <bigjools> which is problematic, not everyone has sources enabled
[11:38] <jtv> Or if downloading directly, we'd lose built-in signature verification.
[11:49] <bigjools> allenap: I think we need to revert blake's branch then
[11:50] <allenap> bigjools: Or fix it.
[11:50] <bigjools> and fold its changes, with the shim-signed stuff, into the new script
[11:50] <bigjools> well the new script is nearly done
[11:50] <bigjools> let's not do the work twice
[11:50] <allenap> bigjools: There was a lot more work in Blake’s branch than just m-i-p-f. Do we want to revert all of it?
[11:50] <bigjools> no not at all
[11:51] <bigjools> just the bits that are going to break without shim-signed :)
[11:52] <allenap> bigjools: The rationale for reverting versus ploughing through is because it’s blocking QA?
[11:52] <bigjools> allenap: it'll block everything, I think mipf will crash
[11:53] <bigjools> we could comment out that one line in it
[11:53] <allenap> bigjools: Yeah, let’s hack round it to unblock things.
[11:54] <bigjools> can't tell if you're serious or being sarcy...
[11:56] <allenap> bigjools: Serious :) Agreeing with you.
[11:56] <bigjools> allenap: oh good :)
[11:57] <bigjools> allenap: are you ok to do that while I unfcuk the packaging?
[11:57] <allenap> bigjools: I need to work around all references to the shim, right?
[11:57] <bigjools> allenap: I think it's just one call you can comment out to the new func
[11:57] <bigjools> see the diff to mipf
[11:58] <allenap> bigjools: So, don’t call update_uefi_boot_loader at all?
[11:58] <bigjools> allenap: just don't call it at all for now to unblock and then fix later
[11:59] <bigjools> so yes :)
[11:59] <bigjools> allenap: also remove shim-signed from required-packages
[11:59] <allenap> Okeydoke.
[12:00] <allenap> bigjools: Is there a bug about this?
[12:00] <bigjools> allenap: no
[12:02]  * allenap files one
[12:04] <bigjools> ok packaging fix just went in
[12:04] <allenap> I have lots of tests to disable.
[12:06] <bigjools> oh well :/
[12:08] <allenap> bigjools: https://bugs.launchpad.net/maas/+bug/1295644
[12:11] <bigjools> thanks allenap
[12:13]  * bigjools sleeps
[12:22] <allenap> bigjools: Fwiw, by reusing your packaging branch every time, each revision gets tagged with the same bugs. See https://code.launchpad.net/~maas-maintainers/maas/packaging.
[12:22] <allenap> It also means I can’t link that branch to the bug.
[12:26] <allenap> rvba: Do you have time for a quick (critical) review fix? https://code.launchpad.net/~allenap/maas/disable-uefi-temporarily/+merge/212150
[12:44] <rvba> allenap: looking now
[12:55] <strikov> Could someone review my patch to allow us to use different keyrings for different sources: http://bazaar.launchpad.net/~strikov/maas/new-import-script-integration.keyring-per-each-source/revision/2155 Thanks
[12:56] <rvba> strikov: I'll have a look
[13:02] <rvba> strikov: looks good, but you need to fix the test_config.py tests (yes, we have unit-tests for this): ./bin/test.maas ./src/provisioningserver/tests/test_config.py
[13:28] <strikov> rvba: thanks for the review, does it look better: http://bazaar.launchpad.net/~strikov/maas/new-import-script-integration.keyring-per-each-source.2/revision/2155
[13:29] <strikov> rvba: Ran 25 tests in 0.719s
[13:29] <strikov> OK
[13:29] <rvba> strikov: cool.  Looks good.  If testing is okay, land it.
[13:30] <rvba> strikov: maybe also update pserv.yaml (I know the value is the default, but it's a good example)
[13:30] <strikov> rvba: will do
[13:35] <strikov> rvba: Pushed with pserv.yaml change. Thanks.
[15:08] <rvba> allenap: time for a tiny review? https://code.launchpad.net/~rvb/maas/build-depe/+merge/212173
[15:09] <allenap> rvba: Sure!
[15:10] <allenap> rvba: Oh man, the deps are not sorted.
[15:10] <rvba> allenap: ahhhhh!
[15:11] <rvba> allenap: fixed
[15:12] <allenap> rvba: If you have a few minutes, can you look at my rpc-ident-redux branch, https://code.launchpad.net/~allenap/maas/rpc-ident-redux/+merge/212070? You only actually need to review the interdiff, http://paste.ubuntu.com/7129526/, which is a lot shorter.
[15:12] <rvba> allenap: k
[16:00] <allenap> rvba: Have you noticed shells taking a long time to exit when closing? I hit Ctrl-d in a screen “tab” and it can take 20-30 seconds for bash to exit. At least, I assume it’s bash taking its time.
[16:00] <allenap> It’s been doing it for a couple of weeks, maybe more.
[16:02] <rvba> allenap: no, it clearly doesn't do that for me.
[16:02] <tych0> hi allenap, any idea what this is? http://paste.ubuntu.com/7131290/
[16:03] <tych0> i'm getting lots of them
[16:03] <tych0> and a clue is that my dhcp server seems to not be working
[16:10] <allenap> tych0: Mmm, was there a request path anywhere near that?
[16:11] <tych0> not in maas.log, might be in apache's logs, though, let me look
[16:12] <tych0> yeah, access.log is totally empty
[16:12] <tych0> error.log doesn't have any timestamps close to that one
[16:14] <allenap> tych0: Is the DHCP server down, not giving out addresses? Or is it that leases are not getting into MAAS? (Not sure what outward indication there would be of that…)
[16:15] <tych0> allenap: it appears to not even be giving out addresses, although i restarted maas-dhcp-server
[16:16] <tych0> allenap: is there a log for it somewhere?
[16:18] <allenap> tych0: The leases file in /var/lib/dhcp might have something useful. Otherwise look in /var/log/syslog.
[16:21] <tych0> yeah, /var/lib/dhcp/dhcpd.leases is empty
[16:24] <allenap> tych0: Are you happy to dig around, try to find out why it’s not running, or not populating the leases file at least?
[16:31] <tych0> allenap: yeah, that's what i'm doing now
[16:31] <tych0> this might be an lxc, thing, actually
[16:40] <tych0> ah, nope
[16:40] <tych0> lxc is asking for one
[16:40] <tych0> it just isn't getting anything back
[16:58] <tych0> ah
[16:58] <tych0> i had dnsmasq running
[17:17] <allenap> tych0: Phew, it’s not another MAAS bug :)
[17:56] <Fishy_> hi!
[18:00] <Fishy_> i am trying to follow the newbie install tutorial and getting stuck.. any pointers?  http://paste.ubuntu.com/7131844/
[18:01] <Fishy_> i guess sudo maas-import-pxe-files   works
[18:01] <Fishy_> but document says thats only for sub 1.3
[19:20] <tcollins> Ive just setup my first MAAS server and now I have an issue with PXE booting.  I can successfuly get an IP, but nodes cannot find a pxelinux.cfg
[19:20] <tcollins> does maas create this or do I have to do it manually?
[20:07] <tcollins> seem tobe an access problem.  in maas.log getting "SuspiciousOperation: Invalid HTTP_HOST header (you may need to set ALLOWED_HOSTS):"
[20:36] <Fishy_> I am trying to do the same thing ;)
[20:37] <Fishy_> running maas server on a bridge, trying to expose the dhcp and dns from my maas server without trashing my entire network
[20:37] <Fishy_> and feed into a pxe boot
[21:01] <Fishy> humm what is "Router Ip"
[21:01] <Fishy> the upstream gateway of mine?
[21:05] <tcollins> I set mine the same as the maas server
[21:06] <tcollins> im trying to bridge as well
[21:10] <tcollins> ok I got it to PXE boot, had to reinstall and start from scratch
[21:11] <tcollins> followed these: http://frugnul.blogspot.com/2013/04/maas-not-tutorial.html
[21:27] <Fishy> hum
[21:28] <Fishy> by default, the little lxcbr0 bridge that juju added to my local machine, is not exposed to the world
[21:28] <Fishy> i think I need to add my eth0 to be behind it
[21:29] <Fishy> so that it can be exposed
[21:29] <Fishy> but beyond what I have done before
[21:30] <tcollins> do you have physical machines, who are they just on the same machine?
[21:40] <Fishy> right now I have 2 phical machines
[21:40] <Fishy> 1) desktop I am on now.  want it to keep connected to current network (192.168.78) as a client..  but also want it to host a new maas network (as 192.168.4.1)
[21:40] <Fishy> 2) a laptop I want to boot off PXE, and grab the 192.168.4.1 broadcast
[21:40] <Fishy> and get added to maas
[21:41] <Fishy> have a maas server up
[21:41] <Fishy> his IP is set to 192.168.4.1
[21:41] <Fishy> laptop cant even ping that though
[21:41] <Fishy> so that network is local to my box
[21:42] <Fishy> so its like a need a bridge in front of my bridge
[21:42] <Fishy> to tie my real eth0 to both networks
[21:42] <Fishy> argh, networking hard