| Derpmeister | Hi. I've got HTTPS working but I'm trying to get the MAAS web UI to work over HTTPS. Any pointers in enabling this? | 02:23 |
|---|---|---|
| Derpmeister | Note: the fact that there isn't much documentation on this is somewhat surprising. Lots of Squid docs in enabling this with regards to MAAS but surprisingly little on getting Apache to run with MAAS on HTTPS. | 02:27 |
| === frankban|afk is now known as frankban | ||
| filiplt | Hello. I very need help - total failure to deploy node (hp proliant dl360g9) - curtin fails to create partition: "An error occured handling 'sdg-part2': ProcessExecutionError - Unexpected error while running comman: ['sgdisk', '--new', '2:976896.0:15550463.0', '--typecode=2:8300', '/dev/sdh'] | 07:41 |
| filiplt | WTF? Asked for sdg-part2, and device is sgdisk is /dev/sdh ??? | 07:41 |
| mup | Bug #1680790 opened: [Device discovery - Enable/Disable toggle] The tooltip works as a button to interact with the toggle <ui> <MAAS:New> <https://launchpad.net/bugs/1680790> | 10:50 |
| mup | Bug #1680795 opened: [Device discovery] Move the tooltipinbetween the label and the toggle <ui> <MAAS:New> <https://launchpad.net/bugs/1680795> | 10:50 |
| mup | Bug #1680812 opened: [UX Improvement] Formally design the sticky table header as a pattern <MAAS:New> <https://launchpad.net/bugs/1680812> | 11:26 |
| mup | Bug #1680812 changed: [UX Improvement] Formally design the sticky table header as a pattern <MAAS:New> <https://launchpad.net/bugs/1680812> | 11:38 |
| mup | Bug #1680812 opened: [UX Improvement] Formally design the sticky table header as a pattern <MAAS:New> <https://launchpad.net/bugs/1680812> | 11:50 |
| mup | Bug #1680816 opened: [UX Improvement] The navigation bar should be sticky <ui> <MAAS:New> <https://launchpad.net/bugs/1680816> | 11:50 |
| mup | Bug #1680819 opened: [MAAS 2.2.0 (beta4) - Nodes] The tooltip on the machines tab goes off the screen <ui> <MAAS:New> <https://launchpad.net/bugs/1680819> | 12:14 |
| mup | Bug #1680856 opened: [MAAS 2.2(beta 4) - Nodes] When I select to view the machines by MAC address, the MAC address is not visible in the table and all the columns are shifted to the left <ui> <MAAS:New> <https://launchpad.net/bugs/1680856> | 13:47 |
| akossh | Hello | 13:50 |
| akossh | I have a problem using MAAS Version 2.2.0~rc1 | 13:50 |
| akossh | I always get timeout at commissioning script 99-maas-02-capture-lldp | 13:51 |
| akossh | 20 to 25 seconds after completing the previous script, this script gets a timeout | 13:52 |
| mup | Bug #1680856 changed: [MAAS 2.2(beta 4) - Nodes] When I select to view the machines by MAC address, the MAC address is not visible in the table and all the columns are shifted to the left <ui> <MAAS:New> <https://launchpad.net/bugs/1680856> | 13:53 |
| akossh | However the script waits until a file created by the LLDPD gets 60 seconds old, | 13:54 |
| akossh | which does never happen within 20 seconds | 13:54 |
| mup | Bug #1680859 opened: [2.2, UX] The tables should maintain the sorting information <MAAS:Incomplete> <https://launchpad.net/bugs/1680859> | 13:57 |
| pmatulis | akossh, fwiw, it works here | 14:05 |
| akossh | I have no idea why I'm getting a timeout | 14:06 |
| akossh | From the start of commissioning it takes less then 5 minutes, and I get a timeout | 14:07 |
| akossh | from the start of that script, it's like 20 to 25 sec | 14:08 |
| akossh | I do not know if it's a global timeout, or "per script" timeout | 14:08 |
| akossh | In older versions, there was a script called 99-maas-01-wait-for-lldpd which was run before the 99-maas-02-capture-lldp | 14:09 |
| akossh | But now that script is missing, and tha later one times out | 14:10 |
| pmatulis | akossh, checked logs? | 14:10 |
| akossh | I chacked the commissioning tab of the node | 14:10 |
| akossh | Wher do I find the logs to check? | 14:11 |
| akossh | https://pastebin.com/kcEAAs88 | 14:12 |
| akossh | This is what I see | 14:12 |
| pmatulis | i would start with /var/log/maas/rsyslog/<node>/<date>/messages | 14:14 |
| mup | Bug #1680859 changed: [2.2, UX] The tables should maintain the sorting information <MAAS:Incomplete> <https://launchpad.net/bugs/1680859> | 14:15 |
| mup | Bug #1680856 opened: [MAAS 2.2(beta 4) - Nodes] When I select to view the machines by MAC address, the MAC address is not visible in the table and all the columns are shifted to the left <ui> <MAAS:New> <https://launchpad.net/bugs/1680856> | 14:15 |
| pmatulis | akossh, (on the region API server) | 14:15 |
| akossh | This kind of messages dominate the log: Apr 7 13:51:08 micro18 ureadahead[574]: ureadahead:39/cmdline: Ignored relative path | 14:17 |
| mup | Bug #1680856 changed: [MAAS 2.2(beta 4) - Nodes] When I select to view the machines by MAC address, the MAC address is not visible in the table and all the columns are shifted to the left <ui> <MAAS:New> <https://launchpad.net/bugs/1680856> | 14:18 |
| mup | Bug #1680859 opened: [2.2, UX] The tables should maintain the sorting information <MAAS:Incomplete> <https://launchpad.net/bugs/1680859> | 14:18 |
| akossh | How can I downgrade to an older, working version? | 14:32 |
| akossh | Is it possible, or the update changed the DB? | 14:33 |
| pmatulis | downgrading maas isn't supported | 14:34 |
| akossh | :( | 14:35 |
| pmatulis | akossh, what kind of machine are you using for the failing node? | 14:36 |
| akossh | A supermicro blade | 14:37 |
| akossh | x86_64 | 14:38 |
| akossh | And I think, the only problem is that the timeout is too short | 14:38 |
| akossh | The other nodes were commissioned before updating maas, it worked good | 14:41 |
| pmatulis | interesting | 14:42 |
| akossh | the HW is the same | 14:43 |
| pmatulis | you're sure the same h/w worked in the previous version? | 14:43 |
| pmatulis | to be clear, what 2 versions are we talking about? | 14:44 |
| akossh | it was last year november | 14:44 |
| akossh | I think 2.0.0 beta something | 14:44 |
| pmatulis | possible to install a second environment with the earlier version and see if it works? | 14:46 |
| akossh | Now measured more precisely, from start to getting a timeout, takes 3 minutes 6 seconds | 14:46 |
| akossh | While I read about 20 minute commissioning timeout on google | 14:47 |
| akossh | pmatulis: no chance for a second environment right now | 14:47 |
| akossh | If I do not let the machine boot, it does not get a timeout after 3 minutes | 14:55 |
| akossh | So it's not a timeout counted from the start of commissioning | 14:56 |
| akossh | Interesting, when I delayed the boot, the script had only 1 second to run before getting timeout | 14:59 |
| pmatulis | akossh, consider filing a bug | 15:00 |
| akossh | pmatulis: i will consider it, thank you for the help so far | 15:09 |
| mup | Bug #1680876 opened: [2.2, UI] Cannot update storage tags over the UI <MAAS:New> <https://launchpad.net/bugs/1680876> | 15:09 |
| pmatulis | welcome | 15:15 |
| vogelc | pmatulis: Hey, hows it going. I have some questions on the DHCP Relay. | 15:16 |
| vogelc | pmatulis: When we configure it for an untagged vlan, the host is discovered and during commissioning it set the interfaces to unconfigured and the commissioning just stops. is that expected? | 15:17 |
| vogelc | pmatulis: when the interfaces get set to unconfigured it pulls an ip from the wrong subnet. | 15:18 |
| pmatulis | vogelc, otp, be back soon | 15:20 |
| mup | Bug #1680886 opened: [2.2] After aborting a deployment, the machine cannot be deployed via the CLI <MAAS:New> <https://launchpad.net/bugs/1680886> | 15:39 |
| mup | Bug #1680886 changed: [2.2] After aborting a deployment, the machine cannot be deployed via the CLI <MAAS:New> <https://launchpad.net/bugs/1680886> | 15:42 |
| mup | Bug #1680886 opened: [2.2] After aborting a deployment, the machine cannot be deployed via the CLI <MAAS:New> <https://launchpad.net/bugs/1680886> | 15:45 |
| pmatulis | vogelc, a node cannot commission if it's not connected to a network. did you do that? | 15:45 |
| vogelc | pmatulis: Let me take some screen shots and post it for you. that might help. | 15:50 |
| === Sagar is now known as Guest5285 | ||
| Guest5285 | hi | 17:11 |
| Guest5285 | does anyone know how to import custom kernel and initrd in MAAS 2.1.x? | 17:12 |
| kiko | Guest5285, AIUI that's only doable through providing your own simplestreams channel | 17:26 |
| mup | Bug #1680917 opened: Machine fails to boot if MAAS server is not available <MAAS:Incomplete> <https://launchpad.net/bugs/1680917> | 17:48 |
| Guest5285 | kiko: if I provision my own simplestreams then also I couldn't find any simple documentation steps. Do you know of anything? | 17:51 |
| Guest5285 | Any quick start on how these images can be pushed via simplestreams? | 17:56 |
| === frankban is now known as frankban|afk | ||
| mup | Bug #1680939 opened: [2.2rc1] When rack controller is down, machines power status shows 'green' <MAAS:New> <https://launchpad.net/bugs/1680939> | 19:21 |
| cmd_pancakes | so i have an issue with a server that is connected to an 84 disk array...when the array is connected, the host cannot mount the iscsi mount from the rack controller, eventually fails to a busybox shell and enlistment fails...when i turn off the array, everything works fine | 20:21 |
| roaksoax | cmd_pancakes: maybe duplicate iscsi initiator names ? | 21:06 |
| cmd_pancakes | roaksoax: could be! im setting up the hardware to test a known working config and bad config...i'll keep an eye on your suggestion | 21:08 |
| roaksoax | cmd_pancakes: maybe the hardware has a duplicate iscsi initiator same as maas' tgt | 21:10 |
| cmd_pancakes | i'm not super familiar with iscsi, are there iscsi commands in the enlistment image that i could test it out? i assume i could only really dig in once it fails to the busy box shell | 21:11 |
| cmd_pancakes | haha i could also just google for that :P | 21:12 |
| mup | Bug #1680979 opened: [2.2] Edited notifications reappear to users who have dismissed them and cannot be dismissed <MAAS:Triaged by allenap> <https://launchpad.net/bugs/1680979> | 22:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!