=== cargonza_ is now known as cargonza [06:33] where can I find installation log when maas fail to boot vm? [07:08] (refer to the installation log for more information), where can I find this installation log? === frankban|afk is now known as frankban [07:22] who is andres rodriguez? which nickname does he have? [08:14] My MaaS controller is only listening to IPv6 on port 5240 [08:15] Any clues on where could I check? [08:31] Anyone has some idea about how to find out why the API endpoint is not listening on IPv4? [08:34] BjornT ? [09:35] Bug #1702649 opened: MAAS should assess PostGRES configuration [09:44] Bug #1702649 changed: MAAS should assess PostGRES configuration [09:53] Bug #1702649 opened: MAAS should assess PostGRES configuration [11:29] Bug #1702669 opened: Index on maasserver_routable_pairs would improve performance [11:29] Bug #1702671 opened: Potentially duplicated presence updates [11:32] Bug #1702669 changed: Index on maasserver_routable_pairs would improve performance [11:32] Bug #1702671 changed: Potentially duplicated presence updates [11:35] Bug #1702669 opened: Index on maasserver_routable_pairs would improve performance [11:35] Bug #1702671 opened: Potentially duplicated presence updates [12:12] hi [12:35] hello [12:59] Hi there! I am trying to connect to my MaaS server with juju, but I'm not sure if I am using the right API endpoint url [13:00] it complains that "Can't validate endpoint: No MAAS server running at http://$ip/MAAS/api/2.0/" [13:01] I also tried with http://$ip:5240/MAAS but the controller is not listening on that port for IPv4 [13:04] I can log in with the CLI with the same (1st) URL on the controller [13:05] Bug #1702560 changed: faild deploy windows 2012r2, but boot stay ok [13:08] Bug #1702560 opened: faild deploy windows 2012r2, but boot stay ok [13:17] Bug #1702560 changed: faild deploy windows 2012r2, but boot stay ok [13:18] Is there any way to template the names based on another field value? [13:30] hi gimmic [13:31] you mean, something else than those "{prefix}_{osystem}_{node_arch}_{node_subarch}_{release}_{node_name}" ? [13:33] Yeah, I'd like to use an octet from the ipmi interface as those are statically assigned. I could also use the ipmi hostname set/advertised via dns [13:33] or if there's a good way to rename hosts via cli or api, I suppose [13:36] I have no idea... but it sounds like it shouldn't be too difficult, let me check [13:46] first step: new_hostname=$(maas maas nodes read hostname=casual-mite |grep mac_address | tail -1 | awk -F'"' '{print $4}') [13:53] uff... it sounds like a very basic thing to do, but on a first sight, I haven't found any options to change the names! [13:57] heh [13:58] It's mostly an ease-of-identification thing. I have 12 racks of nodes to identify [13:58] as bare metal, the only real unique IDs that come easily would be the static-set ipmi interfaces [13:59] I could use service tags too, but that's fairly 'random' [13:59] actually, it seems that the maas CLI doesn't really let you change anything. Just start, stop and delete stuff [13:59] :( Probably have to be an api call then [13:59] CLI would be easier for bash hackery [13:59] definitely [14:05] Bug #1702062 changed: Incompatibilities with Django 1.11

