[06:33] <digv> where can I find installation log when maas fail to boot vm?
[07:08] <digv> (refer to the installation log for more information), where can I find this installation log?
[07:22] <ybaumy> who is andres rodriguez? which nickname does he have?
[08:14] <julen> My MaaS controller is only listening to IPv6 on port 5240
[08:15] <julen> Any clues on where could I check?
[08:31] <julen> Anyone has some idea about how to find out why the API endpoint is not listening on IPv4?
[08:34] <julen> BjornT ?
[09:35] <mup> Bug #1702649 opened: MAAS should assess PostGRES configuration <MAAS:New> <https://launchpad.net/bugs/1702649>
[09:44] <mup> Bug #1702649 changed: MAAS should assess PostGRES configuration <MAAS:New> <https://launchpad.net/bugs/1702649>
[09:53] <mup> Bug #1702649 opened: MAAS should assess PostGRES configuration <MAAS:New> <https://launchpad.net/bugs/1702649>
[11:29] <mup> Bug #1702669 opened: Index on maasserver_routable_pairs would improve performance  <MAAS:New> <https://launchpad.net/bugs/1702669>
[11:29] <mup> Bug #1702671 opened: Potentially duplicated presence updates <MAAS:New> <https://launchpad.net/bugs/1702671>
[11:32] <mup> Bug #1702669 changed: Index on maasserver_routable_pairs would improve performance  <MAAS:New> <https://launchpad.net/bugs/1702669>
[11:32] <mup> Bug #1702671 changed: Potentially duplicated presence updates <MAAS:New> <https://launchpad.net/bugs/1702671>
[11:35] <mup> Bug #1702669 opened: Index on maasserver_routable_pairs would improve performance  <MAAS:New> <https://launchpad.net/bugs/1702669>
[11:35] <mup> Bug #1702671 opened: Potentially duplicated presence updates <MAAS:New> <https://launchpad.net/bugs/1702671>
[12:12] <vignesan> hi
[12:35] <vignesan> hello
[12:59] <julen> 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] <julen> it complains that "Can't validate endpoint: No MAAS server running at http://$ip/MAAS/api/2.0/"
[13:01] <julen> I also tried with http://$ip:5240/MAAS but the controller is not listening on that port for IPv4
[13:04] <julen> I can log in with the CLI with the same (1st) URL on the controller
[13:05] <mup> Bug #1702560 changed: faild deploy windows 2012r2, but  boot stay ok <curtin:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1702560>
[13:08] <mup> Bug #1702560 opened: faild deploy windows 2012r2, but  boot stay ok <curtin:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1702560>
[13:17] <mup> Bug #1702560 changed: faild deploy windows 2012r2, but  boot stay ok <curtin:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1702560>
[13:18] <gimmic> Is there any way to template the names based on another field value?
[13:30] <julen> hi gimmic
[13:31] <julen> you mean, something else than those "{prefix}_{osystem}_{node_arch}_{node_subarch}_{release}_{node_name}" ?
[13:33] <gimmic> 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] <gimmic> or if there's a good way to rename hosts via cli or api, I suppose
[13:36] <julen> I have no idea... but it sounds like it shouldn't be too difficult, let me check
[13:46] <julen> first step:  new_hostname=$(maas maas nodes read hostname=casual-mite |grep mac_address | tail -1 | awk -F'"'  '{print $4}')
[13:53] <julen> 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] <gimmic> heh
[13:58] <gimmic> It's mostly an ease-of-identification thing. I have 12 racks of nodes to identify
[13:58] <gimmic> as bare metal, the only real unique IDs that come easily would be the static-set ipmi interfaces
[13:59] <gimmic> I could use service tags too, but that's fairly 'random'
[13:59] <julen> actually, it seems that the maas CLI doesn't really let you change anything. Just start, stop and delete stuff
[13:59] <gimmic> :( Probably have to be an api call then
[13:59] <gimmic> CLI would be easier for bash hackery
[13:59] <julen> definitely
[14:05] <mup> Bug #1702062 changed: Incompatibilities with Django 1.11 <patch> <django-piston3 (Ubuntu):Fix Released by andreserl> <maas (Ubuntu):Fix Released> <https://launchpad.net/bugs/1702062>
[14:05] <mup> Bug #1702690 opened: [2.2] Commissioning a machine prefers minimum kernel over commissioning global <MAAS:Triaged> <MAAS 2.2:Triaged> <https://launchpad.net/bugs/1702690>
[14:14] <mwe11> hello there out using maas
[14:14] <mwe11> I've a question regarding maas and ipmi
[14:15] <mwe11> dell servers are delivered with deactivated ipmi-over-lan
[14:16] <mwe11> 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] <mwe11> Is it possible to implement this into the automatic discovery?
[14:30] <gimmic> that would need to be a customizable option as it is potentially destructive
[14:30] <gimmic> couldn't you just do it in a script to turn 'em on?
[14:32] <mwe11> hmmm. Where do I have to provide this script? I've no idea where to look :-(
[14:32] <gimmic> Is there any way to template my storage configuration?
[14:33] <mwe11> @gimmic: Yes, via maas cli
[14:34] <mwe11> I do my own storage configuration (partitioning, raid, lvm, etc.) via maas cli
[14:35] <gimmic> nice. Do you have an example of raid?
[14:36] <mwe11> one minute please ...
[14:36] <pmatulis> mwe11, feel like sharing those scripts? maybe we can include some samples in the official docs
[14:36] <julen> mwell: is there any updated guide on how to use the CLI for editing the preseeds?
[14:36] <pmatulis> julen, not yet
[14:38] <julen> pmatulis: could you give me some clues on how to get started on learning how to customize them?
[14:38] <julen> I have seen that curtin stuff, and I am trying to understand it
[14:38] <pmatulis> julen, i haven't started myself unfortunately
[14:39] <pmatulis> julen, right now the old 1.9 docs are all i know of
[14:39] <gimmic> 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] <gimmic> (or on deployment_
[14:40] <julen> gimmic: have does it also fail while commissioning?
[14:40] <gimmic> I don't believe so
[14:41] <julen> I had similar problems today, and I found out that if I release and commission again, it works somehow
[14:41] <gimmic> That was my 'fix' in 1.9
[14:41] <gimmic> doesn't seem to work in 2.2
[14:41] <gimmic> I will try it again though just to see if it can save me some time
[14:43] <julen> 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] <dannf> 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] <dannf> 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] <mwe11> @julen: Yes, feel free to include it.
[14:47] <mwe11> # list all machines in state 'ready'
[14:47] <mwe11>  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] <mwe11> ## set variables
[14:47] <mwe11> HOST_ID=               # eg. dfgwn8
[14:48] <dannf> i'm not sure why i'm on v2 - docs say v3 are the default. is that an upgrade issue?
[14:48] <mwe11> @yulien: sorry I've been logged out due too message flooding :-)
[14:49] <mwe11> Dis you got any of my automated server configuration scripts?
[14:50] <julen> mwell: this one?
[14:50] <julen> 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] <pmatulis> dannf, you need to change to v3, yes
[14:52] <pmatulis> dannf, where you using the default boot/image source pre-2.1 ?
[14:52] <dannf> 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] <pmatulis> *were
[14:53] <dannf> 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] <pmatulis> dannf, were you using the default boot/image source pre-2.1 ?
[14:53] <dannf> sfeole: that's correct, yes?
[14:55] <dannf> 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] <dannf> and it was upgraded from a pre-2.1
[14:55] <pmatulis> dannf, ok, that's why
[14:57] <pmatulis> dannf, this is the default for pre-2.1 AFAIU: https://images.maas.io/ephemeral-v2
[14:57] <pmatulis> dannf, if you were using that, then the upgrade should have changed it to v3
[14:58] <dannf> pmatulis: ok
[14:58] <pmatulis> https://docs.ubuntu.com/maas/2.1/en/release-notes
[14:59] <sfeole> dannf, correct we were using the default boot/image source pre-2.1
[14:59] <dannf> pmatulis: so, to make sure i understand - the issue is that our maas was not using the pre-v2.1 default?
[15:00] <pmatulis> dannf, that's my understanding, yes
[15:01] <pmatulis> dannf, what maas version was originally installed?
[15:01] <dannf> sfeole: ^
[15:01] <sfeole> pmatulis, bahh give me a sec
[15:01] <dannf> pmatulis: in case you haven't gathered, sfeole admins this maas :)
[15:01] <pmatulis> sounds like you also upgraded to 2.0 (from 1.9)?
[15:02] <sfeole> pmatulis, that sounds likely, because this maas has been around for quite some time
[15:02] <pmatulis> dannf, got it ;)
[15:02] <pmatulis> sfeole, ok
[15:02] <mwe11> @julen, @gimmic:  http://paste.ubuntu.com/25032595/
[15:03] <gimmic> <3
[15:03] <sfeole> 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] <mwe11> nearly 200 lines, sorry
[15:03] <mwe11> does it fit your needs?
[15:03] <pmatulis> sfeole, i understand
[15:03] <sfeole> 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] <sfeole> pmatulis, that would be swell if so
[15:04] <julen> mwell: thanks! :)
[15:05] <mwe11> if you need an author you can take Marcus Wellnitz, University of giessen, germany ;-)
[15:06] <pmatulis> mwe11, did you mean the maas docs can include some of your scripting?
[15:06]  * pmatulis writes MAAS documentation
[15:06] <pmatulis> sfeole, i'm pretty sure there is a backup section in the docs
[15:07] <sfeole> pmatulis, ack, will look it up, thx
[15:07] <pmatulis> i need to validate that again probably
[15:07] <mwe11> @pmatulis: yes, you're welcome to include it if it's helpful
[15:08] <pmatulis> mwe11, alright thanks
[15:08] <pmatulis> sfeole, https://docs.ubuntu.com/maas/2.1/en/manage-backup
[15:08] <mup> Bug #1702703 opened: Cannot run maas-regiond without /bin/maas-rack <MAAS:Triaged> <https://launchpad.net/bugs/1702703>
[15:10] <mwe11> maybe someone can answer my question: "Where do I have to add scripts to modify ipmi-settings via ipmitool?"
[15:15] <julen> 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] <mwe11> julen, yes. in my simpel case this one: "ipmitool lan set 1 access on"
[15:19] <julen> that sounds tricky... if I was in the same situation I would probably get around it with a simple shell script
[15:21] <julen> 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] <mwe11> 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] <julen> 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] <julen> 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] <julen> ... unless you are changing your hardware every day...
[15:26] <mwe11> 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] <julen> mwell: wow! that sounds cool :)
[15:28] <mwe11> correction: discovery -> new ( I hope that's the right naming :-))
[15:29] <julen> 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] <mwe11> julen, just to ensure not to have a manual interaction while deploying a node.
[15:30] <julen> you can access the IPMI interface of the host itself from within the host
[15:30] <mwe11> commissioning is too late. It has to be included into the very first PxE-Boot maas-init process.
[15:31] <mwe11> otherwise the node will be in error state because maas is unable to start it via ipmi-power-on
[15:32] <julen> well: you are right...
[15:32] <julen> what about turning them on with WOL?
[15:34] <julen> Uff.. there's no WOL option anymore :S
[15:34] <mwe11> 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] <mwe11> No iDRAC-Webinterface to enable that anoying ipmi-over-lan :D
[15:37] <julen> 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] <julen> there's probably a way better way to handdle that with curtin, but I don't really understand it yet
[15:39] <mwe11> I found some hints at
[15:39] <mwe11> /usr/lib/python3/dist-packages/provisioningserver/templates/commissioning-user-data/snippets/maas_ipmi_autodetect_tool.py
[15:39] <mwe11> /usr/lib/python3/dist-packages/provisioningserver/templates/commissioning-user-data/snippets/maas_moonshot_autodetect.py
[15:39] <mwe11> /usr/lib/python3/dist-packages/provisioningserver/templates/commissioning-user-data/user_data.template
[15:39] <mwe11> at my maas server
[15:40] <mwe11> but templates sounds like templates :D
[15:40] <julen> hmm.. but those probably just run while commissioning
[15:41] <gimmic> mmm found something dirtier than dd: "wipefs -a /dev/sd* -f"
[15:42] <mwe11> those should run on initializing. "####  IPMI setup  ######"
[15:43] <mwe11> commisioning is too late for my needs.
[15:44] <julen> it's weird... I don't have that commissioning-user-data directory
[15:45] <mwe11>    power_type=$(maas-ipmi-autodetect-tool)
[15:45] <mwe11>    case "$power_type" in
[15:45] <mwe11>        ipmi)
[15:45] <mwe11>            power_settings=$(maas-ipmi-autodetect --configdir "$IPMI_CONFIG_D" ${pargs})
[15:45] <mwe11> -> looks like it runs at the very first boot (maybe within maas-init)
[15:46] <julen> that's bash.. it should be easy to debug...
[15:49] <julen> 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] <mwe11> I'll have a look
[15:51] <mwe11> yes, it looks like
[15:52] <julen> uf... then I have no clue of what is wrong
[15:52] <mwe11> netstat -patn | grep 5240
[15:52] <mwe11> tcp6       0      0 :::5240                 :::*                    LISTEN      2316/python3
[15:52] <julen> from the maas cli (on the controller) I use the url http://$ip/MAAS/api/2.0/
[15:52] <mwe11> bt it seems like iptables drops it
[15:52] <julen> aha! ok.. that is IPv6
[15:53] <julen> I have the same. That means that the juju docu is wrong
[15:54] <julen> 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] <mwe11> iptables?
[15:56] <julen> there is this new ufw thing
[15:56] <mwe11> ufw status
[15:57] <julen> inactive
[15:57] <mwe11> mine too
[15:58] <mwe11> but "iptables -L" shows rules
[15:58] <julen> my iptables is empty
[15:58] <julen> maas v2.2.0 right?
[15:59] <mwe11> that means nothing is locked out
[15:59] <mwe11> MAAS Version 2.1.5+bzr5596-0ubuntu1 (16.04.1)
[16:00] <julen> maybe that's why I don't have that commissioning-user-data directory
[16:01] <mwe11> :D
[16:02] <julen> 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] <mwe11> firefox at port 5240?
[16:02] <julen> maybe I am supposed to install juju on the maas controller too...
[16:02] <julen> nope, 80
[16:03] <julen> the 5240 is closed for tcp4
[16:03] <mwe11> I had been told by canonical not to install maas and juju at the same machine
[16:04] <julen> do you have juju too?
[16:05] <mwe11> not yet. Just a VM at the maas server with the name "juju" :D
[16:05] <julen> 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] <julen> hehe :D
[16:05] <julen> I installed juju on my workstation
[16:06] <julen> at the end, it's not really a server. It's just the place from where you submit the tasks to maas
[16:06] <mwe11> you can try the tool tcptraceroute
[16:06] <julen> what you need a server for, is for the charm store thing
[16:09] <julen> 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] <gimmic> mwe11: I owe you a beer
[16:09] <gimmic> mwe11: you just saved me so much time
[16:10] <mwe11> :D You're welcome
[16:10] <gimmic> that script needs to be put into the maas documentation stat
[16:11] <mwe11> @gimmic: which script do you mean?
[16:11] <gimmic> http://paste.ubuntu.com/25032595/
[16:11] <gimmic> I just used the parts i needed
[16:12] <mwe11> @gimmic: @pmautils is currently checking if it fits his need ;-)
[16:14] <mwe11> @gimmic; I developed it during the last 2 month whith 2 trainees
[16:18] <pmatulis> julen, which juju doc is wrong?
[16:22] <julen> pmatulis: https://jujucharms.com/docs/2.1/whats-new
[16:22] <julen> I am using 2.2.0 and assumed that the address what the same
[16:22] <julen> https://192.168.122.143:5240/MAAS
[16:23] <julen> I have no port 5240 listening on IPv4
[16:29] <julen> pmatulis: are you using juju 2.2 ? Which endpoint address do you use for maas?
[16:33] <gimmic> possibly stupid question: Is there any way to see the api calls the webUI is making?
[16:36] <pmatulis> julen, odd, i thought maas always listens on port 5240
[16:37] <julen> not in my controller (v 2.2.0) and not in the one of mwell (v2.1.5)
[16:38] <julen> there is also not so much documentation on how do the config files work
[16:38] <julen> I thought about trying to write something myself, but I have no clue of how to get the info myself
[16:39] <julen> ... besides reading the source code, which looks pretty complex...
[16:40] <julen> I have been trying to make some patches on some bugs I found, but also have no clue of where to search
[16:42] <julen> pmatulis: I am using mostly default settings, and my regiond.conf has "maas_url: http://192.168.122.139:5240/MAAS"
[16:42] <julen> how could I debug this problem?
[16:44] <julen> 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] <mwe11> @weekend for now! good luck everyone
[16:46] <pmatulis> julen, 5240 is for a python-based web server
[16:47] <julen> bye mwell! thanks! :)
[16:47] <julen> but why does the normal web interface listen on 80 then? and how come that the API communicates also with the 80?
[16:48] <pmatulis> 80 is redirected to 5240
[16:48] <pmatulis> you prolly have apache running correct?
[16:48] <julen> yes
[16:48] <pmatulis> bino. it's sole purpose is to redirect. not great i admit
[16:48] <pmatulis> *bingo
[16:49] <julen> should I stop it?
[16:49] <pmatulis> not unless you will use 5240 directly
[16:50] <julen> but how come that I use the address http://$ip/MAAS/ for the CLI?
[16:52] <julen> I have tried all the combinations http://$ip + :5240/MAAS   + /MAAS/api/2.0/   + /MAAS/  ... and none works
[16:53] <pmatulis> julen, fwiw, i *always* use http://$HOST:5240/MAAS/api/2.0 for the CLI
[16:53] <pmatulis> julen, some context: https://bugs.launchpad.net/maas/+bug/1643900
[16:57] <julen> pmatulis, I still don't understand. Then, both juju and maas documentation are kind o wrong...
[16:58] <pmatulis> 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] <julen> the controller is simply not listening on that port...
[17:00] <pmatulis> julen, what maas version and did you install it freshly (not updated)? i would like to reproduce
[17:00] <julen> 2.2.0~rc1
[17:01] <pmatulis> on Xenial?
[17:01] <julen> completely new
[17:01] <julen> zesty
[17:01] <pmatulis> ok, and that's ppa:maas/stable right?
[17:02] <pmatulis> or is it in the archives, i think it is actually
[17:02] <pmatulis> for zesty
[17:02] <pmatulis> yes, it is
[17:02] <julen> I think I didn't add any ppa
[17:03] <julen> apt-cache policy maas says: http://archive.ubuntu.com/ubuntu zesty/main amd64 Packages
[17:04] <pmatulis> creating zesty instance now...
[17:05] <julen> cool! :D
[17:06] <julen> so, I just installed clean, and apt update && apt -y upgrade && apt -y dist-upgrade
[17:07] <julen> then apt -y install maas maas-cli
[17:09] <pmatulis> maas package drags in maas-cli
[17:09] <pmatulis> i'm installing 'maas' now
[17:18] <pmatulis> $ nc -vz localhost 5240
[17:18] <pmatulis> Connection to localhost 5240 port [tcp/*] succeeded
[17:18] <pmatulis> julen, ^^^
[17:18] <julen> :O !
[17:19] <julen> wait wait...
[17:19] <julen> netstat -tulpen | grep 5240
[17:20] <julen> that also works for me! :P you are connecting via IPv6...
[17:20] <julen> try to connect from somewhere else
[17:22] <pmatulis> nc -vz 10.55.60.29 5240
[17:22] <pmatulis> Connection to 10.55.60.29 5240 port [tcp/*] succeeded!Y
[17:22] <julen> ok...
[17:23] <julen> wait.. it also worked for me!
[17:23] <julen> so why is nmap not showing the port?
[17:24] <julen> and why does netstat also not show that it is listening for IPv4?
[17:24] <pmatulis> dunno. it does seem to look ipv6 only. but works. i'm not using ipv6
[17:24] <pmatulis> maybe there is some switcharoo happening
[17:24] <julen> ok... final test...
[17:24] <pmatulis> i'm going to ask someone
[17:25] <julen> try with juju add-cloud, maas and http://192.168.122.139:5240/MAAS
[17:33] <pmatulis> julen, i used localhost
[17:34] <pmatulis> you wanted the juju client to be remote i think
[17:35] <pmatulis> lemme create a second instance
[17:35] <julen> pmatulis: yes
[17:35] <julen> I have the controller on a machine and juju on the local one
[17:36] <pmatulis> julen, and why did you use that specific address? i will use my own address
[17:36] <julen> that's the point with juju, right? to use it from anywhere and attach external resources to run the jobs
[17:36] <pmatulis> sure, the client can be anywhere
[17:36] <julen> pmatulis: do you mean, http://192.168.122.139:5240/MAAS ?
[17:37] <pmatulis> yes
[17:37] <julen> I saw it in the docu
[17:37] <pmatulis> well obviously you need to change that to fit your needs
[17:37] <julen> https://jujucharms.com/docs/2.1/clouds-maas#registering-a-maas-cloud-with-juju
[17:38] <julen> plus, it appears also on the /etc/maas/regiond.conf and rackd.conf
[17:39] <mup> Bug #1408106 changed: attach_disconnected not sufficient for overlayfs <aa-kernel> <aa-parser> <aa-tools> <AppArmor:Invalid by jjohansen> <MAAS:Invalid> <apparmor (Ubuntu):Invalid by sbeattie> <linux (Ubuntu):Invalid by jjohansen> <https://launchpad.net/bugs/1408106>
[17:39] <pmatulis> julen, so you tried to use 192.168.122.139 over the network right?
[17:40] <julen> I am too afraid to dive into the source code of the web API to try to find out the right syntax
[17:40] <julen> yes
[17:40] <pmatulis> 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] <julen> 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] <pmatulis> julen, it will work on the localhost but not over the network
[17:42] <julen> on the code block, it says: Enter the API endpoint url: http://maas.example.org:5240/MAAS
[17:43] <julen> hmm...
[17:43] <pmatulis> julen, that subnet is used internally by libvirt
[17:43] <julen> so, I cannot communicate with my maas server from outside?
[17:44] <julen> sure...
[17:44] <pmatulis> 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] <julen> I have a maas controller running as a VM on my workstation and the nodes are also VMs
[17:45] <pmatulis> yep, they are all using the same internal subnet, so that works
[17:45] <pmatulis> the bridge will allow your libvirt guests to be contacted over the network
[17:45] <julen> but, what difference does it make?
[17:46] <pmatulis> b/c, if i understand correctly, you have a juju client that is *not* on that subnet
[17:46] <julen> you mean, get the VMs to the physical network...
[17:46] <julen> yes it is
[17:46] <pmatulis> it is?
[17:47] <julen> it is on the 192.168.122.1
[17:47] <pmatulis> oh
[17:47] <julen> the hypervisor
[17:47] <pmatulis> the juju client is the hypervisor?
[17:47] <julen> this is why i can curl, ping, ... from the same terminal
[17:47] <julen> yep
[17:47] <pmatulis> ok, that's fine
[17:48] <pmatulis> so it should work. my 2nd instance should be ready now
[17:49] <julen> just one hint... we have a corporate http-proxy, but I already added no_proxy=http://my-proxy:8080 on that shell
[17:49] <pmatulis> julen, and where does it fail and what is the error
[17:49] <julen> Can't validate endpoint: No MAAS server running at 192.168.122.139
[17:49] <pmatulis> during the 'juju add-cloud' command right?
[17:50] <julen> yes
[17:50] <julen> juju add-cloud
[17:50] <julen> > maas
[17:50] <julen> > desktop
[17:50] <julen> > http://192.168.122.139/MAAS
[17:50] <julen> Can't validate endpoint: No MAAS server running at http://192.168.122.139/MAAS
[17:51] <pmatulis> Enter the API endpoint url: http://10.55.60.29:5240/MAAS
[17:51] <pmatulis> Cloud "maas-cloud" successfully added
[17:52] <pmatulis> so it's something on your network
[17:52] <pmatulis> firewall?
[17:52] <julen> not between my and the VM...
[17:52] <julen> also, on the same terminal:
[17:52] <julen> nc -vz 192.168.122.139 5240
[17:52] <julen> Connection to 192.168.122.139 5240 port [tcp/*] succeeded!
[17:53] <pmatulis> so add port 5240
[17:53] <julen> sure.. same result
[17:54] <julen> Enter the API endpoint url: http://192.168.122.139:5240/MAAS/
[17:54] <julen> ... waitwaitwait...
[17:54] <pmatulis> why? :)
[17:54] <julen> well... I have done it about 10 times today. It returns...
[17:55] <julen> Can't validate endpoint: No MAAS server running at http://192.168.122.139:5240/MAAS
[17:55] <julen> (I was just waiting for the response... which takes a while)
[17:56] <julen> yep. It just returned that
[17:56] <julen> is there some hidden stuff with the http_proxy settings?
[17:57] <julen> I am passing no_proxy=192.168.122.139
[17:57] <julen> should I pass NO_PROXY as well?
[17:57] <pmatulis> i don't believe proxying is involved at this stage
[17:58] <pmatulis> but can you revert to default settings just in case?
[17:59] <julen> Dammit!
[17:59] <julen> I am stupid! :P
[17:59] <pmatulis> is that a good damnit or a bad damnit?
[17:59] <julen> I passed noproxy :D
[18:00] <julen> bad because I am stupid, good because the right no_proxy did the job ;)
[18:00] <pmatulis> there you go :)
[18:00] <julen> I wasted so many hours with this stupid thing...
[18:00] <julen> thank you very much!!
[18:00] <julen> hey... now that we are here...
[18:00] <julen> a bonus point...
[18:00] <julen> how do you set the timezone for the nodes?
[18:01] <julen> my controller was in UTC and if I change it to CEST the there is a +2 difference with the nodes
[18:01] <pmatulis> oof, that sounds like a base ubuntu thing. i guess it would be with a preseed level
[18:01] <julen> well.. I worked around by setting the controller to UTC
[18:01] <julen> I can probably use some custom script to reconfigure the tzdata
[18:02] <pmatulis> i think it just uses what the image uses
[18:04] <julen> I have to look into that. As soon as I get the production one up, I definitely have to find some time to check the source code into more detail
[18:05] <julen> but ... thank you very much :D
[18:23] <gimmic> Is there any way to see why explicitly a node failed testing?
[18:27] <gimmic> Would be nice if the output had a highlight or other indicator to show where the smart test(s) bombed. nodes with a lot of disks are tedious to dig through
[19:45] <gimmic> Is it possible to assign static interface IP addresses via cli
[19:50] <jamesbenson> hi, I just installed centos7 with maas, and I noticed that our br0 (which has our public IP), doesn't come up.  brctl isn't installed
[19:50] <jamesbenson> have others ran into this problem?
[19:53] <roaksoax> jamesbenson: custom networking is not supported in centos
[19:53] <roaksoax> jamesbenson: it will be supported in maas 2.3+
[19:54] <jamesbenson> gah, okay.  I appreciate it :-)
[20:12] <gimmic> I found how to add a new IP to an interface, but I can't seem to update one via cli
[20:18] <mup> Bug #1702751 opened: maas machines create fails when node can't be reached via ipmi <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1702751>
[20:18] <mup> Bug #1702754 opened: No way to add a node as admin user without starting commissioning <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1702754>
[21:22] <pmatulis> gimmic, you want to change a static IP address on an interface?