[04:46] <chiluk> Hey guys is there any hidden functionality that enables maas to be better suited for a test machine environment *(i.e. nag notices on extended length machine reservations?)
[09:23] <jtv> chiluk: we have no such notices, no.  Should be doable through the API though.
[10:24] <rvba> allenap: now that I think about it, wouldn't it be simpler to have a RPC power_change() method instead of power_on/power_off?  This way, the new method used to query the power state of a node would simply be a different call to the existing RPC method?
[10:26] <allenap> rvba: power_change(query=True) smells.
[10:26] <allenap> or something like that.
[10:27] <rvba> allenap: power_change({'on', 'off', 'query'})
[10:28] <allenap> rvba: That smells too. PowerOn and PowerOff don’t declare any response arguments because they’re not relevant. If we munged these together with checking the power state we’d need to declare some response arguments just for that case.
[10:29] <rvba> allenap: hum… okay, good point.  I just feel that the RPC layer is starting to extend its tentacles in every direction.
[10:32] <allenap> rvba: Heh. By keeping the interface very tight and focused instead of overloading RPC calls it’s doing the opposite.
[10:34] <allenap> Once Celery is out and its replacement is in, I think MAAS overall will feel less embraced by wandering tentacles.
[10:34] <rvba> allenap: what interface?  It seems to me we're extending the API surface (the RPC api) quite a bit.
[10:37] <rvba> allenap: one good thing about Celery was that it wasn't very "invasive".  It was pretty clear what the API surface was and how to do retries and things like that was pretty straightforward.   I just hope the RPC stuff won't lose this.
[10:38] <rvba> I'm not saying that it looks like the RPC stuff is going to be worse than Celery was;  the importance of having a simple interface is just something we need to keep mind.
[10:43] <rvba> allenap: btw, the RPC power_on/power_off methods are there now but they are not "wired" (as in, used) at all yet correct?
[10:48] <allenap> rvba: Each RPC call has a well-defined shape. Celery allows us to pass almost anything around, which increases the implementation coupling between parts of MAAS. It’s convenient, but there’s no distinct edge to the layering.
[10:48] <allenap> rvba: That’s right, they’re not used yet because there’s a hornet’s nest of static IP Celery stuff to sort out first.
[10:50] <rvba> allenap: Is sorting out the static IP stuff a pre-req for using the PowerOn/PowerOff methods?
[10:51] <rvba> (Just asking because I was planning to do that now.)
[10:53] <allenap> rvba: They can be used, but if you look in m.models.node…start_nodes you’ll see that power_on can be chained behind a task returned by claim_static_ips().
[10:54] <rvba> allenap: oh, right.  Damn.
[10:56] <allenap> rvba: Indeed. The hornet’s nest is found by digging into claim_static_ips :)
[10:56] <rvba> allenap: yep, it's definitely a hornet's nest :)
[11:03] <bigjools> allenap, rvba: is my beautifully written code too complex for you?  Should I draw a picture? :)
[11:04] <bigjools> FTR, this is why I said we needed a layer on RPC to simulate jobs so that you can chain them to guarantee ordering
[11:04] <rvba> allenap: time for a quick pre-imp chat?
[11:05] <schegi> hey, got some problems with the maas dns, i think. after i bootstrapped a juju node, it is not reachable by dns always getting ERROR state/api: websocket.Dial wss://controller.wcloud.uni-koblenz.de:17070/: dial tcp: lookup controller.wcloud.uni-koblenz.de: no such host when doing juju ssh 0
[11:05] <schegi> bootstrapping works fine starts with Attempting to connect to controller.wcloud.uni-koblenz.de:22 Attempting to connect to 192.168.25.14:22
[11:12] <schegi> anyone?
[11:23] <allenap> bigjools: It is complicated, but then it’s not a trivial problem.
[11:23] <allenap> rvba: Sorry, I was otp, and I’m getting a call back any minute :-/
[11:24] <bigjools> allenap: yes, I always said that removing celery was not as simple as just replacing tasks with rpc :)
[11:24] <rvba> allenap: it won't take long, and I can wait if the someone calls you while we're on the phone.  I'd be happy to talk to you before we step out for lunch if possible.
[11:24] <rvba> s/the someone/someone/
[11:25] <allenap> rvba: Okay, call again.
[12:05] <bigjools> if anyone needs a trivial bug to fix: https://bugs.launchpad.net/maas/+bug/1340920
[12:40] <bigjools> the formatter's ordering of imports can really bugger up tests when you're using monkeypatching :(
[12:52] <bigjools> allenap: do you know a convenient way to create a mock object that has mock functions which return a particular value, without doing a dance involving multiple mocks?
[12:53] <allenap> bigjools: Yes :)
[12:53] <allenap> my_thing = self.patch(thing, “name”)
[12:53] <bigjools> excellent, always full of useful info
[12:53] <bigjools> :)
[12:53] <allenap> my_thing.function_1.return_value = 1234
[12:53] <bigjools> oh that easy
[12:53] <allenap> Just reference the thing you want and you’ll get a Mock back.
[12:53] <allenap> Yep.
[12:54] <bigjools> the obvious is always sitting too close to see, isn't it?
[12:54] <allenap> Yeah. And mock is a little scary too.
[12:55] <bigjools> allenap: a further thing - is there a convenient way of making the return value conditional on passed values? :)
[12:55] <allenap> bigjools: Also, see mock.create_autospec(). That’s a fairly cool function.
[12:55] <allenap> bigjools: my_thing.function_1.side_effect = my_callable
[12:55] <bigjools> basically I am patching the rpc client
[12:55] <bigjools> oh side_effect...!
[12:55]  * bigjools not having a good day
[12:56] <allenap> Hehe :)
[12:56] <rvba> allenap: care to have a look at this tiny branch? https://code.launchpad.net/~rvb/maas/retry-power-changes-1/+merge/227722
[12:57] <allenap> rvba: It would be my pleasure.
[13:02] <rvba> allenap: ta
[13:03] <rvba> allenap: "RabbitMQ will be going away this cycle" to we have a plan to do away with txlongpoll?  Because it also depends on RabbitMQ.
[13:03] <rvba> s/to we/do we/
[13:06] <allenap> rvba: In my mind I do :) otp now.
[13:06] <bigjools> rvba: irrelevant for this bug though
[13:06] <rvba> bigjools: who said it was about this bug?
[13:06] <bigjools> rvba: because that's the context for the statement!
[14:32] <bigjools> allenap: there?
[14:32] <bigjools> need rpc halp
[14:43] <allenap> bigjools: I’ll be with you in 3 minutes.
[14:46] <bigjools> tick tock
[14:47] <allenap> bigjools: https://plus.google.com/hangouts/_/canonical.com/bigjools
[14:48] <bigjools> allenap: https://code.launchpad.net/~julian-edwards/maas/image-download-service/+merge/227309
[15:01] <bigjools> allenap: can you review my branch please?
[15:05] <rvba> allenap: question for you:  I thought the methods in src/provisioningserver/rpc/clusterservice.py like power_on where being executed in the reactor?   That's weird because PowerAction.execute is effectively blocking… isn't that a problem?
[15:07] <bigjools> rvba: should be deferred to a thread
[15:07] <rvba> allenap: in other words, shouldn't this be wrapped in deferToThread?
[15:07] <allenap> rvba: Yeah, it probably should be deferred. I’ll sort that out unless you want to?
[15:07] <rvba> allenap: I'm on it.
[15:07] <allenap> Tip top.
[15:28] <bigjools> allenap: https://code.launchpad.net/~julian-edwards/maas/image-download-service/+merge/227309
[15:29] <allenap> bigjools: I’m half way done already. Waaay ahead of you :)
[15:29] <bigjools> allenap: ha!
[15:30] <bigjools> allenap: I just realised I am about to be hoist by my own petard
[15:30] <bigjools> I only did happy path testing
[15:30] <bigjools> lol
[15:30] <allenap> bigjools: Hehe, everything’s happy in Twistedland.
[15:31] <bigjools> allenap: because it's on drugs
[15:31] <allenap> Absolutely. As long as it doesn’t stop taking them it’ll never come down ;)
[15:57] <bigjools> allenap: I just re-read the original email you sent me about the implementation for this and realised I got something wrong.  Lack of maas.meta means it should not be importing automatically.
[16:00] <allenap> bigjools: Ah yes! I’d forgotten that.
[16:03] <bigjools> allenap: LOL at last two MP comments
[16:13] <schegi> hey one question in the /etc/maas/templates/dhcp/dhcpd.conf.template the option ntp-server is set by dhcp_subnet.get('ntp_server') but there is no specific option when specifying dhcp in maas how to set that to a different address?
[16:15] <matsubara> schegi, The setting is in the main maas settings page not at the cluster dhcp config.
[16:15] <matsubara> I mean, the ntp server setting.
[16:16] <schegi> ok gotz it thx
[16:17] <matsubara> np
[16:17] <schegi> ah and theere is also a field for the forwarders, nice
[16:17] <schegi> have hardcoded them
[16:18] <schegi> if i update these values do i have to restart something??
[16:19] <matsubara> Nope
[16:20] <schegi> it is just possible to specify one forwarder right?
[16:22] <matsubara> Yes
[17:09] <automatemecolema> So I'm getting an "Internal Server Error" after I have MAAS installed, and the PXE images downloaded. Not sure what has happened. I used the latest ISO release, and updated before I installed MAAS any ideas?
[17:10] <automatemecolema> Looked through some logs and maas.log reveals an RPC connection error, and celery has a couple errors too
[18:06] <Sh3l0ck> Is there a way to statically map IP addresses to machines in MAAS?
[18:07] <roaksoax_> Sh3l0ck: not until the next release
[18:09] <Sh3l0ck> roaksoax_: Oh I see...Is the next release coming out soon?
[18:35] <roaksoax_> Sh3l0ck: yes! sometime in the next few weeks
[18:59] <automatemecolema> So I'm getting an "Internal Server Error" after I have MAAS installed, and the PXE images downloaded. Not sure what has happened. I used the latest ISO release, and updated before I installed MAAS any ideas?
[20:43] <newell> automatemecolema, can you do a tail -f *.log in /var/log/maas and see if there is any information that would help you out
[21:33] <breze411> anyone knows what login works maas nodes console ?