[14:05] Bug #1702690 opened: [2.2] Commissioning a machine prefers minimum kernel over commissioning global [14:14] hello there out using maas [14:14] I've a question regarding maas and ipmi [14:15] dell servers are delivered with deactivated ipmi-over-lan [14:16] i found out that within the installed server I can toggel the ipmi-ove-lan via ipmitool: "sudo ipmitool lan set 1 access on" [14:20] Is it possible to implement this into the automatic discovery? [14:30] that would need to be a customizable option as it is potentially destructive [14:30] couldn't you just do it in a script to turn 'em on? [14:32] hmmm. Where do I have to provide this script? I've no idea where to look :-( [14:32] Is there any way to template my storage configuration? [14:33] @gimmic: Yes, via maas cli [14:34] I do my own storage configuration (partitioning, raid, lvm, etc.) via maas cli [14:35] nice. Do you have an example of raid? [14:36] one minute please ... [14:36] mwe11, feel like sharing those scripts? maybe we can include some samples in the official docs [14:36] mwell: is there any updated guide on how to use the CLI for editing the preseeds? [14:36] julen, not yet [14:38] pmatulis: could you give me some clues on how to get started on learning how to customize them? [14:38] I have seen that curtin stuff, and I am trying to understand it [14:38] julen, i haven't started myself unfortunately [14:39] julen, right now the old 1.9 docs are all i know of [14:39] in a similar boat here as I want to automate dd mangling the disks in the nodes on commission. Curtin is failing due to conflicting lvm vg groups [14:39] (or on deployment_ [14:40] gimmic: have does it also fail while commissioning? [14:40] I don't believe so [14:41] I had similar problems today, and I found out that if I release and commission again, it works somehow [14:41] That was my 'fix' in 1.9 [14:41] doesn't seem to work in 2.2 [14:41] I will try it again though just to see if it can save me some time [14:43] but then, there is no chance of finding one of those "cheetah" templates (like in cobbler), where one can just edit stuff with "old-school" syntax, right? [14:46] I'd be trying to figure out how to get xenial/hwe images on my system - they weren't there by default, and the instructions in the doc gave me an error (https://docs.ubuntu.com/maas/2.1/en/manage-cli-images) [14:47] by digging through simplestream json on maas.io, i figured out that it only works w/ the v3 simplestream. switched to that as a custom stream, and things are working now [14:47] @julen: Yes, feel free to include it. [14:47] # list all machines in state 'ready' [14:47] maas ${PROFILE} machines read | jq '.[] | select(.status_name=="Ready") | {hostname: .hostname, system_id: .system_id, status: .status, in: [.interface_set[].name]|sort }' --compact-output [14:47] ## set variables [14:47] HOST_ID= # eg. dfgwn8 [14:48] i'm not sure why i'm on v2 - docs say v3 are the default. is that an upgrade issue? [14:48] @yulien: sorry I've been logged out due too message flooding :-) [14:49] Dis you got any of my automated server configuration scripts? [14:50] mwell: this one? [14:50] maas ${PROFILE} machines read | jq '.[] | select(.status_name=="Ready") | {hostname: .hostname, system_id: .system_id, status: .status, in: [.interface_set[].name]|sort }' --compact-output [14:51] dannf, you need to change to v3, yes [14:52] dannf, where you using the default boot/image source pre-2.1 ? [14:52] pmatulis: ok. obviously that'd be good to clarify in the docs (i can send a patch for that), but the "dirty" part about that is that i'm now in "custom image mode" [14:52] *were [14:53] the docs do say v3 is the default, and that should be good - but the section about adding hwe options doesn't show the dep on v3 explicitly [14:53] dannf, were you using the default boot/image source pre-2.1 ? [14:53] sfeole: that's correct, yes? [14:55] pmatulis: if this answers the quesiton, here's the dump of the boot-sources before i switched to v3: http://paste.ubuntu.com/25032562/ [14:55] and it was upgraded from a pre-2.1 [14:55] dannf, ok, that's why [14:57] dannf, this is the default for pre-2.1 AFAIU: https://images.maas.io/ephemeral-v2 [14:57] dannf, if you were using that, then the upgrade should have changed it to v3 [14:58] pmatulis: ok [14:58] https://docs.ubuntu.com/maas/2.1/en/release-notes [14:59] dannf, correct we were using the default boot/image source pre-2.1 [14:59] pmatulis: so, to make sure i understand - the issue is that our maas was not using the pre-v2.1 default? [15:00] dannf, that's my understanding, yes [15:01] dannf, what maas version was originally installed? [15:01] sfeole: ^ [15:01] pmatulis, bahh give me a sec [15:01] pmatulis: in case you haven't gathered, sfeole admins this maas :) [15:01] sounds like you also upgraded to 2.0 (from 1.9)? [15:02] pmatulis, that sounds likely, because this maas has been around for quite some time [15:02] dannf, got it ;) [15:02] sfeole, ok [15:02] @julen, @gimmic: http://paste.ubuntu.com/25032595/ [15:03] <3 [15:03] pmatulis, i have not reinstalled it simply due to the fact it's production and has a boatload of user accounts and hosts [15:03] nearly 200 lines, sorry [15:03] does it fit your needs? [15:03] sfeole, i understand [15:03] pmatulis, speaking of that, there is no way to "backup" the configured users and enlisted hosts , so that I could "restore" it to a new MAAS install. [15:03] pmatulis, that would be swell if so [15:04] mwell: thanks! :) [15:05] if you need an author you can take Marcus Wellnitz, University of giessen, germany ;-) [15:06] mwe11, did you mean the maas docs can include some of your scripting? [15:06] * pmatulis writes MAAS documentation [15:06] sfeole, i'm pretty sure there is a backup section in the docs [15:07] pmatulis, ack, will look it up, thx [15:07] i need to validate that again probably [15:07] @pmatulis: yes, you're welcome to include it if it's helpful [15:08] mwe11, alright thanks [15:08] sfeole, https://docs.ubuntu.com/maas/2.1/en/manage-backup [15:08] Bug #1702703 opened: Cannot run maas-regiond without /bin/maas-rack [15:10] maybe someone can answer my question: "Where do I have to add scripts to modify ipmi-settings via ipmitool?" [15:15] mwell: you mean, like change the management IP of the node? Or a settings template to avoid having to set the IPMI in all new servers? [15:16] julen, yes. in my simpel case this one: "ipmitool lan set 1 access on" [15:19] that sounds tricky... if I was in the same situation I would probably get around it with a simple shell script [15:21] well... I have been trying to ask the same question a lot of times, but I'll try again, now that there's a little more activity in here... [15:21] It's because of a default setting of dell servers: ipmi over LAN ist disabled by default. maas ist creating a user, reads the ip-configuraton and ... can't connect because it's disabled :-( [15:22] I am trying to connecto to my maas with juju, but the port 5240 of the controller is closed. I also tried with http://$ip/MAAS/api/2.0/ but it's also not working [15:23] mwell: but that sounds like a one time thing. It sounds like you can just run a shell script with a for loop, enable all the cards, and that's it [15:25] ... unless you are changing your hardware every day... [15:26] julen, you're right. I just want to implement an automatic activation of ipmi-over-lan when maas detects the host (at the first boot new -> ready) [15:27] mwell: wow! that sounds cool :) [15:28] correction: discovery -> new ( I hope that's the right naming :-)) [15:29] mwell: I am not very much into MaaS, and my solutions are usually quite twisted... but why not to include a custom script which does it or you while commissioning? [15:30] julen, just to ensure not to have a manual interaction while deploying a node. [15:30] you can access the IPMI interface of the host itself from within the host [15:30] commissioning is too late. It has to be included into the very first PxE-Boot maas-init process. [15:31] otherwise the node will be in error state because maas is unable to start it via ipmi-power-on [15:32] well: you are right... [15:32] what about turning them on with WOL? [15:34] Uff.. there's no WOL option anymore :S [15:34] my goal ist to unpack a server, mount it into the rack, do the cabeling stuff, adjust iDRAC (ipmi) via mini-display and just power on the server [15:35] No iDRAC-Webinterface to enable that anoying ipmi-over-lan :D [15:37] from my limited knowledge, the only twisted solution I could think about, would be to try to rebuild the ramdisk to do that thing for you. But it sounds really un-elegant [15:38] there's probably a way better way to handdle that with curtin, but I don't really understand it yet [15:39] I found some hints at [15:39] /usr/lib/python3/dist-packages/provisioningserver/templates/commissioning-user-data/snippets/maas_ipmi_autodetect_tool.py [15:39] /usr/lib/python3/dist-packages/provisioningserver/templates/commissioning-user-data/snippets/maas_moonshot_autodetect.py [15:39] /usr/lib/python3/dist-packages/provisioningserver/templates/commissioning-user-data/user_data.template [15:39] at my maas server [15:40] but templates sounds like templates :D [15:40] hmm.. but those probably just run while commissioning [15:41] mmm found something dirtier than dd: "wipefs -a /dev/sd* -f" [15:42] those should run on initializing. "#### IPMI setup ######" [15:43] commisioning is too late for my needs. [15:44] it's weird... I don't have that commissioning-user-data directory [15:45] power_type=$(maas-ipmi-autodetect-tool) [15:45] case "$power_type" in [15:45] ipmi) [15:45] power_settings=$(maas-ipmi-autodetect --configdir "$IPMI_CONFIG_D" ${pargs}) [15:45] -> looks like it runs at the very first boot (maybe within maas-init) [15:46] that's bash.. it should be easy to debug... [15:49] mwell? nobody is really answering my question, but you have a working maas... could you tell me if your port 5240 is visible from outside (with IPv4)? [15:50] I'll have a look [15:51] yes, it looks like [15:52] uf... then I have no clue of what is wrong [15:52] netstat -patn | grep 5240 [15:52] tcp6 0 0 :::5240 :::* LISTEN 2316/python3 [15:52] from the maas cli (on the controller) I use the url http://$ip/MAAS/api/2.0/ [15:52] bt it seems like iptables drops it [15:52] aha! ok.. that is IPv6 [15:53] I have the same. That means that the juju docu is wrong [15:54] now the problem is, why can I connect with the CLI from the controller, but not with juju from outside. But well... it probably just a firewall issue or something [15:54] iptables? [15:56] there is this new ufw thing [15:56] ufw status [15:57] inactive [15:57] mine too [15:58] but "iptables -L" shows rules [15:58] my iptables is empty [15:58] maas v2.2.0 right? [15:59] that means nothing is locked out [15:59] MAAS Version 2.1.5+bzr5596-0ubuntu1 (16.04.1) [16:00] maybe that's why I don't have that commissioning-user-data directory [16:01] :D [16:02] well.. the funny thing is, that I have a firefox open with the web interface, so why is juju saying that there's no maas server running in there? [16:02] firefox at port 5240? [16:02] maybe I am supposed to install juju on the maas controller too... [16:02] nope, 80 [16:03] the 5240 is closed for tcp4 [16:03] I had been told by canonical not to install maas and juju at the same machine [16:04] do you have juju too? [16:05] not yet. Just a VM at the maas server with the name "juju" :D [16:05] yeah.. the idea is, to keep the things separated, and to be able to deploy juju from anywhere. But how?? I can't connect [16:05] hehe :D [16:05] I installed juju on my workstation [16:06] at the end, it's not really a server. It's just the place from where you submit the tasks to maas [16:06] you can try the tool tcptraceroute [16:06] what you need a server for, is for the charm store thing [16:09] well.. the connection is ok. I tried tcptraceoute too, but well... I have the website open! I bet it is an stupid bug in juju or something [16:09] mwe11: I owe you a beer [16:09] mwe11: you just saved me so much time [16:10] :D You're welcome [16:10] that script needs to be put into the maas documentation stat [16:11] @gimmic: which script do you mean? [16:11] http://paste.ubuntu.com/25032595/ [16:11] I just used the parts i needed [16:12] @gimmic: @pmautils is currently checking if it fits his need ;-) [16:14] @gimmic; I developed it during the last 2 month whith 2 trainees [16:18] julen, which juju doc is wrong? [16:22] pmatulis: https://jujucharms.com/docs/2.1/whats-new [16:22] I am using 2.2.0 and assumed that the address what the same [16:22] https://192.168.122.143:5240/MAAS [16:23] I have no port 5240 listening on IPv4 [16:29] pmatulis: are you using juju 2.2 ? Which endpoint address do you use for maas? [16:33] possibly stupid question: Is there any way to see the api calls the webUI is making? [16:36] julen, odd, i thought maas always listens on port 5240 [16:37] not in my controller (v 2.2.0) and not in the one of mwell (v2.1.5) [16:38] there is also not so much documentation on how do the config files work [16:38] I thought about trying to write something myself, but I have no clue of how to get the info myself [16:39] ... besides reading the source code, which looks pretty complex... [16:40] I have been trying to make some patches on some bugs I found, but also have no clue of where to search [16:42] pmatulis: I am using mostly default settings, and my regiond.conf has "maas_url: http://192.168.122.139:5240/MAAS" [16:42] how could I debug this problem? [16:44] also, why is that maas_url on the port 5240, but I have nothing listening on the 5240? (It's just listening on IPv6) [16:46] @weekend for now! good luck everyone [16:46] julen, 5240 is for a python-based web server [16:47] bye mwell! thanks! :) [16:47] but why does the normal web interface listen on 80 then? and how come that the API communicates also with the 80? [16:48] 80 is redirected to 5240 [16:48] you prolly have apache running correct? [16:48] yes [16:48] bino. it's sole purpose is to redirect. not great i admit [16:48] *bingo [16:49] should I stop it? [16:49] not unless you will use 5240 directly [16:50] but how come that I use the address http://$ip/MAAS/ for the CLI? [16:52] I have tried all the combinations http://$ip + :5240/MAAS + /MAAS/api/2.0/ + /MAAS/ ... and none works [16:53] julen, fwiw, i *always* use http://$HOST:5240/MAAS/api/2.0 for the CLI [16:53] julen, some context: https://bugs.launchpad.net/maas/+bug/1643900 [16:57] pmatulis, I still don't understand. Then, both juju and maas documentation are kind o wrong... [16:58] julen, what you pointed to me before shows 5240. to me, that's correct. i don't understand why it doesn't work for you [16:59] the controller is simply not listening on that port... [17:00] julen, what maas version and did you install it freshly (not updated)? i would like to reproduce [17:00] 2.2.0~rc1 [17:01] on Xenial? [17:01] completely new [17:01] zesty [17:01] ok, and that's ppa:maas/stable right? [17:02] or is it in the archives, i think it is actually [17:02] for zesty [17:02] yes, it is [17:02] I think I didn't add any ppa [17:03] apt-cache policy maas says: http://archive.ubuntu.com/ubuntu zesty/main amd64 Packages [17:04] creating zesty instance now... [17:05] cool! :D [17:06] so, I just installed clean, and apt update && apt -y upgrade && apt -y dist-upgrade [17:07] then apt -y install maas maas-cli [17:09] maas package drags in maas-cli [17:09] i'm installing 'maas' now [17:18] $ nc -vz localhost 5240 [17:18] Connection to localhost 5240 port [tcp/*] succeeded [17:18] julen, ^^^ [17:18] :O ! [17:19] wait wait... [17:19] netstat -tulpen | grep 5240 [17:20] that also works for me! :P you are connecting via IPv6... [17:20] try to connect from somewhere else === frankban is now known as frankban|afk [17:22] nc -vz 10.55.60.29 5240 [17:22] Connection to 10.55.60.29 5240 port [tcp/*] succeeded!Y [17:22] ok... [17:23] wait.. it also worked for me! [17:23] so why is nmap not showing the port? [17:24] and why does netstat also not show that it is listening for IPv4? [17:24] dunno. it does seem to look ipv6 only. but works. i'm not using ipv6 [17:24] maybe there is some switcharoo happening [17:24] ok... final test... [17:24] i'm going to ask someone [17:25] try with juju add-cloud, maas and http://192.168.122.139:5240/MAAS [17:33] julen, i used localhost [17:34] you wanted the juju client to be remote i think [17:35] lemme create a second instance [17:35] pmatulis: yes [17:35] I have the controller on a machine and juju on the local one [17:36] julen, and why did you use that specific address? i will use my own address [17:36] that's the point with juju, right? to use it from anywhere and attach external resources to run the jobs [17:36] sure, the client can be anywhere [17:36] pmatulis: do you mean, http://192.168.122.139:5240/MAAS ? [17:37] yes [17:37] I saw it in the docu [17:37] well obviously you need to change that to fit your needs [17:37] https://jujucharms.com/docs/2.1/clouds-maas#registering-a-maas-cloud-with-juju [17:38] plus, it appears also on the /etc/maas/regiond.conf and rackd.conf [17:39] Bug #1408106 changed: attach_disconnected not sufficient for overlayfs

