[00:23] Hello === Lord_Set2 is now known as Lord_Set [00:30] hi [01:03] How are things going bihjools? === CyberJacob is now known as CyberJacob|Away [01:20] busy busy busy [01:22] Any update on the MAAS issue with enlistment? Or do you have an eta? [01:22] I'm in the middle of a fix [01:22] just testing something out [01:22] Awesome you rock [01:22] If you want me to do some testing as well let me know [01:30] yup [01:55] Lord_Set: try this package https://launchpad.net/~maas-maintainers/+archive/experimental/+build/5800532 [01:55] it's got a change that's not landed in trunk yet so is highly experimental but seems to work for me locally [02:09] if i was to try to set up a MAAS that had a bunch of real arm server nodes and virtual machines enlisted, could i make that work? [02:09] or would i just go insane and fall into the sea? [02:10] mwhudson: no reason why it won't work [02:10] cool [02:10] there's a section in the docs for setting up VMs [02:10] it was more the highly heterogeneous nature that worried me [02:11] maas doesn't care what it is [02:11] it's an equal opportunities provisioner [02:11] :) [02:11] Bigjools: How much testing have you done with ARM machines such as Raspberry Pi? Or some of it's more powerful cousins out there? [02:12] i've run it on highbank before now [02:12] well there just happens to be the right man here :) [02:12] Lord_Set: you need remote, well, management of some kind [02:13] i guess you could have rpi and a pdu [02:13] The team here came up with a great concept we want to build using arm machines for super high density... like 30+ machines per 2U of space. [02:13] Lord_Set: where is "here"? [02:13] I am the lead network and systems engineer of a few "connected" startups. [02:14] Same owner and CEO/CIO started a bunch of companies that each complement each other infrastructure wise. [02:15] We are using Ubuntu Server, MAAS, and Juju as the core of our infrastructure for deployment over geographically disjoint locations. [02:16] We are pushing a handful of our services and platform live this week. [02:18] cool :) [02:19] have you seen hp's moonshot? [05:37] bigjools: I didn't notice earlier because my connection to the board was broken, but you're doing "Hook power_types registry to rpc call" while I'm doing "Registry for power types." [05:37] jtv: argh [05:38] I expect quite a bit of overlap. [05:38] I am doing that too [05:38] currently fighting tests [05:38] registry bit is easy [05:38] but I am having trouble stopping the test data leaking out of the test in the singletons [05:38] The way I did it, JSON_POWER_TYPE_PARAMETERS contained only the fields. [05:39] One thing we can always do is start out by patching each registry to contain a copy of its original contents. [05:40] that's what I am doing [05:40] hang on let me show you a diff [05:40] jtv: https://code.launchpad.net/~julian-edwards/maas/power-registry/+merge/210343 [05:42] jtv: the Mocks added in the tests leak out so I am not restoring state properly [05:42] I can see why [05:42] just need to fix it and then it's done. how far did you get? [05:44] Wrote and initialised the registry, pared down JSON_POWER_TYPE_PARAMETERS to list just the fields, made the RPC function compose its answer based on the registry, added a module of functions-to-patch-out-RPC-calls, and was fixing up tests because the global data structure that the MAASServerTestCase patch depended on no longer existed. [05:45] mine is done [05:45] ummm [05:45] I didn't remove or change JSON_POWER_TYPE_PARAMETERS [05:45] it can stay as it is, surely? [05:46] Can, but probably shouldn't. [05:46] why? [05:47] I didn't find any good place to put the whole thing — it was too much for the driver's __init__.py, even though it's really just another "built-in" list; and power_schema.py should be about the JSON schema, not the core definition of built-in power types. [05:48] So I figured power_schema.py should know the fields, but the names/descriptions belonged in a "builtin_power_types" list in driver. [05:48] let's move it in a separate branch - since mine is done and working shall we use it and then yours can be a bout moving the struct around? [05:48] Sure. I'm already doing part of it in a separate branch. [05:48] By the way, can't you just use self.patch to override the registry during testing? [05:48] ok feel free to review that MP [05:48] no, because it's a global [05:49] you have to modify its content [05:49] not its reference [05:49] Yes, but patching it would let you do either, right? [05:49] "Replace with a copy, and restore after the test." [05:50] it didn't work with patch [05:50] that's all I know [05:50] and I thnk it's because the registry classes keep a reference to the old object [05:51] and patch just replaces the reference with a new one but doesn't help with things that already took a reference [05:51] Right, I was thinking more along the lines of patching the classes. [05:51] you can't do that [05:51] they don't have anything to patch [05:51] Yes you can. Python. :) [05:51] you have to patch the global [05:52] Yes, but what if you replaced the double "global _registry" with a single class variable? [05:53] just so we can use patch? [05:53] not really worth it IMO [05:53] OK [05:53] I mean, feel free to disagree :) [05:53] Don't want to slow this down with bikeshedding. [05:54] good man [05:54] Lies. [05:54] One thing that bothered me a bit about the Registry class is that entries are not keyed on names. [05:57] It's probably nothing, but I do wonder if anything could go wrong with poorly written drivers, e.g. ones that might re-register new versions of what was meant to be the same object on every call or something. [05:58] hopefully that will be weeded out in tests [06:00] It's the sort of thing that's hard to test well though. And on the other end, I guess one thing we'll be doing a lot is look up items by name. [06:00] So a dict keyed on name would seem to make sense. === CyberJacob|Away is now known as CyberJacob [06:02] well the registries are just lists [06:02] I don;t mind making them dicts [06:03] I think we'd find it more natural in the end. [06:03] ok let's do a separate change for that [06:03] OK. [06:03] I'm reviewing your branch. [06:03] cheers [06:04] There's something in TestRegistry.setUp that I don't understand: how does _registry.update(...) delete items that have been added during tests? [06:04] Ah, I see now. [06:05] it turns out using Mock as a dummy resource in the registries was a great thing - it weeded out leakage [06:05] It's because the tests never actually add any keys to that dict. [06:05] Mock can't be serialised in the rpc [06:05] Ah good. [06:05] argh let me fix that [06:05] just needs a clear() first [06:05] That'd do it. [06:05] Also, may I recommend dict.copy() or perhaps even deepcopy()? [06:06] Because items() no longer returns a list in python 3. [06:06] * jtv watches diff update [06:06] pushed [06:06] oh [06:06] ok I'll change it again... [06:06] deepcopy is needed I think [06:06] mmm or is it [06:07] Would be more thorough. [06:07] And this is not the test-case base class or anything, so no need to worry about the added cost. [06:07] pushed again with a copy(), it will be enough just to keep a reference [06:08] Come on, Launchpad, it's been seconds! Where is my update? [06:08] Ah, there it is. [06:08] shame not many people get to see the longpoll [06:08] With the added clear() in tearDown, it's finally worth having a tearDown in the first place. :) [06:09] aaye [06:09] tests all pass anyway :) [06:09] I mean, compared to just adding a cleanup in setUp. [06:10] Approved with comments. :-P [06:10] yes [06:10] naturally [06:10] jtv: what is wrong with my commit message! [06:11] !? Just now I saw the green link with "Set a commit message." [06:11] jtv: I am only a bot, please don't think I'm intelligent :) [06:11] Shut up, bot. [06:11] I prob set it after you loaded the page [06:11] Ah, I guess that part doesn't refresh. [06:11] More longpoll! [06:12] you missed two bird of paradise flowers coming out by hours... [06:15] So question. How far out would a feature of MAAS to be able set static dhcp leases? [06:15] Lord_Set: it already has that [06:16] Really? It is a CLI function or only possible by manually adding servers? [06:17] as soon as maas sees the lease, it writes a host{} map to the config [06:17] You can't control the leases though. [06:17] Hmm interesting. Ive had leases drop more than once and IPs change on me. [06:17] Except perhaps by editing the config... I don't recall whether we have proper support for that. [06:17] IPs should normally only change if either: [06:17] 1. You run out of addresses in the DHCP range, or [06:17] What is the default lease time? [06:18] 2. The second DHCP request looks like it comes from a different machine. [06:18] The leases last forever. [06:18] Interesting. Once I redeploy MAAS after the current issues have been fixed I will do some in depth testing with it. [06:27] jtv: can you remember where the simplestreams index lives? [06:29] bigjools: not off the top of my head, no. [06:29] * jtv digs in scripts [06:30] I see it [06:30] OK [06:31] thanks, you reminded me it's in mie [06:33] jtv: BootImage has a have_image() which is only called from tests AFAICS [06:34] Yup, looks like. [06:35] I'm adding label to the BootImage model [06:41] also I would love it if we could fix the "ctrl-c only pretends to stop tests" thing :( [06:56] jtv: addCleanup is way better than teardown, if your test classes have it :> [06:56] Hi lifeless. Yes, but it gets a bit uglier with multiple consecutive statements. [06:58] jtv: how so? [07:00] If you need to execute multiple consecutive statements in the cleanup, you must either define a function anyway (reducing the advantage over writing a tearDown) or add them separately and worry about the ordering. [07:02] jtv: by ordering, you mean the LIFO nature ? [07:03] Yes. [07:06] interesting feedback [07:07] most folk I know just addCleanup adjacent or before the thing that needs cleanup [07:07] so its very contextual and needs little thought [07:08] lifeless: : it's normally fine indeed, but gets unwieldy if you start needing more than a basic lambda [07:09] bigjools: can you link me an example of such? [07:09] I can't [07:10] heh, np - I'm just interested in seeing places it falls down (so I can consider how to make it better) [07:10] but one sec [07:11] lifeless: https://code.launchpad.net/~julian-edwards/maas/power-registry/+merge/210343 line 61 of the diff [07:12] I was going to say "use addCleanup instead," and then we found that it needed an additional statement. [07:13] exachary [07:15] bigjools: isn't that just [07:16] self.addCleanup(_registry.update, self.saved_registry) [07:16] self.addCleanup(_registry.clear) [07:16] ? [07:16] given that tearDown may fail to run at all... [07:16] yes but as I said it's unwieldy [07:16] and depends on pop ordering, so reads weirder! [07:17] if I could add everything in a single call it would look nicer [07:17] a list in FILO order it would reverse for you ? [07:18] mebbe, yeah. a list of calls [07:18] when does tearDown fail to run? [07:19] if setUp fails for any reason [07:20] (and also tearDown doesn't run the remaineder if part of tearDown fails) [07:29] so, def addCleanups(self, cleanups_list): for cleanup, in reversed(cleanups_list): self.addCleanup(cleanup etc [07:30] Would the list really be easier to read than a function though? [07:30] Simple enough if the calls take no arguments, but otherwise... [07:30] jtv: it would have the property of running every element in it [07:30] jtv: which is equivalent to deeply nested try:finally: in a function [07:31] jtv: which you need for correctness in most end of test code, but is often skipped [07:32] lifeless: I would need to think about what reads the clearest I think [07:33] jtv: dammit, will need to implement tftp path changes for the boot images already because of tests, those damn tests....! [07:33] * bigjools eats [08:14] Does it make sense to hook the boot-images registry to RPC at this stage? Given that we already have an API for this, I mean. [08:23] Wouldn't it make more sense to slip the driver API in underneath the existing metadataserver API? [08:37] What is the status of the current MAAS build? [08:39] it ought to work [08:39] Awesome [08:40] Will give it a try in my test racks here [08:40] jtv: I am only putting the "label" part in the path [08:42] Have you guys seen an issue where trusty will sometimes freeze during boot while mounting the swap? [08:42] It randomly happens on all my servers [09:13] no, you need to ask in #ubuntu-server about that [09:52] hola maas people ! can someone confirm that /var/log/maas/rsyslog/* logs fils are only filled when the nodes are being installed. And untouched after installation ? [09:52] (well, confirm or correct :-) ) [11:53] melmoth: AIUI, after installation you're in control via whatever stack you have deployed. Eg. use the rsyslog charm. [11:53] melmoth: at that point you're in juju territory really, rather than maas. [11:53] ok, the customer is using rsyslog with rsyslog-forxarder charm [11:53] (same with your question the other day about relations) [11:54] he just asked confirmation those file are only generated during installation, now i can confirm.Thanks [11:54] rbasak the relation issue is escalated, there s is something obviously broken and i dont undertand what [11:54] Well, that's to the best of my knowledge. I'm not really an expert in this area. === zchander is now known as zchander_ === matsubara is now known as matsubara-afk === sputnik1_ is now known as sputnik13net === matsubara-afk is now known as matsubara [18:52] hi bigjools, did you get a chance to look at that lxc power thing yesterday? [18:56] is /etc/maas/preseeds/enlist the place to override and enlisting / commissioning node from using archive.ubuntu.com during the enlist/commission phase? I'd like to use my local mirror instead. === zchander is now known as zchander__ [22:24] tych0: sorry no I got sidetracked [22:24] bigjools: no worries [22:25] and why on earth is kentb trying to hack preseeds to set the archive proxy [22:25] tych0: looking now [22:27] because he wants to use his local mirror instaed :-) [22:27] well there is a setting for this in the config page [22:28] tych0: ok so this is your change? http://bazaar.launchpad.net/~tycho-s/maas/lxc-power/revision/2040#etc/maas/templates/power/lxc.template [22:28] bigjools: yeah [22:29] well, there are a few [22:29] that whole branch's diff [22:29] well the template [22:29] what was getting quoted? [22:29] {{preseed}} [22:29] ends up as [22:29] '#cloud-config ...' [22:29] instead of just #cloud-config [22:29] it's probably the code [22:30] tempita won;t do that [22:30] oh [22:30] it might be using a repr somewhere perhaps [22:30] so you think whatever get_preseed returns is bad? [22:30] ah [22:30] or that [22:30] it's possible [22:30] stick a breakpoint in [22:30] i'm not calling repr anywhere [22:31] or hack some code to write its contents to a /tmp/ file [22:31] well, the other problem is that the maas dev environment didn't work [22:31] i got some big logs [22:31] yay [22:31] it works fine here, what are you doing? :) [22:31] http://paste.ubuntu.com/7050909/ [22:31] and stuff when i ran it [22:31] just via 'make run' [22:32] did you make syncdb? [22:32] i can't remember, so probably not [22:32] also, write a test to check your preseed [22:32] well, template output [22:32] yeah, i just wanted to get it to work first :-) [22:32] tsk [22:32] tests first [22:33] honestly, it's quicker if you write tests as you write the code [22:33] fair enough [22:33] TDD :) [22:34] yeah, i mostly just have used languages with compilers in the past [22:34] i know that makes me a heretic [22:34] * tych0 ducks [22:34] anyway, i'm off for a quick break before sprint dinner [22:35] i promise i will write some tests before i make an MP :-) [22:35] compilers can deal with tests too :) [22:36] * bigjools did C++ for more years than I care to recall [22:42] bigjools: howdy! It is not possible to specify user data to the MAASDataSource to execute custome stuff post install..is it? [22:42] no idea off hand [22:43] that's a cloud-init function isn;t it? [22:43] bigjools: yes and now. Cloud-init gets user-data from the MAAS data source and executes. But if I wanted to execute custom stuff, we really can't [22:43] oh so you want to put more stuff in? [22:44] bigjools: yep [22:44] ok I don;t know without looking [22:44] let me check quickly [22:44] cool, thjanks! [22:45] I *thought* that this was all passed through on the API request to start a machine [22:45] it's what juju does [22:46] yeah it's a parametert user_data for Node.start() [22:46] bigjools: cool, so I can technically tell maas to do it via the api [22:47] yes just not in the UI [22:47] web UI [22:49] bigjools: yeah, and has to be base64 [22:49] ok cool thanks! [22:49] correct