[03:21] <AskUbuntu> Ubuntu 14.04 LTS server + MAAS WEB gui wont import boot image | http://askubuntu.com/q/483883
[08:09] <rvba> bigjools: we've used a FakeRequest in a couple of places…
[08:09] <rvba> :)
[08:11] <rvba> bigjools: right, you need to shove whatever field you need in the FakeRequest.  See for instance how we've set the 'user' field in the FakeRequest in src/maasserver/tests/test_api_support.py.
[08:13] <bigjools> rvba: eurgh
[08:13] <bigjools> rvba: it's easier to create a real request surely
[08:14] <rvba> bigjools: we've used the RequestFactory in a couple of places as well (it's coming back to me now)
[08:35] <rvba> bigjools: ugly I know, but please have a look at src/maasserver/tests/test_middleware.py:fake_request
[08:54] <bigjools> rvba: je vais regarder
[08:55] <bigjools> rvba: maybe I should put that util in the testing dir
[08:56] <rvba> bigjools: yeah, looks like we've added many different ways of creating a test request.  All over the place.
[08:56] <bigjools> rvba: I had noticed :(
[08:56] <bigjools> rvba: I'll put it in the factory
[08:57] <rvba> Sounds good.
[08:57] <bigjools> FWIW those getCamelCaseThings really jar with the make_things!
[09:08] <bigjools> rvba: that's not right that Messages uses a class property as storage in that thing, is it?
[09:23] <rvba> bigjools: why?
[09:25] <rvba> bigjools: request._message it is an instance of Message… what's wrong with that?
[09:26] <bigjools> rvba: the fake Message has self.messages as a class property
[09:26] <bigjools> seems a bit weird
[09:26] <bigjools> works, anyway
[09:26] <bigjools> rvba: https://code.launchpad.net/~julian-edwards/maas/staticip-api-exceptions/+merge/223192 :)
[09:27] <rvba> bigjools: I'll review it (still otp) soon
[09:27] <bigjools> rvba: thank you.  can you or jtv please review https://code.launchpad.net/~julian-edwards/maas/allocate-ip-on-start-2/+merge/222747 as well please, I am totally blocked on that now
[09:28] <rvba> bigjools: sure.  One of us (me, allenap or jtv) will take care of it today.
[09:28] <bigjools> rvba: a thousand thank yous
[09:36] <jtv> Or "toosind tak" as they say in Danish.
[09:36] <jtv> (Which happens to be their standard way of saying "thanks a lot")
[10:59] <bigjools> rvba: "Why using the hostname here and the system_id in the API error?"
[10:59] <bigjools> Why do you think? :)
[12:03] <rvba> bigjools: sorry, I meant "Why are you using the system_id in the API and the hostname in the UI?"
[12:04] <bigjools> rvba: same response :
[12:04] <bigjools> :)
[12:04] <rvba> heh
[12:04] <bigjools> IOW, which would you, as a consumer of each, prefer to see?
[12:06] <rvba> bigjools: I tend to favor using the system id, because it's guaranteed to be constant.
[12:06] <rvba> But I can see why the hostname makes sense in the UI.
[12:06] <bigjools> so you see why I used the system id in the api and the hostname in the web ui? :)
[12:07] <bigjools> the system id appears nowhere in the web ui
[12:07] <rvba> Well, it's in the URI of course.
[12:08] <rvba> I just wish we had a pattern for these kind of things.
[12:09] <bigjools> the url to the page is irrelevant in the context of a good web ui
[12:10] <rvba> The system id should at least be displayed on the node's page.
[12:11] <rvba> But anyway, that was a detail.
[12:11] <rvba> allenap should be in the process of reviewing your other branch.
[12:11] <allenap> rvba: I am in the process of doing that.
[12:12] <rvba> allenap: cool ;)
[12:58] <bigjools> allenap: much grassy ass.  I shall be heading to bed now.
[12:58] <allenap> bigjools: nn
[12:58] <allenap> Nearly done.
[12:58] <bigjools> be gentle with me
[13:07] <galebba> Happy Monday, newbie here.Sorry to repeat the question i asked here yesterday.Where should i look for logs that shows ipmi powering on/off nodes ? I have setup maas and trying to add the first node. Booted the node from the dvd and pointed to maas server. Node get powered off as expected but doesnt show up under the nodes in the gui.
[13:07] <bigjools> allenap: just caught the review before actually going to bed.  Thanks :)
[13:07] <bigjools> galebba: /var/log/maas/celery.log
[13:09] <galebba> Thanks. but it does not show any indication of an issue. This is all i have  INFO/MainProcess] Task provisioningserver.tasks.upload_dhcp_leases[fe6beb91-8dfa-4eee-9f7b-bfa9c9ed01bf] succeeded in 0.0749380588531s: Non
[13:09] <galebba> and nothing in maas.log and pserv.log
[13:09] <bigjools> make sure there's power parameters defined in the edit node page
[13:10]  * bigjools off now, bye
[13:11] <rbasak> galebba: the power control pieces are templated scripts. I forget where they are exactly, but one option to debug is for you to wrap them or amend them for debugging.
[14:44] <galebba> so i got the nodes to power on.off using the ipmitool with the follwoing,  ipmitool -H 172.18.112.136 -U admin -P password -I lanplus  -y 0000000000000000000000000000000000000000 chassis power status
[14:45] <galebba> how do i insert a crypto key in to Maas ipmi templates as it seems the use of the keys is not in maas
[14:45] <galebba> btw this is maas 1.4 on 12.04 LTS and Cisco UCS C series server
[15:59] <blake_r> allenap: ping
[16:04] <alexpilotti> blake_r: ping
[16:04] <blake_r> allenap: hey
[16:04] <blake_r> alexpilotti: hey
[16:04] <alexpilotti> blake_r: do we have a meeting today? :-)
[16:04] <blake_r> alexpilotti: yes
[16:04] <alexpilotti> blake_r: trying to join on the hangout but no luck
[16:04] <blake_r> alexpilotti: sorry running late
[16:23] <allenap> Hey blake_r, what’s up?
[16:24] <blake_r> allenap: how does rpc handle long running operatings
[16:25] <blake_r> allenap: will it block, or is it async
[16:26] <allenap> blake_r: It won’t block any other RPC calls. If you use it from Twisted-land then it won’t block, but the helpers that are in (can’t remember offhand) will block the running thread if you need blocking.
[16:26] <blake_r> allenap: from maasserver side will it block
[16:27] <allenap> blake_r: We’re also planning on having “threads” (not OS threads) that can be initiated and queried, so things like boot and install and can started by a Django thread and revisited later on.
[16:27] <blake_r> allenap: i got a branch for diskless booting
[16:27] <allenap> blake_r: From Django, yes, they’ll block, but all calls go via Twisted’s event-loop, and there’s one of those running in every Django process on the region.
[16:27] <blake_r> allenap: i want to use rcp to create the disk on the cluster
[16:28] <allenap> blake_r: Cool.
[16:28] <blake_r> allenap: so it will take a while
[16:28] <blake_r> allenap: so if i make the call, it will wait for the response?
[16:28] <blake_r> allenap: i don't want to block the webrequest, but i want to wait to execute the poweron
[16:29] <allenap> blake_r: You could have a response which says “I’ve started, here’s my uuid if you want to check on my later”.
[16:29] <allenap> s/my/me/
[16:29] <blake_r> allenap: rpc returns a uuid?
[16:29] <allenap> That’s our proposal for the robustness work.
[16:29] <allenap> blake_r: Nope, but it could do. Do you want a call about this later?
[16:29] <blake_r> allenap: sure
[16:30] <allenap> blake_r: In 3h okay?
[16:30] <blake_r> allenap: 3h?
[16:30] <allenap> I have another call then dinner and kids into bed stuff to do between now and then.
[16:30] <allenap> blake_r: 3 hours.
[16:30] <blake_r> allenap: oh okay, thats fine
[16:31] <blake_r> allenap: i send you an invite
[16:31] <allenap> blake_r: Ta.
[19:11] <skinder_> where's a good place to inquire as to problems with maas? i've setup a cluster controller that, when hosts in the subnet pxe boot and attempt to start the provisioning process, i get an error about / not being found
[19:11] <skinder_> i'm a bit stumped
[19:14] <MilesDenver> Yea, I think this is a good place skinder
[19:15] <MilesDenver> At the moment, I'm working on understanding the actual steps to build a system.  The language seems off and my system never seems to stay powered on.
[19:15] <MilesDenver> Documentation doesn't have steps.
[19:16] <MilesDenver> skinder_: have you modified your preseed files?
[19:17] <skinder_> nope, a very basic unmolested install. the region controller is able to do its thing, and provision hosts in the subnet it's in, but when i added the second cluster controller, hosts in its subnet don't complete the pxe boot process.
[19:18] <MilesDenver> both the first and the second are in the same subnet?
[19:18] <skinder_> no, is that necessary?
[19:18] <blake_r> skinder_: can the second cluster controller, reach the region controller
[19:18] <skinder_> yes
[19:19] <MilesDenver> no... it won't work actually.  MaaS is pretty good at making sure it's the only DHCP in the logical network
[19:19] <blake_r> skinder_: it needs to be able to reach the region, and so do the nodes!
[19:19] <blake_r> skinder_: do the nodes, have a route to the region as well?
[19:19] <skinder_> yes
[19:19] <skinder_> L3 connectivity is good
[19:19] <blake_r> skinder_: what is the error you are getting on the nodes?
[19:20] <skinder_> blake_r: one moment, i'll get you the exact error
[19:20] <skinder_> MilesDenver: well the two cluster controllers are the only dhcp servers in their respective broadcast domains, so that shouldn't be a problem i don't think
[19:22] <skinder_> and they're in different subnets, no dhcp forwarding is happening either
[19:23] <MilesDenver> Keep talking through the issue.  I'm not the expert Blake_r is, but i'll help where I can
[19:24] <skinder_> blake_r: "The disk drive for / is not ready yet or not present. Continue to wait, or Press S to skip or M for manual recovery."
[19:24] <skinder_> that is displayed directly after the "Net device info" and "Route info" tables are displayed
[19:24] <blake_r> skinder_: has it already installed? or should it be installing?
[19:24] <blake_r> skinder_: on the cluster, do "sudo service tgt restart"
[19:25] <blake_r> skinder_: also you do have the boot images imported for that cluster?
[19:25] <skinder_> blake_r: yes, boot images are installed
[19:25] <skinder_> blake_r: and no, it hasn't already installed
[19:25] <blake_r> skinder_: did it say the anything about ISCSI? trying to connect?
[19:26] <blake_r> skinder_: are you using fast-path installer?
[19:26] <skinder_> blake_r: yes, i have seen iscsi messages zip by
[19:26] <skinder_> tgt is restarted, will try again
[19:26] <blake_r> skinder_: so thats fast-path
[19:26] <blake_r> skinder_: yeah let me know if that works, if not
[19:27] <blake_r> skinder_: got something else for you to try that will help you debug
[19:27] <skinder_> blake_r: sweet, thanks. i will update momentarily.
[19:30] <skinder_> blake_r: still gets stuck at the same spot, same error
[19:38] <MilesDenver> I have a sad question - Why doesn't my new node stay running?  It displays it's hostname, but shuts down in less than a minute.
[19:45] <MilesDenver> With a simple web interface, you can add, commission, update and recycle your servers at will
[19:45] <MilesDenver> Does Commission mean set the Operating System on it and leave it running?
[19:47] <skinder_> i thought it was commission -> install
[19:50] <skinder_> oh wait derp that's probably not what you were asking. i've seen commissioned nodes stay powered on.
[19:50] <MilesDenver> skinder_ thanks
[19:50] <MilesDenver> I'm testing with a system that boots glacially slow.
[19:51] <skinder_> fun fun
[19:51] <MilesDenver> seems like "Start" is the same as "Accepting" a node
[19:51] <MilesDenver> START a) Finds DHCP server b) Receives PXE details c) Boots temp image d) Reports to MaaS server e) Node shuts down
[19:52] <MilesDenver> COMMISSION must therefore load an OS and stay running.
[19:54] <skinder_> like you MilesDenver, i wish there were more details about the entire process. what happens during the commissioning, install, etc.
[19:54] <skinder_> makes it hard to troubleshoot without that
[19:54] <skinder_> especially when using a java remote kvm console in a linux desktop :P
[19:54] <MilesDenver> skinder_: so, we hang out here and help each other.  That works.
[19:54] <MilesDenver> hahaha
[19:56] <MilesDenver> Commissioning booted with the proper OS and name... ran for about a minute and powered off.
[19:58] <jhobbs> MilesDenver: "start" is load an os and stay running
[19:58] <jhobbs> MilesDenver: "commission" is more or less "get a node ready to install to"
[19:59] <MilesDenver> jhobbs: cool.  I'll try that.  Just deleted my node thinking I had it in some strange state
[20:00] <MilesDenver> Not really sure why the published doc is missing that detail.
[20:01] <blake_r> skinder_: same issue?
[20:01] <skinder_> blake_r: yes
[20:01] <blake_r> skinder_: is the node, that is trying to boot, already in MAAS, liek shows up in the WebUI
[20:02] <skinder_> blake_r: no
[20:02] <blake_r> skinder_: okay, is it amd64?
[20:02] <blake_r> skinder_: actually that doesn't matter
[20:02] <blake_r> skinder_: do this on the cluster
[20:02] <blake_r> skinder_: "tftp 127.0.0.1"
[20:02] <blake_r> skinder_: "get /pxelinux.cfg/default"
[20:03] <blake_r> skinder_: please pastebin the output
[20:03] <blake_r> skinder_: "cat default"
[20:03] <skinder_> blake_r: it'll be posted shortly
[20:04] <skinder_> blake_r: http://pastebin.com/rHcdHNaB
[20:05] <blake_r> skinder_: what version of MAAS are you runing?
[20:05] <skinder_> blake_r: 1.5.4
[20:05] <skinder_> blake_r: ubuntu 12.04.5
[20:05] <blake_r> skinder_: newest version uses trusty, for enlistment and commisioning, this is showing precise
[20:06] <blake_r> skinder_: even on precise should boot trusty for enlistment
[20:06] <skinder_> blake_r: kk will give that a go
[20:06] <blake_r> skinder_: you are running an older version
[20:06] <blake_r> skinder_: even the kernel paths are old
[20:07] <skinder_> blake_r: apparently one of my coworkers upgraded from 1.3 to 1.5
[20:07] <blake_r> skinder_: then you need to run, maas-import-pxe-files again!
[20:07] <skinder_> blake_r: did, but i'll do so again
[20:09] <skinder_> blake_r: so apparently trusty wasn't listed in the /etc/maas/import_pxe_files sources, i added that, going to re-run the pxe file import
[20:09] <blake_r> skinder_: okay, let me know
[20:24] <skinder_> blake_r: same problem. even after the pxe image update, it's still pointing to the same precise images in the pxe cfg, not trusty
[20:24] <blake_r> skinder_: "sudo service maas-pserv restart"
[20:24] <blake_r> skinder_: try again
[20:24] <skinder_> blake_r: already did that
[20:25] <skinder_> i'm honestly just considering nuking these servers, installing a fresh copy of 14.04 and maas, and going from there
[20:26] <MilesDenver> That's what I did
[20:26] <blake_r> skinder_: your going to have better luck with that
[20:26] <blake_r> skinder_: but it should work
[20:27] <blake_r> skinder_: apt-cache policy maas-cluster-controller
[20:27] <skinder_> http://pastebin.com/7kUBHVjW
[20:28] <blake_r> skinder_: your using 1.4
[20:28] <blake_r> skinder_: not 1.5.3
[20:28] <blake_r> skinder_: if your region is not the same version, it will not work
[20:29] <blake_r> skinder_: that makes since, as 1.4 is the highest on precise
[20:29] <skinder_> well, maas --version on the region controller says 1.5.4, and the package is named the same as on the cluster controller
[20:30] <skinder_> curious
[20:30] <blake_r> skinder_: well that is very strange
[21:14] <MilesDenver> Still seeing the behavior where after commissioning the node builds. runs for 90 seconds and shuts down.
[21:22] <MilesDenver> If I disable DHCP, it can boot and stay running.... so something it's getting registered back to the MaaS server to let it know the system build is complete.
[21:23] <MilesDenver> But I cannot log in to see the Node I just built, because it has not IP address
[22:37] <MilesDenver> anyone know how to debug a system that stays in a cycle of building.  Meaning after a successful node build, it shuts down and if you start it again is rebuilds... and shuts down
[22:43] <AskUbuntu> Openstack Neutron - Cannot Access Tenant Router Gateway | http://askubuntu.com/q/484293