[17:39] julen, so you tried to use 192.168.122.139 over the network right? [17:40] I am too afraid to dive into the source code of the web API to try to find out the right syntax [17:40] yes [17:40] julen, that looks like an internal libvirt address. why are you using that address? i also don't see it on the doc you posted [17:42] well.. before I put the real maas into production I was testing the thing on a VM, but it shouldn't make any difference [17:42] julen, it will work on the localhost but not over the network [17:42] on the code block, it says: Enter the API endpoint url: http://maas.example.org:5240/MAAS [17:43] hmm... [17:43] julen, that subnet is used internally by libvirt [17:43] so, I cannot communicate with my maas server from outside? [17:44] sure... [17:44] julen, you would be better off putting a network bridge on that host and then linking the KVM guests (maas server) to that bridge [17:44] I have a maas controller running as a VM on my workstation and the nodes are also VMs [17:45] yep, they are all using the same internal subnet, so that works [17:45] the bridge will allow your libvirt guests to be contacted over the network [17:45] but, what difference does it make? [17:46] b/c, if i understand correctly, you have a juju client that is *not* on that subnet [17:46] you mean, get the VMs to the physical network... [17:46] yes it is [17:46] it is? [17:47] it is on the 192.168.122.1 [17:47] oh [17:47] the hypervisor [17:47] the juju client is the hypervisor? [17:47] this is why i can curl, ping, ... from the same terminal [17:47] yep [17:47] ok, that's fine [17:48] so it should work. my 2nd instance should be ready now [17:49] just one hint... we have a corporate http-proxy, but I already added no_proxy=http://my-proxy:8080 on that shell [17:49] julen, and where does it fail and what is the error [17:49] Can't validate endpoint: No MAAS server running at 192.168.122.139 [17:49] during the 'juju add-cloud' command right? [17:50] yes [17:50] juju add-cloud [17:50] > maas [17:50] > desktop [17:50] > http://192.168.122.139/MAAS [17:50] Can't validate endpoint: No MAAS server running at http://192.168.122.139/MAAS [17:51] Enter the API endpoint url: http://10.55.60.29:5240/MAAS [17:51] Cloud "maas-cloud" successfully added [17:52] so it's something on your network [17:52] firewall? [17:52] not between my and the VM... [17:52] also, on the same terminal: [17:52] nc -vz 192.168.122.139 5240 [17:52] Connection to 192.168.122.139 5240 port [tcp/*] succeeded! [17:53] so add port 5240 [17:53] sure.. same result [17:54] Enter the API endpoint url: http://192.168.122.139:5240/MAAS/ [17:54] ... waitwaitwait... [17:54] why? :) [17:54] well... I have done it about 10 times today. It returns... [17:55] Can't validate endpoint: No MAAS server running at http://192.168.122.139:5240/MAAS [17:55] (I was just waiting for the response... which takes a while) [17:56] yep. It just returned that [17:56] is there some hidden stuff with the http_proxy settings? [17:57]