| === CyberJacob is now known as CyberJacob|Away | ||
| === kickinz1|afk is now known as kickinz1 | ||
| gnuoy | Hi, I'm using maas 1.7 from the experimental ppa. When I try an create an new boot resource I get | 06:41 |
|---|---|---|
| gnuoy | {"architecture": ["'amd64/generic' is not a valid architecture. It should be one of: ''."]} | 06:41 |
| gnuoy | does this ring a bell with anyone? | 06:41 |
| gnuoy | http://paste.ubuntu.com/8408696/ | 06:43 |
| === CyberJacob|Away is now known as CyberJacob | ||
| gnuoy | ok, I seem to be past that after installing the base images. sorry for the noise | 07:11 |
| rvba | gnuoy: I think this is actually a bug. AFAIK there is no reason to force you to import the base images to let you manually import a different image. | 07:16 |
| gnuoy | rvba, ok, thanks, I'll file a bug. While you're here .... The 'boot-resources create' completed silently after a few minutes boot the boot image is not appearing in the bootimages pages in the webui. I don't see any errors in the maas.log | 07:19 |
| gnuoy | s/boot the boot/but the boot/ | 07:19 |
| gnuoy | but I do see the image is now in /var/lib/maas/boot-resources/snapshot* | 07:20 |
| rvba | gnuoy: the images are now downloaded to the region and *then* synced to the cluster… the sync should happen right after the download but this is when the processing happens so it's not instantaneous. | 07:20 |
| gnuoy | rvba, I shall try being patient, thank you :) | 07:20 |
| rvba | And thanks for filing a bug. | 07:21 |
| rvba | gnuoy: this mechanism is quite new (and still being worked on) so please file bugs about usability problems etc. | 07:22 |
| gnuoy | Will do | 07:23 |
| rvba | Ta | 07:23 |
| === kickinz1 is now known as kickinz1|afk | ||
| === kickinz1|afk is now known as kickinz1 | ||
| === CyberJacob is now known as CyberJacob|Away | ||
| === kickinz1 is now known as kickinz1|afk | ||
| === kickinz1|afk is now known as kickinz1 | ||
| caribou | jtv: remember my the TFTP maas issue I had yesterday ? | 08:52 |
| jtv | Hi caribou... yes, and I remember not understanding what might have caused it. Any news? | 08:53 |
| caribou | jtv: well, it's either an explanation or a workaround | 08:54 |
| * jtv looks curious | 08:54 | |
| caribou | jtv: I found that if I do a reset of the VM once it has failed to get the TFTP file, it works ! | 08:54 |
| jtv | The VM being the simulated node? | 08:55 |
| caribou | jtv: yes | 08:55 |
| * jtv ponders | 08:55 | |
| jtv | Sounds almost as if it no longer tries to netboot or something... | 08:55 |
| caribou | I was wondering if I was doing the "commissionning" too fast for maas to have time to react | 08:55 |
| caribou | jtv: well, I just wanted to let you know. At least I got my maas setup working so I can test the other problem | 08:56 |
| jtv | It would be nice to understand this, so we can document and/or fix etc... | 08:57 |
| jtv | Remind me: you netbooted the VM to auto-enlist it, and then it failed to netboot for commissioning, right? | 08:57 |
| caribou | jtv: well, it is reproducible on my side. It could be environmental as well | 08:57 |
| jtv | (BTW annoying difference between French and English, one of many: "commissioning," with lots of double consonants but not the ‘n’ :-) | 08:57 |
| jtv | Even if it's environmental, it could translate into useful advice for others. | 08:58 |
| caribou | jtv: no simpler than that : I setup maas, configure it, then PXE boot a VM | 08:58 |
| caribou | jtv: the first PXE boot works fine & the VM is seen by maas | 08:58 |
| jtv | Yes, at that point the VM should enlist with MAAS. | 08:58 |
| caribou | then I Edit the node, change its name & power setup so it can be controlled by virsh | 08:58 |
| caribou | do the ssh key bits so maas can issue libvirt commands | 08:59 |
| jtv | *The very latest version I believe will tell you if there's a problem with the power parameters.) | 08:59 |
| jtv | ( | 08:59 |
| jtv | And then you tell MAAS "commission this node" but nothing happens? | 08:59 |
| caribou | then I go & click on "commission", the VM starts and the TFTP request never completes | 08:59 |
| jtv | Hmmm | 09:00 |
| jtv | I wonder if it's a problem with the IP address from DHCP. | 09:00 |
| caribou | the TFTP request gets to the maas server (as seen in /var/log/syslog) but it never does more than that | 09:00 |
| caribou | if I do "virsh reset {VM}", then it works | 09:00 |
| jtv | I'm thinking maybe it's because the DHCP client in the PXE gets a different IP address from the one in the OS. | 09:00 |
| caribou | apparently it sees it ok (according to /var/log/syslog) | 09:01 |
| jtv | Or maybe... | 09:01 |
| caribou | oh, another thing I noticed but might be a fixed issue | 09:01 |
| jtv | You're saying this is very fast? But the problem happened in 1.5, right? | 09:01 |
| caribou | I can only do that kind of test once. If I delete the node & start over again with the same VM it fails | 09:01 |
| caribou | yes, I'm testing 1.5 only atm | 09:02 |
| caribou | If I want to *reuse* the same VM, I need to remove the NIC & create a new one so the MAC address changec | 09:02 |
| caribou | changes | 09:02 |
| jtv | It might be worth a look to see if the OS boot and the PXE boot get the same IP addresses from DHCP. | 09:02 |
| caribou | I think that there is some problem with trying to add a new node with the same MAC on the dhcp lease side | 09:02 |
| caribou | I can do that | 09:03 |
| jtv | Yes, there can be problems with that. | 09:03 |
| jtv | Where the two clients basically get treated as two machines. | 09:03 |
| jtv | IIRC we have workarounds for that in the DHCP config, but VMWare might have its own PXE implementation that those workarounds don't, er, work around. | 09:03 |
| caribou | well, in my case it's not VMware but qemu/kvm | 09:04 |
| caribou | ok, let me re-run the whole test once again & see what I get | 09:04 |
| jtv | Oh sorry I thought you said VMWare at some point. | 09:06 |
| caribou | jtv: no worry | 09:08 |
| caribou | jtv: this is the kind of msg I get when I *reuse* a VM : | 09:09 |
| caribou | jtv: dhcpd: DHCPREQUEST for 192.168.123.185 (192.168.123.1) from 52:54:00:76:32:4e via eth0: lease 192.168.123.185 unavailable. | 09:09 |
| jtv | Ah yes. | 09:09 |
| jtv | It's probably unavailable because either: | 09:09 |
| jtv | 1. The PXE DHCP client and the OS DHCP client get treated basically as different systems. | 09:10 |
| jtv | 2. The last lease is still active. | 09:10 |
| jtv | I think #1 is the most likely explanation. | 09:10 |
| jtv | (Because otherwise there'd be nothing stopping the DHCP server from giving the node a fresh address in the first place, unless your DHCP range is completely exhausted.) | 09:11 |
| jtv | (I'm assuming you have a DHCP range that's considerably larger than the number of virtual machines.) | 09:11 |
| caribou | jtv: yes, 100 nodes | 09:11 |
| jtv | And how big are the address ranges on your node network? | 09:12 |
| caribou | what do you mean by "node network" ? | 09:13 |
| jtv | The network on which you're letting MAAS serve DHCP. | 09:13 |
| caribou | jtv: btw, the maas server itself is a VM (yeah, I know I'm making things a bit twisted) | 09:13 |
| jtv | No, that should be fine. | 09:13 |
| jtv | As long as you don't have conflicting DHCP servers, obviously. :) | 09:13 |
| caribou | jtv: it has the whole 192.168.123 network to itself | 09:13 |
| jtv | So /24. | 09:14 |
| caribou | yep | 09:14 |
| jtv | That might still run out I guess, given the wrong circumstances. And do you have a static and a dynamic IP range configured on the cluster interface? | 09:14 |
| caribou | btw, I don't want to waste your time on this. I can investigate it myself, just wanted to keep you posted | 09:14 |
| caribou | no, I don't think 1.5 has that feature yet | 09:14 |
| jtv | Believe me, I appreciate that very much. Part of me is just curious though, and part of me wants to prevent more people from asking us the same thing later. :) | 09:15 |
| jtv | Ah right, 1.5. | 09:15 |
| caribou | yeah, same here. My dayjob if to fix bugs. I hate to overlook one when I find it | 09:15 |
| jtv | You might want to have a look at your leases file, to see if the server is running out of addresses, but 1.5 may still have the dhcpd bug where the leases file doesn't get cleaned up. | 09:16 |
| caribou | yeah, I think that's the bug I was refering to; I've seen that before | 09:16 |
| jtv | I'd certainly consider allocating a larger subnet. | 09:16 |
| jtv | Let me check what happened to that bug... | 09:16 |
| caribou | ok, I have a few minutes: I'll ditch the current maas setup, rebuild it & see if I can reproduce on a fresh install | 09:17 |
| jtv | The current Trusty packaging does have the workaround, so I'd expect your leases file to be nice and clean. | 09:18 |
| caribou | so at least the log files are not filled with all the tests I ran yesterday | 09:18 |
| caribou | oh, other than that everything seems to work fine, I was able to bootstrap juju on this maas server | 09:21 |
| rvba | Simple UI branch up for review: https://code.launchpad.net/~rvb/maas/nel-ui/+merge/235584 | 09:23 |
| * jtv struggles to keep up with rvba | 09:25 | |
| jtv | Oh I do like the faster test startup... | 09:26 |
| jtv | rvba: review done. | 09:31 |
| rvba | Thanks. | 09:31 |
| jtv | Oh wow. | 09:42 |
| jtv | Why on Earth do we still have JS tests with hard-coded enum values? | 09:42 |
| jtv | After all that work to make our enums available uniformly across JS and Python? | 09:43 |
| jtv | Maybe it was to protect against accidental value changes. | 09:46 |
| jtv | Gavin: thanks for the __new__ tip. It's always a few years between encounters with that thing and I always forget it's there. | 09:52 |
| jtv | Erm. A shame tests are failing all over the place though. | 09:52 |
| jtv | May be unrelated. I'll see what the output is. | 09:52 |
| allenap | jtv: __new__ is a bit of an ugly wart :-/ | 09:53 |
| jtv | Ah, I forgot to pass cls. | 09:53 |
| jtv | Do I need to decorate it as a @classmethod? | 09:53 |
| jtv | Nope, apparently not — it works without. | 09:58 |
| allenap | jtv: Python automagically declares it _static_, which I guess is because of History. | 10:01 |
| * jtv hates History | 10:01 | |
| jtv | allenap: replacement MP → https://code.launchpad.net/~jtv/maas/bug-1372735-bis/+merge/235600 | 10:05 |
| === kickinz1 is now known as kickinz1|afk | ||
| rvba | allenap: care to review https://code.launchpad.net/~rvb/maas/relax-mark-failed/+merge/235606 ? It's the followup from our conversation from yesterday, | 10:43 |
| allenap | rvba: Sure. | 10:49 |
| === kickinz1|afk is now known as kickinz1 | ||
| gmb | rvba: Does the node event log stuff rely on RPC? | 11:08 |
| gmb | rvba: Actually, a more pertinent question: what's the relation of the metadataserver code to maasserver… I.e. can I just safely call model stuff from metadataserver code? | 11:09 |
| allenap | gmb: You can. | 11:10 |
| gmb | allenap: Huzzah. I thought as much from looking at it, but wanted to check before I did anything catastrophically daft. | 11:10 |
| allenap | gmb: You’re safe; we’ve done all the catastrophically daft things already. | 11:11 |
| gmb | MAAS core team: Blowing things up so you don't have to | 11:12 |
| === kickinz1 is now known as kickinz1|afk | ||
| === kickinz1|afk is now known as kickinz1 | ||
| === kickinz1 is now known as kickinz1|afk | ||
| gmb | rvba, jtv, allenap: https://code.launchpad.net/~gmb/maas/event-for-netboot-off/+merge/235615 for needing of review pleasekthx | 11:51 |
| jtv | gmb: got it. | 11:51 |
| jtv | gmb: you want to turn netboot? Into what? | 11:51 |
| gmb | jtv: Either I'm missing a funny thing or I've done something confusing. Please elucidate :) | 11:52 |
| gmb | Oh! | 11:52 |
| gmb | jtv: Haha. | 11:52 |
| jtv | :) | 11:52 |
| gmb | Sorry, my Engrish is strong today | 11:52 |
| jtv | The answer was "both." | 11:52 |
| gmb | Indeeds. | 11:54 |
| === kickinz1|afk is now known as kickinz1 | ||
| gmb | /win 10 | 12:19 |
| gmb | Gaah | 12:19 |
| === kickinz1 is now known as kickinz1|afk | ||
| === kickinz1|afk is now known as kickinz1 | ||
| === kickinz1 is now known as kickinz1|afk | ||
| rvba | allenap: thanks for the review on https://code.launchpad.net/~rvb/maas/relax-mark-failed/+merge/235606. Maybe I can do something even better: have the RPC method know about the exception and only ignore it when it's raised in the periodic power check. | 12:53 |
| === kickinz1|afk is now known as kickinz1 | ||
| allenap | rvba: That’s *worse*! Are you trolling? | 13:10 |
| rvba | allenap: I was not. Why do you think it's worse? | 13:11 |
| rvba | allenap: as you pointed out, changing mark_failed was overly broad. | 13:11 |
| allenap | rvba: Okay. It would violate layering to have the RPC code know to ignore exceptions depending on the caller. I think either the responder for MarkNodeFailed in the region should ignore NodeStateViolation all the time, or it should send it over the wire back to the cluster, where the periodic poller code would catch it and ignore it. | 13:14 |
| rbasak | MarkNodeFailed? | 13:15 |
| rvba | allenap: the second option is exactly what I'm proposing. | 13:15 |
| rbasak | Sounds like a special exception just for sabdfl :) | 13:15 |
| rvba | rbasak: heh | 13:15 |
| === jefferai__ is now known as jefferai | ||
| allenap | rvba: Oh, okay, in that case it sounds fine. | 15:04 |
| gmb | rvba: So, netboot_off is done anonymously, I guess… | 15:08 |
| rvba | gmb: yep | 15:08 |
| gmb | Okay. | 15:08 |
| gmb | rvba: Any point having both netboot_off()s emit this event, or are we just in for a world of duplication and pain? | 15:09 |
| rvba | gmb: I have no idea when the other code path is used. | 15:09 |
| rvba | Let's not duplicate this. | 15:09 |
| gmb | K | 15:09 |
| gmb | I’ll just move it to the anon handler. | 15:09 |
| rvba | And maybe fix the call to register_event_and_event_type() while you're at it. | 15:10 |
| rvba | ;) | 15:10 |
| gmb | rvba: Done that already, smartypants :P | 15:10 |
| rvba | haha, cool. | 15:10 |
| gmb | rvba: https://code.launchpad.net/~gmb/maas/fix-netboot_off/+merge/235659 | 15:20 |
| gmb | svp | 15:20 |
| rvba | gmb: approved | 15:23 |
| gmb | Ta | 15:24 |
| rvba | gmb: Please don't forget to do the QA for this when your change goes through the CI. | 15:32 |
| gmb | rvba: Of course. | 15:32 |
| rvba | Cool, ta. | 15:33 |
| gmb | rvba: I need to step AFK for a while, but I will QA my change this afternoon. | 15:39 |
| smoser | anyone have a pointer .. | 16:04 |
| smoser | i'm wondering how i'd go about adding my own "operating system" to maas. to install. | 16:04 |
| roadmr | smoser: best way I've found is to create a fastpath-installable tar.gz (only done it with Ubuntu derivatives so it's easy to get this) and replace the root-tgz in /var/lib/maas/boot-resources for the default release | 16:06 |
| smoser | roadmr, right. but i think there is a more supported path for that. | 16:07 |
| smoser | blake_r, maybe ?^ or roaksoax ^? | 16:07 |
| roadmr | smoser: bladernr_ worked on publishing his custom root.tar.gz using simplestreams, not sure how far he was able to go | 16:08 |
| smoser | well, that should be reasonably simple. | 16:08 |
| smoser | i'm interested in non-ubuntu. | 16:08 |
| bladernr_ | smoser: AIUI 1.7 has a mechanism for introducing a new image to MAAS but doesn't work all the way | 16:08 |
| smoser | thats what i was hoping to get at. | 16:09 |
| bladernr_ | I've been doing as roadmr mentions for now, just hijacking an existing one. blake_r should have a good idea though | 16:09 |
| roadmr | smoser: yes, that's ^^ the third alternative. maas maas boot-resources create will let you upload a custom .tgz but then it can't yet be selected for deployment into a node. Work in progress :) | 16:09 |
| bladernr_ | as for simplestreams, I have a sample stream built (for now, another hijack) but got hung up on image signatures.... I know nothing about creating/using keyrings and image signing | 16:11 |
| bladernr_ | and won't be able to return to it until next week some time. | 16:11 |
| smoser | bladernr_, well, you dont actually have to sign anything. | 16:16 |
| bladernr_ | that's what I thought, I think I just haven't completely hijacked the stream I duplicated. | 16:16 |
| smoser | its not hard to sign... simplstreams has a tool to sign it all, you just have to tell it what key to use. | 16:16 |
| smoser | but when you tell maas about the stream. you need to point it at streams/v1/index.json | 16:16 |
| smoser | if you leave that part off, then it will assume the path is streams/v1/index.sjson | 16:17 |
| smoser | and will then expect signed data. | 16:17 |
| smoser | i can help you get your stuff signed if you want though. | 16:17 |
| bladernr_ | hrmmm... ok. that may be where I messed up then because it was complaining about the ubuntu-cloud keyring when I tried an import... | 16:17 |
| bladernr_ | so maybe I was pointed to the wrong json file | 16:17 |
| smoser | i dont know. feel free to ping me if you need to . | 16:18 |
| smoser | my goal is to get maas to point at a stream that says things like: | 16:18 |
| bladernr_ | I'll bug you about it next week, I've got to get my maas server running for an OCP demo on Thursday | 16:18 |
| smoser | operating-system: smosOS | 16:18 |
| smoser | version: 2014 | 16:18 |
| smoser | and then install that. | 16:18 |
| smoser | you down with ocp ? | 16:19 |
| bladernr_ | yeah, you know me | 16:19 |
| bladernr_ | early 90's flashbacks | 16:19 |
| === roadmr is now known as roadmr_afk | ||
| === kickinz1 is now known as kickinz1|afk | ||
| blake_r | smoser: sorry you cannot select a custom os yet, I hoep to get that fixed today | 17:49 |
| blake_r | smoser: so comming soon | 17:49 |
| smoser | but is there some sort of doc on that. | 17:50 |
| blake_r | smoser: about what? how to select it? its not enabled yet | 17:50 |
| smoser | ok. | 17:52 |
| === roadmr_afk is now known as roadmr | ||
| === roadmr is now known as roadmr_afk | ||
| === jfarschman is now known as MilesDenver | ||
| === roadmr_afk is now known as roadmr | ||
| smoser | blake_r, https://code.launchpad.net/~blake-rouse/maas/move-curtin-reporter-to-preseed/+merge/235716 | 21:31 |
| smoser | wrt to that, remember / knwo that curtin can take multiple configs | 21:32 |
| smoser | if there is no sense in exposing that in the template, then you dont have to | 21:32 |
| smoser | just give curtin another config | 21:32 |
| blake_r | smoser: yeah that is what i am doing, removing it from the template | 21:32 |
| blake_r | smoser: so its always there no matter the template | 21:33 |
| smoser | oh yeah. i see that :) | 21:33 |
| smoser | good job. | 21:33 |
| smoser | i thought from the comment that you ewre just putting that snippet into a variable | 21:34 |
| smoser | and then having the template render the whole variable | 21:34 |
| blake_r | no that is how it was | 21:34 |
| blake_r | smoser: also have a branch up for selecting custom images, so once that lands you can use that feature | 21:34 |
| blake_r | roadmr: ^ | 21:34 |
| smoser | and i can somehow define smosOS ? | 21:35 |
| smoser | because lots of people want to run smosOS. | 21:35 |
| roadmr | blake_r: \o/ awesome!!! | 21:35 |
| smoser | ok. i have to run. later. | 21:35 |
| * roadmr looks forward to stop using the root-tgz substitution hack :D | 21:35 | |
| blake_r | smoser: later | 21:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!