| === Guest76746 is now known as med_ | ||
| === jac_ is now known as jac_cplane | ||
| mpontillo | jac_: is the 'vlan' package installed? any errors in the syslog or dmesg? | 03:32 |
|---|---|---|
| === jac_ is now known as jac_cplane | ||
| mup | Bug #1581727 changed: [2.0b5] Document that we need to configure postgres allows connections from external hosts <doc> <maasgh> <MAAS:Expired> <https://launchpad.net/bugs/1581727> | 04:21 |
| === admcleod_afk is now known as admcleod | ||
| cnf | has anyone configured their maas controller as a NAT gateway? | 09:58 |
| allenap | Hi. Does anyone know where or if the docs from the MAAS source are published these days? The docs at https://docs.ubuntu.com/maas/ are new, written by the docs team, and I have no complaints about them, but the from-source docs have a lot of other information in them, especially around how to develop MAAS itself. | 12:29 |
| pmatulis | hi allenap, we're working on making the Dev docs part of docs.u.c | 13:12 |
| allenap | pmatulis: Tip top, thanks. In the meantime are they available only via a checkout of the source? | 13:14 |
| Flint | Good afternoon/morning everyone! | 13:28 |
| === Flint is now known as Guest19663 | ||
| === Guest19663 is now known as Elm0 | ||
| Elm0 | ok, is there anyone here? | 13:29 |
| Elm0 | I need some help with Windows images if anyone already worked with. | 13:30 |
| cnf | not I | 13:33 |
| pmatulis | allenap, yep | 13:45 |
| allenap | Ta. | 13:46 |
| Elm0 | I mean, is a "classic" image build for windows (the way we build it on Openstack with packer) is suppose to work? | 13:55 |
| Elm0 | no one? | 14:04 |
| cnf | Elm0: it is PXE booted | 14:13 |
| cnf | i have no experience with pxe booting windows installers | 14:13 |
| mup | Bug #1685807 opened: MaaS does not discover storage devices on Lenovo System x3650 M5 <MAAS:New> <https://launchpad.net/bugs/1685807> | 14:19 |
| Elm0 | cnf: I want to build a windows Image to provide to maas, but I don't want to use cloudbase.it tool as I already have a working pipeline using packer which build Windows images for Openstack | 14:20 |
| cnf | Elm0: you want to live boot windows? not install it? | 14:21 |
| cnf | ie, it lives in ram? | 14:21 |
| mup | Bug #1685807 changed: MaaS does not discover storage devices on Lenovo System x3650 M5 <MAAS:New> <https://launchpad.net/bugs/1685807> | 14:22 |
| Elm0 | nop, I want like with any linux, maas to be used as the PXE images provider. | 14:22 |
| cnf | Elm0: "like with any linux", maas boots into an _installer_ | 14:22 |
| cnf | Elm0: which then installs a distribution to disk | 14:22 |
| Elm0 | cnf: yes, that is that kind of information that I need ^^ thx | 14:23 |
| cnf | np | 14:23 |
| cnf | i have no idea how to pxe boot a windows installer, though | 14:23 |
| Elm0 | using windows PE | 14:24 |
| Elm0 | with a unattend installer | 14:24 |
| Elm0 | file | 14:24 |
| mup | Bug #1685807 opened: MaaS does not discover storage devices on Lenovo System x3650 M5 <MAAS:New> <https://launchpad.net/bugs/1685807> | 14:25 |
| cnf | i'd like to figure out how to install ESXi with MaaS :P | 14:25 |
| Elm0 | cnf: Another question that's stuck running in my head is, how the maas µos is launching the install of a virtual HDD using the cloudbase.it tool which launch a VM then create and install a windows and then upload the resulting virtual HDD | 14:26 |
| Elm0 | cnf: me too ^^ I'll need to boot ESXi nodes at some point eventually :D | 14:26 |
| Elm0 | cnf: BOOM!! http://bazaar.launchpad.net/~maas-committers/maas/trunk/view/head:/src/provisioningserver/boot/windows.py | 14:28 |
| === bdx_ is now known as bdx | ||
| cnf | let me know if it works :P | 14:40 |
| Elm0 | cnf: I'm out from this week until the middle of may, so, I'll update you then. | 14:47 |
| vasey | hey folks, i'm getting a "did not find any datasource" error when my hosts complete PXE booting into ubuntu 16.04.2 LTS...any idea what the issue is? the hosts are successfully getting DHCP addresses and booting, but the cloud-init fails because of this datasource issue | 15:36 |
| Elm0 | vasey: I had this error if my rackd server is on a different subnet than my regiond. | 15:40 |
| vasey | elm0: hmmm, i've got everything on the same subnet for now, and i know everything can ping everything else | 15:46 |
| xygnal | mpontillo: was there a way to up log level in maas? I am not finding errors or tracebacks that indicate a problem. trying to get more information out of it. | 16:23 |
| mpontillo | xygnal: if there is a traceback, it will be in /var/log/maas inside regiond.log or rackd.log. what's the issue? | 16:24 |
| mup | Bug #1683542 opened: After configuing Ubuntu Core system still displays subiquity wizard <cloud-init:Won't Fix> <MAAS:Triaged> <https://launchpad.net/bugs/1683542> | 16:34 |
| mup | Bug #1685835 opened: MAAS doesn't ignore pre-composed node remote storage if InitiatorIQN is non-empty <MAAS:Triaged by newell-jensen> <MAAS RSD :Triaged by newell-jensen> <https://launchpad.net/bugs/1685835> | 16:34 |
| mup | Bug #1683542 changed: After configuing Ubuntu Core system still displays subiquity wizard <cloud-init:Won't Fix> <MAAS:Triaged> <https://launchpad.net/bugs/1683542> | 16:40 |
| mup | Bug #1685835 changed: MAAS doesn't ignore pre-composed node remote storage if InitiatorIQN is non-empty <MAAS:Triaged by newell-jensen> <MAAS RSD :Triaged by newell-jensen> <https://launchpad.net/bugs/1685835> | 16:40 |
| xygnal | mpontillo: yes we were talking about this last week. Comissions work, but deployments end up on temporary dhcp scope instead of auto-assign, and the UI goes to 'unmanaged'. | 16:48 |
| xygnal | mpontillo: I have plenty of tracebacks, 99% sure none of them will tell you anything | 16:49 |
| mup | Bug #1683542 opened: After configuing Ubuntu Core system still displays subiquity wizard <cloud-init:Won't Fix> <MAAS:Triaged> <https://launchpad.net/bugs/1683542> | 16:49 |
| mup | Bug #1685835 opened: MAAS doesn't ignore pre-composed node remote storage if InitiatorIQN is non-empty <MAAS:Triaged by newell-jensen> <MAAS RSD :Triaged by newell-jensen> <https://launchpad.net/bugs/1685835> | 16:49 |
| vasey | mpontillo: me again, since my hosts and MAAS are on the same subnet and can all ping each other, what do you think would cause my "could not find any datasource" error? | 16:50 |
| xander | exit | 17:06 |
| mpontillo | vasey: the first thing I always check is the MAAS URL; the MAAS region might report an IP address to the nodes that is off-subnet or otherwise unreachable. | 17:34 |
| mpontillo | vasey: https://gist.github.com/mpontillo/6ee4c96d8aed4d0efde66a37aa6d5af9 << I wrote this last week to test things out, if you run it on the MAAS region it will connect to localhost and show you the default URLs presented to machines | 17:34 |
| mpontillo | vasey: if you run it with a parameter, it will try to reach the MAAS server at that IP address/hostname. | 17:35 |
| vasey | mpontillo: thanks! i'll give that a shot | 17:35 |
| vasey | mpontillo: i'm getting a "(" unexpected error on line 5; doesn't look wrong to me though | 18:14 |
| mpontillo | vasey: curl https://gist.githubusercontent.com/mpontillo/6ee4c96d8aed4d0efde66a37aa6d5af9/raw/dbc72aca7f6f056c773f4dad146547576e61c06b/test-maas-enlistment.sh > test-enlistment && chmod +x test-enlistment | 18:16 |
| mpontillo | ^ that results in a working script for me | 18:16 |
| mpontillo | xygnal: right, so I think I figured out where it goes to unmanaged; what I don't know is why. you might be able to force a traceback by modifying the code in that location, to get us more info | 18:19 |
| mpontillo | xygnal: per https://bugs.launchpad.net/maas/+bug/1685306, if you were to edit /usr/lib/python3/dist-packages/maasserver/models/signals/interfaces.py and change the code (where it deletes all the links except DISCOVERED links) to do something like "raise ValueError()" on that line, that should provide a traceback that will at least tell us more about how we | 18:25 |
| mpontillo | got into that situation | 18:25 |
| vasey | mpontillo: for the "found metadata URL", it's pointing to an IP that i don't have set up; is that the trouble spot? | 18:26 |
| vasey | mpontillo: the cloud-config-url is correct | 18:26 |
| === cnfer is now known as cnf | ||
| mpontillo | vasey: that's usually the problem. I would run "sudo dpkg-reconfigure -plow maas-rack-controller" and make sure the URL configured on the rack is the one that you want to communicate with from the deployed nodes | 18:28 |
| mpontillo | vasey: the one subtle thing here is that MAAS may try to infer which URL to provide based on the source IP, so the most accurate way to run that script would be from a host on the same subnet as the MAAS rack | 18:29 |
| vasey | mpontillo: so i ran the dpkg-reconfigure, then retested the enlistment, and the correct IP/URL shows up everywhere until right after END GRUB CONFIG. then it shows a different IP that i did not set, and which doesn't represent a real system in my network | 18:34 |
| mpontillo | vasey: that's strange; what address is it showing? | 18:36 |
| vasey | mpontillo: it's showing 192.168.0.201, when it should be 192.168.0.100 | 18:36 |
| roaksoax | 14:26 < vasey> mpontillo: for the "found metadata URL", it's pointing to an IP that i don't have set up; is that the trouble spot? | 18:38 |
| mpontillo | vasey: can you pastebin the output for me? and the output of "sudo maas-rack support-dump --networking"? if it contains sensitive info you can email it to me or send me a PM to a secret gist on github | 18:38 |
| roaksoax | mpontillo: ^^ | 18:38 |
| roaksoax | cloud-init tries to contact other stuff | 18:38 |
| roaksoax | other ip addresses | 18:38 |
| roaksoax | if it cannot contact the metadata | 18:39 |
| roaksoax | that could be what's going on there | 18:39 |
| mpontillo | roaksoax: yeah but this is MAAS itself reporting a weird URL per my diagnostic script | 18:39 |
| mpontillo | roaksoax: I was thinking that too, just don't know why MAAS would report an incorrect IP at that point; that means it was found in the PXE config | 18:39 |
| roaksoax | mpontillo: that could be the case if rackd.conf points to localhost for maas url | 18:40 |
| mpontillo | roaksoax: yeah, that's why I said to check that first ;-) | 18:40 |
| vasey | mpontillo: https://pastebin.com/hHL8UJ5g here's the script output first | 18:41 |
| vasey | mpontillo: https://pastebin.com/a5z0KKRC and here's the networking output | 18:42 |
| roaksoax | vasey: pastebin /etc/maas/rackd.conf | 18:42 |
| mpontillo | vasey: I would check /etc/maas/regiond.conf and see if the .201 IP address is in there; if so, fix it and do "service maas-regiond restart" | 18:43 |
| vasey | roaksoax: https://pastebin.com/CjdVBiPw | 18:44 |
| mpontillo | vasey: is it possible that when MAAS was first set up the machine was using DHCP and had a different IP? | 18:44 |
| vasey | mpontillo: that's the one! :))) | 18:44 |
| roaksoax | vasey: restart maas-regiond && maas-rackd | 18:44 |
| roaksoax | that will fix it | 18:45 |
| vasey | mpontillo: and i think the system did originally have a DHCP-provided address, that makes a lot of sense | 18:48 |
| mup | Bug #1685891 opened: [2.2] Allow pod syncing to fail for pre-existing or manual composed machines bad physical storage. <MAAS:In Progress by blake-rouse> <MAAS RSD :In Progress by blake-rouse> <https://launchpad.net/bugs/1685891> | 19:07 |
| === bdx_ is now known as bdx | ||
| mup | Bug #1685904 opened: Remote Drive's CapacityGiB should be greater or equal to Master Drive's CapacityGiB <MAAS:Triaged by blake-rouse> <MAAS RSD :Triaged by blake-rouse> <https://launchpad.net/bugs/1685904> | 19:52 |
| mup | Bug # changed: 1376483, 1381129, 1433012, 1533822, 1555759, 1616417, 1635061, 1657471, 1661203, 1671517, 1672220, 1672735, 1674148, 1675915, 1675919, 1676167, 1676882, 1676962, 1677336, 1677933, 1677936, 1678323, 1679431, 1680277, 1680278, 1680876, 1681378, 1681379, 1681383, 1681386, 1681387, | 20:22 |
| mup | 1681389, 1681399, 1681757, 1681856, 1682099, 1682139, 1682152, 1682255, 1682290 | 20:22 |
| mup | Bug #1685952 opened: trusty with vlan reboot hang: ifup: waiting for lock on /run/network/ifstate.eth1 <MAAS:New> <https://launchpad.net/bugs/1685952> | 22:34 |
| mup | Bug #1685955 opened: RSD nodes don't power off after commissioning <MAAS:Triaged by newell-jensen> <MAAS RSD :Triaged by newell-jensen> <https://launchpad.net/bugs/1685955> | 23:10 |
| === zerick_ is now known as zerick | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!