| === frankban|afk is now known as frankban | ||
| gimmic | pmatulis: I want to change an interface from dhcp to static | 14:43 |
|---|---|---|
| mup | Bug #1702919 opened: displayed lease IP information not updated when entering rescue mode <dhcp> <MAAS:Incomplete> <https://launchpad.net/bugs/1702919> | 15:07 |
| pmatulis | gimmic, yep, i've got something for you | 15:17 |
| pmatulis | gimmic, it's a bit indirect to change an interface's IP assignment | 15:18 |
| pmatulis | via the CLI | 15:18 |
| pmatulis | gimmic, still in the oven: https://git.io/vQobJ | 15:22 |
| pmatulis | scroll down to 'Change the IP assignment mode of a network interface' | 15:22 |
| gimmic | Ah, I got most of the way there yesterday. I didn't think to remove the existing one first | 15:23 |
| gimmic | When I was adding it manually, it was making it an alias on :1 | 15:23 |
| pmatulis | 'xactly | 15:24 |
| gimmic | Looks like that works. Might save me some clicking, thank you. | 15:29 |
| gimmic | I see hostname change there in the doc too :) | 15:29 |
| pmatulis | (welcome) | 15:29 |
| gimmic | How about where to hook some custom commissioning bits? Like If I just wanted to exec a command while the node was netbooted | 15:29 |
| gimmic | I assume commissioning would be the right place for that? Stuff I'm having to use rescue mode for right now | 15:30 |
| pmatulis | yeah, i haven't dived into that subject yet. i agree that it is important to have | 15:31 |
| gimmic | would be nice to have a simple place to define postexec stuff for the different stages, even | 15:31 |
| gimmic | "run this command" | 15:31 |
| gimmic | Right now curtin is failing due to an odd disk configuration issue with my nodes, I repopulated systems using existing disks from other 'donor systems', which still have LVM metadata on it | 15:32 |
| gimmic | when it tries to wipe the disk partitioning, LVM sees duplicate volgroups and errors out the process | 15:33 |
| gimmic | simplest way I've found to fix it so far is to use wipefs -a /dev/sd* -f | 15:33 |
| roaksoax | gimmic: please file a bug aginast 'curtin' and post the version of curtin-common running on the maas server | 16:11 |
| gimmic | Yeah. I'm also getting this after configuring raid on some hosts: | 16:29 |
| gimmic | /sys/class/block/dm-7 had no syspath (/sys/class/block/dm-7) | 16:29 |
| gimmic | curtin: Installation failed with exception: Unexpected error while running command. | 16:29 |
| gimmic | Command: ['curtin', 'block-meta', 'custom'] | 16:29 |
| julen | pmatulis: I found your bug report from last year, on the connection refused for the websocket with juju and maas, did you figure out some workaround? | 16:47 |
| vogelc | roaksoax: Question, once a client does a dhcp request and gets an IP tftp responds with the boot information, what protocol is used to pull down the boot images? | 16:48 |
| roaksoax | vogelc: pxe | 16:49 |
| roaksoax | vogelc: from there, you mean pxelinux or efi/grub | 16:49 |
| vogelc | roaksoax: I see booting under MAAS direction and then every thing just stops. do you know if its trying to use http to pull down the boot images? | 16:50 |
| gimmic | pxe boot should be TFTP transfer, afaik | 16:50 |
| roaksoax | vogelc: well it sounds like you are using legacy, so it should be booting pxelinux and getting the images from tftp | 16:51 |
| vogelc | Legacy? | 16:51 |
| roaksoax | vogelc: maybe it is not showing you console output because the right kernel params are not there ? | 16:51 |
| vogelc | I was thinking that too. | 16:51 |
| roaksoax | vogelc: what hardware are you using ? Is it configured to do Legacy boot or EFI ? | 16:51 |
| vogelc | Yes we are using BIOS, not UEFI | 16:52 |
| roaksoax | vogelc: ok, so the booting under maas direction should yield pxelinux downloading the kernel and initrd | 16:55 |
| vogelc | it does look like the kernel parms might have caused some conflicts. I was able to boot removing the global parameters. | 16:55 |
| roaksoax | vogelc: yee that could e too | 16:55 |
| roaksoax | vogelc: you could add per node kernel params too | 16:55 |
| vogelc | do you have a list of all the ports that need to be open on the firewall? | 16:56 |
| roaksoax | vogelc: from the machines to MAAS ? | 16:57 |
| vogelc | correct | 16:57 |
| roaksoax | vogelc: dns,dhcp,http on 5240,power management (ipmi). | 16:57 |
| roaksoax | that shoudl be it | 16:57 |
| vogelc | iscsi too | 16:57 |
| vogelc | thats where I am hung up now | 16:58 |
| roaksoax | that too, that will hopefully go away in 2.3 though | 16:58 |
| vogelc | once I get the ports opened I will let you know where we land. thanks for the help | 17:00 |
| julen | roaksoax: I think I found two little bugs in the code of maas, but I don't have time to make a patch are you interested? | 17:17 |
| roaksoax | julen: you should file bugs for them though | 17:18 |
| julen | yes.. I did.. but I just wanted to speed up the thing a little bit | 17:18 |
| roaksoax | julen: if they are already triaged, we will look at them when we get a change | 17:19 |
| roaksoax | atm we are focused on fixing other critical issues | 17:19 |
| pmatulis | julen, bug URL? | 17:19 |
| julen | https://bugs.launchpad.net/maas/+bug/1702332 | 17:20 |
| julen | the solution would be very simple, but it might require some discussion with other people | 17:20 |
| pmatulis | julen, i was expecting "my bug report from last year" | 17:21 |
| julen | it's basically dumping the http_proxy variables into /etc/environment or /etc/profile, probably within the file /usr/share/maas/maas-proxy-common.sh | 17:21 |
| julen | oh! I thought it was about what I asked to roaksoax :P | 17:22 |
| julen | https://bugs.launchpad.net/juju-core/+bug/1592179 | 17:22 |
| pmatulis | julen, no, i never found a way out | 17:23 |
| julen | I am really stuck at that point too, and that websocket thing seems to me like a real black box | 17:23 |
| julen | oh no! | 17:23 |
| pmatulis | no idea why it expired | 17:23 |
| julen | so, how does the people manage? | 17:24 |
| pmatulis | julen, if it's the same issue i propose: a) you comment in it that you just got bit by it b) send a mail to the juju mailing list about it | 17:25 |
| julen | the maas seems to work fine (after plenty of hacks) and the juju does bootstrap almost completely. It cannot be so difficult | 17:26 |
| pmatulis | julen, are you running a recent version of juju? | 17:26 |
| julen | I just started with the maas two days ago, and juju since yesterday. So... they should be recent | 17:27 |
| julen | juju 2.2.1 | 17:27 |
| pmatulis | julen, since you are so new to this stuff we value your insights. i recommend you also send a msg to the maas mailing list about why maas works only after plenty of hacks | 17:28 |
| pmatulis | just be positive :) | 17:28 |
| pmatulis | see irc channel topic for mailing list | 17:29 |
| julen | well... ok... | 17:29 |
| julen | I prefer forum format or Q&A type, but I'll subscribe for some time | 17:30 |
| === frankban is now known as frankban|afk | ||
| gimmic | I just realized after upgrading to 2.2 my nodes are now using .maas dns zone instead of my old configured one. How do I configure the default? | 17:45 |
| gimmic | having a hard time finding that | 17:45 |
| gimmic | I see how I can change them manually.. but with the number of nodes it's probably just easier to redeploy them unless I can mass-change them.. | 17:46 |
| gimmic | (Assuming I can change the default to my pre-existing zone) | 17:46 |
| gimmic | Would be nice if it was tied to Physical Zones | 17:48 |
| mup | Bug #1702976 opened: Cavium ThunderX nodes fail to auto-enlist <MAAS:New> <https://launchpad.net/bugs/1702976> | 17:58 |
| gimmic | 1.9 was pretty simple to set the DNS zone name, but I can't find it in 2.2? https://docs.ubuntu.com/maas/1.9/en/cluster-configuration | 17:59 |
| mup | Bug #1702976 changed: Cavium ThunderX nodes fail to auto-enlist <MAAS:New> <https://launchpad.net/bugs/1702976> | 18:04 |
| mup | Bug #1702976 opened: Cavium ThunderX nodes fail to auto-enlist <MAAS:New> <https://launchpad.net/bugs/1702976> | 18:16 |
| pmatulis | gimmic, sounds like something that should be reported as a bug | 18:18 |
| roaksoax | gimmic: 1.9 and 2.0 changed the way how DNS is managed | 18:33 |
| roaksoax | 1.9 used per rack, and 2.0 adds first class support for dns | 18:33 |
| roaksoax | gimmic: in 2.2 you have a tab that says 'DNS' | 18:33 |
| gimmic | All my 1.9 maas nodes had a default zone of 'example.net' and all my 2.2 nodes use '.maas'. I'd rather just change the default back to 'example.net' (and also change all existing deployed nodes to that dns zone) | 18:34 |
| gimmic | so I guess it's twofold: 1) I need to change my default maas dns zone 2) I need to bulk-change existing hosts' dns zone | 18:34 |
| gimmic | both dns zones are managed by maas | 18:34 |
| roaksoax | gimmic: so update the name of 'maas' to 'example.net' | 18:52 |
| roaksoax | gimmic: you can do that via the API | 18:52 |
| roaksoax | effectively, remove 'example.net', udpate 'maas' with 'example.net' | 19:01 |
| mup | Bug #1665057 opened: [UX] No Save button on fabric/vlan/subnets <accessibility> <canonical-bootstack> <ux> <MAAS:Fix Committed> <https://launchpad.net/bugs/1665057> | 19:16 |
| mup | Bug #1660819 changed: [2.1.3] webUI unusable during windows image create -- rackd gets disconnected <oil> <performance> <MAAS:Invalid> <https://launchpad.net/bugs/1660819> | 19:28 |
| mup | Bug #1660819 opened: [2.1.3] webUI unusable during windows image create -- rackd gets disconnected <oil> <performance> <MAAS:Invalid> <https://launchpad.net/bugs/1660819> | 19:37 |
| mup | Bug #1660819 changed: [2.1.3] webUI unusable during windows image create -- rackd gets disconnected <oil> <performance> <MAAS:Invalid> <https://launchpad.net/bugs/1660819> | 19:46 |
| catbus | roaksoax: Hi, does maas update the /etc/resolv.conf or run some tool which updates the /etc/resolve.conf in any event? I see in regiond.conf, [info] b'/etc/resolv.conf' changed, reparsing [info] Resolver added ('172.168.228.1', 53) to server list [info] Resolver added ('127.0.1.1', 53) to server list. | 21:15 |
| catbus | I have a node which looks to maas (172.168.228.1) for dns (/etc/resolv.conf in the node), but can't resolve names. I think in the /etc/resolv.conf on MAAS, it should have the external dns ip (8.8.8.8) and its ip (172.168.228.1) and 127.0.0.1, but it seems maas keeps updating the /etc/resolv.conf back. | 21:19 |
| catbus | I know manually editing the /etc/resolv.conf is not recommended, where can I find where maas finds these ip address for dns name servers to update the resolv.conf? | 21:20 |
| catbus | Resolver is running, is it because my friend used Network Manager to configure network interfaces? | 21:21 |
| roaksoax | catbus: maas doesn't update that | 21:28 |
| roaksoax | catbus: you probably have network manager that updates that | 21:28 |
| catbus | ok. | 21:29 |
| exodusftw | anybody been able to successfully configure raid1 over the MaaS API? or have some examples of that | 21:29 |
| exodusftw | I can get the raid device to create - but i'm having issues getting a filesystem setup on the device | 21:30 |
| exodusftw | it would appear that when I add 2 unformatted block devices to a raid 1 device, the sda device always registers in the raid device as a partition named sda-part1 - and i'm not able to add a filesystem to that partition without it removing itself from the raid device | 21:30 |
| mup | Bug #1703035 opened: MAAS should warn on version skew between controllers <MAAS:Triaged> <https://launchpad.net/bugs/1703035> | 21:37 |
| exodusftw | nevermind - I was able to figure it out...just had to do some magic | 22:38 |
| catbus | exodusftw: is that something maas.io documentation can improve on? | 22:46 |
| exodusftw | it certainly couldn't hurt | 22:47 |
| exodusftw | for example - on node creation - the current 2.0 /devices/ doc doesn't event show power_parameters as a valid key on node creation - but it certainly works | 22:49 |
| exodusftw | granted, I can sympathize with how difficult it is to keep up documentation across an active code base | 22:50 |
| pmatulis | exodusftw, what 'devices doc'? | 22:59 |
| mup | Bug #1702329 changed: Set NTP server for 'timesyncd' <ntp> <MAAS:Incomplete> <https://launchpad.net/bugs/1702329> | 23:10 |
| roaksoax | exodusftw: devices dont have power parameters | 23:22 |
| roaksoax | exodusftw: and yes, it is a PITA to keep documentation when there's so much movement | 23:22 |
| roaksoax | exodusftw: pmatulis should know :) | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!