[00:57] <mup> Bug #1671407 opened: Creation of kvm machine with large root-disk fails <4010> <juju:Incomplete> <juju 2.1:Won't Fix> <MAAS:New> <https://launchpad.net/bugs/1671407>
[01:42] <mup> Bug #1674148 opened: hook for storage: storage already attached - Juju using already mounted disk <juju:Incomplete> <MAAS:New> <https://launchpad.net/bugs/1674148>
[01:51] <mup> Bug #1674148 changed: hook for storage: storage already attached - Juju using already mounted disk <juju:Incomplete> <MAAS:New> <https://launchpad.net/bugs/1674148>
[01:57] <mup> Bug #1674148 opened: hook for storage: storage already attached - Juju using already mounted disk <juju:Incomplete> <MAAS:New> <https://launchpad.net/bugs/1674148>
[02:59] <lalit> join
[03:01] <lalit> hello experts
[03:01] <lalit> I have conbfigured maas server . when nodes boot up with maas pxe i am getting exception "raise DataSourceNotFoundException"
[03:02] <lalit> above exception is from cloudinit script
[04:36] <mup> Bug #1657375 changed: RFE: DNS and DHCP <MAAS:Expired> <https://launchpad.net/bugs/1657375>
[07:11] <Guest9012> Did anyone had luck with installing CentOS 7 on a node using MAAS 2.1.3 version?
[07:12] <Guest9012> I am running into issue https://bugs.launchpad.net/maas/+bug/1658718?comments=all
[09:31] <cnf> morning
[09:32] <cnf> also, wow...
[09:32] <cnf> https://bugs.launchpad.net/maas/+bug/1631908 2016-10-10
[09:32] <cnf> i'm screwd
[09:36] <Guest84817> did anyone run into issues listed in bug https://bugs.launchpad.net/maas/+bug/1658718?comments=all?
[09:36] <Guest84817> it is related to CentOS installation via MAAS 2.1.3
[10:16] <cnf> hmm
[10:34] <cnf> hmm...
[10:35] <cnf> jamespage, roaksoax i think i might have found why my vlans are not coming up
[10:40] <cnf> jamespage: ah, and it seems you already know about it :P
[10:41] <jamespage> cnf: ?
[10:41] <cnf> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1565804
[10:41] <cnf> and https://bugs.launchpad.net/maas/+bug/1543195
[10:41] <cnf> jamespage: i had large MTU set on vlan interfaces
[10:41] <cnf> and MAAS isn't setting the corresponding MTU on the base interface
[10:42] <jamespage> cnf: that rings a bell somewhere - reading the bug I do seem to remember something about that
[10:42] <jamespage> cnf: I thought MAAS would not let you do the wrong thing these days.
[10:42] <cnf> :P
[10:42] <cnf> it seems it does
[10:43] <cnf> do you remember the fix?
[10:46] <jamespage> cnf: reading the bug reports I though this was fixed in the vlan package
[10:46] <jamespage> "If VLAN is configured with higher MTU than raw device MTU, which can
[10:46] <jamespage>     happen if VLAN is ifup'ed before raw device, then increase raw device
[10:46] <jamespage>     MTU first so the VLAN ifup does not fail."
[10:47] <cnf> hmm
[10:47] <jamespage> cnf: how did you set the mtu's up in MAAS?
[10:47] <cnf> on the vlan
[10:48] <cnf> is there a different place?
[10:49] <cnf> hmm
[10:49] <cnf> jamespage: so if i ifdown / ifup the base interface, my vlans do come up
[10:49] <jamespage> cnf: digging
[10:49] <jamespage> https://bugs.launchpad.net/maas/+bug/1543195
[10:50] <jianghuaw_> Hi, anyone know how to customize the maas images? I want to pre-install guest tools in the image. Thanks.
[10:50] <cnf> jianghuaw_: use commissioning scripts?
[10:51] <cnf> jamespage: i just linked you that one :P
[10:51] <jamespage> cnf: so you did (only noted the first)
[10:51] <jianghuaw_> cnf, thanks. Will try.
[10:51] <jamespage> cnf: have you set the mtu on the 'default' vlan as described in that bug report?
[10:51] <cnf> jamespage: thing is, i have no default vlan
[10:52] <cnf> hmm, i guess i can set the untagged one...
[10:52] <cnf> because maas is weird that way
[10:52] <cnf> jamespage: let me try that
[10:52] <jamespage> cnf: well every port has untagged traffic  - try that
[10:52] <cnf> well, our switches don't allow untagged on trunks
[10:53] <cnf> but yeah, i made a vlan 0 (untagged) vlan, which has no subnets
[10:53] <cnf> i'm setting MTU on that
[10:53] <jamespage> cnf: +1
[10:55] <cnf> jamespage: now to wait 20 minuted for redeploy :P
[10:57] <cnf> jamespage: stuff like this should be documented ^^;
[10:57] <cnf> if it is this, i just spend 2 days finding why things where not working >,<
[10:59] <jamespage> roaksoax, mpontillo: what is the maas story for MTU management these days - I've not used it since 1.9 where the above but was reported originally
[11:00] <jamespage> roaksoax, mpontillo: I thought that was going to be managed at the fabric level, and automatically propagated to network interfaces connected to a fabric
[11:00] <jamespage> rather than being set on a individual VLAN level
[11:03] <mpontillo> jamespage: agree that it would be good to have a default MTU on a fabric and/or vlan that would automatically propagate to interfaces configured on said fabric/vlan
[11:03] <mpontillo> jamespage: there may have been some discussion about that but I think only interface-level MTU made it so far
[11:04] <cnf> that would make more sense :P
[11:04] <cnf> or at least set the base device MTU high enough automatically
[11:04] <cnf> you should not deploy configs that do not work :P
[11:07] <mpontillo> cnf: jamespage: so to be clear, for this specific issue.. it sounds like there is a bug/wishlist item for MAAS in which we should, upon creating a VLAN, automatically adjust the MTU of the VLAN's parent to be +4 to account for the 802.1q tag. do I understand correctly?
[11:07]  * mpontillo hasn't had coffee yet, sorry ;-)
[11:07] <cnf> sounds good
[11:08] <mpontillo> cnf: would you do me a favor and file this as a bug in MAAS, and include why the current behavior breaks you? https://bugs.launchpad.net/maas/+filebug
[11:10] <jamespage> do switches define global mtu's or per port mtu's
[11:10] <jamespage> or is the answer there 'it depends'
[11:10] <jianghuaw_> cnf, may i ask another question?
[11:10] <jianghuaw_> I'm deploying applications on 4 machines; but the last machine got stuck at allocating status. From MAAS, it's kept in deploying status. As I don't think it will proceed. So marked this machine as broken. the problem is it didn't allocate new machine. How can I proceed under this situation?
[11:11] <mpontillo> lamont: ^ FYI and see also bug #1543195; I guess you already wrote some code for fabric-level MTU that I forgot about =)
[11:12] <cnf> jianghuaw_: idno, release it?
[11:12] <cnf> jamespage: it depends :P
[11:12] <mpontillo> cnf: jianghuaw_: it's appropriate to mark broken if you don't think the machine will ever work again, but then I think you'd want to retry the deployment (I assume this is with juju?)
[11:12] <cnf> jamespage: but maas seems to assume every port is configured the same, anyway
[11:13] <jianghuaw_> cnf, anyway to make it allocate new machine and continue the application deployment?
[11:13] <cnf> jamespage: can't chose the "default untagged" vlan per device, anyway
[11:13] <jianghuaw_> mpontillo, yes, it's with juju.
[11:13] <cnf> jianghuaw_: ah, i have no idea how to make juju recover from broken machines...
[11:13] <cnf> if you figure that out, please please do let me know :P
[11:14] <jianghuaw_> cnf, sure I will if I can:-)
[11:14] <mpontillo> jamespage: I think MTU is a source of bugs for switch vendors too ;-) on the switches I've worked with I think it's per-VLAN
[11:15] <jamespage> oh for a fully software defined datacenter
[11:17] <cnf> mpontillo: https://bugs.launchpad.net/maas/+bug/1674658
[11:17] <jamespage> thankyou cnf
[11:18] <mpontillo> cnf: thanks much
[11:19] <mpontillo> jianghuaw_: sounds like this may be a better question for #juju
[11:19] <cnf> the "VLAN with ID 0 (not tag 0) is the default "untagged" traffic confused me as well
[11:19] <mpontillo> jianghuaw_: once you mark the machine broken in MAAS you should be able to cancel and retry in juju; I just don't know the commands from the top of my mind
[11:19] <mup> Bug #1674658 opened: setting larger MTU on vlan does not set MTU on base device <MAAS:Triaged> <https://launchpad.net/bugs/1674658>
[11:20] <jianghuaw_> mpontillo, Thanks very much. Will ask in #juju.
[11:20] <mpontillo> cnf: when we say "VID" that is an 802.1q tag, it should be the same.
[11:20] <cnf> mpontillo: right, but you don't get to choose
[11:21] <cnf> if you add an interface, the VLAN field is grayed out, and the original vlan in the fabric is selected
[11:21] <cnf> only way to change that is rename them, because the 1st one is _always_ the default one
[11:21] <cnf> (from what I can tell, anyway)
[11:21] <Guest84817> looks like no one has tried with CentOS7 installation through MAAS :(
[11:22] <mpontillo> cnf: ah, 0 is just the "default untagged", though arguably that is not very useful since the default tag can vary per-port. MAAS likes it better if the default VLAN is consistent throughout the fabric.
[11:22] <brendand> Guest84817, we do test that
[11:22] <Guest84817> anyone has any update for  https://bugs.launchpad.net/maas/+bug/1658718 ?
[11:22] <cnf> mpontillo: 0 not as in the VLAN, but as in the ID to maas :P
[11:23] <cnf> mpontillo: we don't use untagged traffic on trunk ports
[11:23] <Guest84817> @brendand - I see issues reported in  https://bugs.launchpad.net/maas/+bug/1658718
[11:23] <roaksoax> Guest84817: no there's no update for that. We are working on other issues at the moment
[11:23] <mpontillo> cnf: to be honest I would like to move away from this concept entirely; I don't like the idea that there is a "dumping ground" object that may get polluted with things in which we don't know where they would otherwise go =)
[11:23] <cnf> yeah
[11:24] <Guest84817> roaksoax: I had tried with MAAS 2.0, 2.1.2 and 2.1.3
[11:24] <Guest84817> all gave same errors
[11:24] <brendand> Guest84817, what hardware are you using?
[11:24] <mpontillo> cnf: the "we don't use untagged traffic on trunk ports" issue may deserve a bug, too, then; is a MAAS region/rack interface managing your network via a trunk port?
[11:25] <Guest84817> brendand: Wiwynn servers
[11:25] <cnf> mpontillo: so our machines are connected on 10G LAGs
[11:25] <Guest84817> but I am sure it is not h/w related
[11:25] <cnf> mpontillo: as I could not figure out how to PXE boot on LAG interfaces, i added a copper link just for MAAS / PXE
[11:25] <Guest84817> seems to be something to do with curtin hooks configuration
[11:26] <cnf> the LAGs only do tagged traffic
[11:26] <Guest84817> within images
[11:26] <mpontillo> cnf: yeah, that's a terrible workaround; I'd like to see this fixed
[11:26] <cnf> yeah, i'd like to see that fixed as well :P
[11:26] <mpontillo> cnf: what was the issue there? if you wouldn't mind filing another bug that would be nice
[11:26] <cnf> no idea how to get PXE booting on LAG interfaces, though
[11:27] <cnf> because there is no LACP link at boot time, obviously
[11:29] <roaksoax> Guest84817: this is not a bug in MAAS, this is a bug in the image
[11:29] <Guest84817> I believe I am using images officially supported by MAAS ... is this the right assumption?
[11:30] <cnf> doesn't mean they can't contain bugs :P
[11:30] <roaksoax> cmagina: are you sure it is not a firmware/grub issue ? we just recently got confirmation that PXE booting on 10gig interfaces isn't related to MAAS itself, but rather grub & firmware
[11:30] <roaksoax> err
[11:30] <roaksoax> cmagina: sorry
[11:30] <roaksoax> cnf: ^^\
[11:30] <cnf> roaksoax: i can PXE on 10G
[11:31] <cnf> roaksoax: i can't PXE on LACP links
[11:31] <roaksoax> Guest84817: they are officially supported. But that doesn't necessarily mean we have all the hardware available out there ot test this image against. We only CI against the hardware we currently have available
[11:31] <mpontillo> cnf: yeah you might be stuck with copper then, probably more reliable anyway
[11:31] <cmagina> np
[11:32] <cnf> roaksoax: this might also be a problem with the juniper qfabrics, i don't know
[11:32] <roaksoax> cnf: gotcha!
[11:32] <cnf> not even sure if this should / could work, tbh
[11:33] <Guest84817> roaksoax: Looking at the error, it doesn't look like a h/w issue
[11:33] <cnf> mpontillo: it is quite annoying, we are not really set up for copper :P
[11:34] <Guest84817> or related to drivers
[11:34] <cnf> mpontillo: iLo links are on a separate network, and most of those are on 100mbps :P
[11:34] <cnf> the rest is all fiber
[11:35] <mpontillo> cnf: I was just talking to someone yesterday who was doing something similar; their management interface for IPMI was able to be used also as the PXE interface; seemed like a clean solution. (but 100mbps is sad; it's the new millennium!) ;-)
[11:35] <cnf> well, it's just IPMI
[11:35] <cnf> it's all old copper switched
[11:36] <cnf> we really don't have a lot of copper around
[11:36] <cnf> my 6 copper links filled up the switch
[11:36] <cnf> for the PXE booting
[11:36] <roaksoax> Guest84817: it is not a hardware issue. it is a EFI issue
[11:36] <mpontillo> cnf: right, I guess some newer servers will let you use an internal switch connected to the BMC to do PXE booting /and/ IPMI, the PXE-boot-over-LAG issue being somewhat known in the industry I suspect
[11:36] <cnf> fiber, i can ask as many as i want
[11:36] <cnf> mpontillo: you can also put IPMI on your "normal" nic
[11:37] <cnf> HP and dell let you do that
[11:37] <cnf> i'm sure others do as well
[11:37] <mpontillo> cnf: that might boost you up from 100 megabits too =)
[11:37] <Guest84817> roaksoax: if you have detailed insight, can you please elaborate on what exactly is the issue?
[11:37] <cnf> mpontillo: no, because the IPMI network is only 100mbps :P
[11:38] <cnf> mpontillo: strange, i know, but ipmi here is 100mpbs everywhere
[11:38] <cnf> mpontillo: everything else is  2 x 10G fiber LACP
[11:38] <cnf> or 2 x 40G LACP if need be
[11:38] <cnf> hardly any 1G copper around
[11:38] <mpontillo> cnf: right. okay, thanks for the discussion and for the bug reports - I've got to step out for a bit
[11:38]  * mpontillo -> {coffee, breakfast}
[11:38] <cnf> \o thanks for the help
[11:39] <roaksoax> Guest84817: i dont have detailed insight, but there's a bug installing centos on machines with EFI. Machines in Legacy mode will work just fine
[11:39] <roaksoax> Guest84817: unfortauntely, we have not had the time to fix it
[11:41] <Guest84817> roaksoax: so is there a workaround of how I can instruct MAAS to install via legacy mode for a specific host?
[11:41] <brendand> Guest84817, ask ipmi to tell it to
[11:42] <brendand> oh but you mean via maas
[11:43] <roaksoax> Guest84817: no, MAAS is currently agnostic as to what you boot (whether EFI/Legacy). You can change the BIOS settings and recommission the machine
[11:43] <roaksoax> and you should be able to deploy
[11:43] <Guest84817> brendand: yes, I believe MAAS is trying to go with EFI mode, so I will need to configure in MAAS for legacy mode
[11:43] <roaksoax> Guest84817: you can reconfigure the BIOS via IPMI as well
[12:07] <cnf> btw
[12:07] <cnf> is there a way to install the MAAS cli stand alone?
[12:07] <cnf> preferably not on ubuntu :P
[12:07] <Guest84817> roaksoax: brendand: thanks for the details. Will give it a try
[12:07] <Guest84817> in case if you have any updates on the bug that would be great
[12:08] <Guest84817> do you have a roadmap for the bug resolution?
[12:09] <roaksoax> Guest84817: it is on the bug list atm
[12:09] <roaksoax> cnf: only uspport in ubuntu atm
[12:09] <roaksoax> cnf: sudo apt-get install maas-cli
[12:10] <cnf> hmm, bummer
[12:10] <cnf> roaksoax: what is it written in?
[12:10] <roaksoax> cnf: python
[12:10] <cnf> hmm, and no pip package?
[12:10] <roaksoax> cnf: no the cli
[12:10] <roaksoax> cnf: libmaas is, but libmaas is alpha at the moment
[12:10] <roaksoax> and does not cover everything
[12:10] <roaksoax> nor all releases
[12:11] <cnf> hmm
[12:11] <cnf> i'd really like the maas cli available on my mac
[12:11] <brendand> cnf, container?
[12:11] <cnf> brendand: yeah, but that's still a bit of a pain
[12:12] <cnf> brendand: it's probably what i'll do for now, though
[12:13] <cnf> but a brew install maas-cli would be awesome :P
[12:13] <brendand> cnf, that will probably never happen - libmaas in python is the priority
[12:13] <roaksoax> cnf: the new cli will probbaly be
[12:13] <cnf> roaksoax: nice
[12:13] <cnf> juju is in homebrew
[12:14] <roaksoax> the new cli is being built on top of libmaas
[12:14] <cnf> ah, nice
[12:14] <roaksoax> cnf: http://maas.github.io/python-libmaas/
[12:15] <cnf> running pip install python-libmaas :P
[12:15] <roaksoax> its on baby steps bte
[12:15] <roaksoax> btw
[12:15] <roaksoax> :)
[12:15] <cnf> sure, i saw the ALPHA disclaimer :P
[12:15] <brendand> cnf, you're welcome to contribute and add what you need :)
[12:16] <cnf> <3 virtualenvwrapper
[12:25] <brendand> cnf, hint: http://paste.ubuntu.com/24221349/
[12:27] <cnf> $ maas list --all
[12:27] <cnf> works :P
[12:28] <brendand> cnf, just bear in mind that the api is very limited atm
[12:28] <cnf> roaksoax: so add a "most seems to work, so far, for libmaas cli, on OSX sierra
[12:28] <cnf> yeah
[12:29] <mup> Bug #1671407 changed: Creation of kvm machine with large root-disk fails <4010> <juju:Incomplete> <juju 2.1:Won't Fix> <MAAS:Invalid> <https://launchpad.net/bugs/1671407>
[12:30] <roaksoax> cnf: cool
[12:32] <cnf> ok, i think maas is up, for now
[12:32] <cnf> back to juju :P
[12:43] <cnf> sheesh!
[12:44] <cnf> back here :(
[12:45] <cnf> https://bpaste.net/show/1c001024308b is what maas made of my network config this time
[12:45] <cnf> o,O
[12:51] <roaksoax> cnf: yeah juju creates the bridges
[12:51] <roaksoax> cnf: to put containers/kvms
[12:52] <cnf> hmm, and then it tells me it doesn't have the right ip's
[12:55] <cnf> this shit is really frustrsting
[13:10] <zeestrat> Hey, was there CLI command to skip the whole "Intro" thing on a fresh MAAS install?
[13:28] <pmatulis> zeestrat, yup
[13:32] <pmatulis> but iirc, it only suppresses the first stage (there are two). someone should file a bug on it
[13:32] <pmatulis> maas $PROFILE maas set-config name=completed_intro=true
[13:33] <pmatulis> ^^^ this means it is completed
[13:39] <zeestrat> pmatulis: Thanks. I'll see how that works out and perhaps file a bug.
[13:40] <pmatulis> zeestrat, thanks a lot. i usually track the maas bugs but if you can remember to ping me that would be great
[13:40] <pmatulis> https://github.com/CanonicalLtd/maas-docs/issues/364
[13:40] <pmatulis> zeestrat, ^^^
[13:48] <zeestrat> pmatulis: cheers
[14:00] <zeestrat> pmatulis: Just to make sure I'm not screwing up, are you sure the command is "maas $profile maas set-config name=completed_intro=true" and not "maas $profile maas set-config name=completed_intro value=true"?
[14:01] <pmatulis> zeestrat, you can try it
[14:02] <zeestrat> pmatulis: The latter is the only one that works for me on MAAS 2.1.4
[14:02] <pmatulis> then verify with
[14:02] <pmatulis> maas $PROFILE maas get-config name=completed_intro
[14:03] <zeestrat> "maas $profile maas set-config name=completed_intro=true" just returns "No provided value!" and does not set it.
[14:04] <pmatulis> zeestrat, your syntax is good then and makes sense according to
[14:04] <pmatulis> maas $PROFILE maas set-config -h
[14:04] <pmatulis> :param name: The name of the config item to be set.
[14:04] <pmatulis> :param value: The value of the config item to be set.
[14:04] <pmatulis> lemme change my doc bug
[15:08] <mup> Bug #1674714 opened: [CLI] create subnet with space does not work when referring to space by name <MAAS:New> <https://launchpad.net/bugs/1674714>
[15:08] <mup> Bug #1674720 opened: metadataserver: NodeKey matching query does not exist <MAAS:New> <https://launchpad.net/bugs/1674720>
[15:11] <mup> Bug #1674714 changed: [CLI] create subnet with space does not work when referring to space by name <MAAS:New> <https://launchpad.net/bugs/1674714>
[15:11] <mup> Bug #1674720 changed: metadataserver: NodeKey matching query does not exist <MAAS:New> <https://launchpad.net/bugs/1674720>
[15:14] <mup> Bug #1673987 changed: [2.2 beta3]  Servers are failing to deploy - Times out after PXE installation - cloud-init[1563]: Can not apply stage final, no datasource found! Likely bad things to come! <cdo-qa-blocker> <oil> <curtin:New> <MAAS:Triaged> <https://launchpad.net/bugs/1673987>
[15:14] <mup> Bug #1674030 changed: [2.2] AttributeError: 'tuple' object has no attribute 'subnet_id' <MAAS:Triaged> <https://launchpad.net/bugs/1674030>
[15:14] <mup> Bug #1674714 opened: [CLI] create subnet with space does not work when referring to space by name <MAAS:New> <https://launchpad.net/bugs/1674714>
[15:14] <mup> Bug #1674720 opened: metadataserver: NodeKey matching query does not exist <MAAS:New> <https://launchpad.net/bugs/1674720>
[15:15] <ThiagoCMC> Hey guys, I'm playing with "maas-2.2.0~beta3+bzr5815-0ubuntu1~16.04.1" and I'm seeing a problem here... If I change the DNS for a PXE subnet, and reboot the bare-metal server, it doesn't see the new DNS server.
[15:15] <ThiagoCMC> Any tips?
[15:16] <ThiagoCMC> Under "Subnet summary", both "DNS" and "Gateway IP" changes have no effect.
[15:17] <ThiagoCMC> Since the gateway ip was wrong, instead, I changed it on /etc/network/interfaces instead, so now at least, the gateway ip matches what it shows on subnet summary, however, things are a bit different for DNS...
[15:18] <brendand> ThiagoCMC, just rebooting the machine would not reflect any changes in maas
[15:18] <brendand> ThiagoCMC, you would have to recommission/deploy
[15:18] <ThiagoCMC> Ouch!
[15:18] <ThiagoCMC> I'll try that...
[15:21] <BlackDex> Hello there, I have a big issue with maas atm
[15:21] <BlackDex> when i deploy a system it doesn't seem to get out of the deploying state
[15:22] <BlackDex> it seems the system starts correctly, but in the end it keeps running the deployment status, and after a while it will go to failed
[15:23] <BlackDex> It looks like it starts oke, it even gets the correct network settings
[15:23] <BlackDex> what could be the issue?
[15:23] <BlackDex> i do not see anything in the maas logs
[15:23] <BlackDex> or what ever
[15:24] <brendand> BlackDex, did you check the syslog under /var/log/maas/rsyslog?
[15:24] <BlackDex> brendand: Yes
[15:24] <BlackDex> it all seems oke
[15:25] <BlackDex> after the deployment it reboots
[15:25] <BlackDex> and that seems to go fine
[15:25] <BlackDex> but it never reports back
[15:25] <BlackDex> i also can ping the IP('s)
[15:25] <BlackDex> but can't connect to it via ssh
[15:25] <BlackDex> while during comission mode, i can connect with ssh
[15:26] <pmatulis> BlackDex, what is the nature of the node's underlying machine?
[15:26] <mup> Bug #1673987 opened: [2.2 beta3]  Servers are failing to deploy - Times out after PXE installation - cloud-init[1563]: Can not apply stage final, no datasource found! Likely bad things to come! <cdo-qa-blocker> <oil> <curtin:New> <MAAS:Triaged> <https://launchpad.net/bugs/1673987>
[15:26] <mup> Bug #1674030 opened: [2.2] AttributeError: 'tuple' object has no attribute 'subnet_id' <MAAS:Triaged> <https://launchpad.net/bugs/1674030>
[15:26] <BlackDex> the nature? of the underluing machine?
[15:27] <BlackDex> i don't really understand that question
[15:28] <pmatulis> is it a bare metal HP machine? a KVM guest? a vmware system?
[15:28] <BlackDex> ah
[15:28] <BlackDex> bare-metal :)
[15:28] <BlackDex> Dell R630
[15:28] <pmatulis> what BMC did you choose for that?
[15:29] <pmatulis> (power type)
[15:29] <BlackDex> using IPMI LAN_@
[15:29] <BlackDex> LAN_2
[15:29] <BlackDex> But i have the same with all systems in the setup
[15:30] <BlackDex> except for a KVM instance
[15:30] <pmatulis> oh, and the others work fine?
[15:30] <BlackDex> which is on the same machine as maas is installed on
[15:30] <BlackDex> all systems fail
[15:30] <BlackDex> i use maas a lot
[15:30] <BlackDex> but i never have seen this
[15:30] <pmatulis> i'm wondering if there's a more suitable power type for these Dell machines
[15:31] <pmatulis> did you try any other?
[15:31] <BlackDex> it does boot
[15:31] <BlackDex> it powers the systems on
[15:31] <BlackDex> and off
[15:31] <BlackDex> so that seems to work
[15:31] <BlackDex> only the last part of telling maas it is finished doesn't work, and it seems that ssh isn't running etc..
[15:38] <mup> Bug #1673987 changed: [2.2 beta3]  Servers are failing to deploy - Times out after PXE installation - cloud-init[1563]: Can not apply stage final, no datasource found! Likely bad things to come! <cdo-qa-blocker> <oil> <curtin:New> <MAAS:Triaged> <https://launchpad.net/bugs/1673987>
[15:38] <mup> Bug #1674030 changed: [2.2] AttributeError: 'tuple' object has no attribute 'subnet_id' <MAAS:Triaged> <https://launchpad.net/bugs/1674030>
[15:38] <brendand> BlackDex, if it's got that far there should be a syslog, and it should have enough detail to tell why it's going wrong
[15:39] <brendand> BlackDex, get the hostname of the machine and look in /var/log/rsyslog/<hostname>/<date>/messages
[15:39] <BlackDex> i know
[15:39] <BlackDex> and all there is that the installation went fine
[15:39] <BlackDex> and it is going to reboot for the last time
[15:39] <BlackDex> after that, there is no syslog
[15:39] <BlackDex> because it isn't pxe booted
[15:39] <BlackDex> and the system doesn't report syslog after deployment
[15:46] <BlackDex> Mar 21 15:44:17 openstack7 cloud-init[3769]: curtin: Installation finished.
[15:47] <BlackDex> there are no errors except for lvm not found etc..
[15:48] <BlackDex> also, the network the systems are one is a private one, nothing in between but a single switch
[15:50] <BlackDex> i'm going to try 14.04, see if that helps
[16:00] <pmatulis> 14.04?
[16:01] <BlackDex> Ubuntu 14.0
[16:01] <BlackDex> 14.04 LTS as a deployment image
[16:01] <BlackDex> but that failed also
[16:11] <mup> Bug #1606999 changed: reporting messages can slow down operations greatly <MAAS:Confirmed> <https://launchpad.net/bugs/1606999>
[16:15] <BlackDex> lets see if a normal iso install will work
[16:41] <mup> Bug #1674747 opened: [2.1] Cannot sync with an upstream NTP server with stratum=9 or larger <MAAS:New> <https://launchpad.net/bugs/1674747>
[16:48] <BlackDex> brendand pmatulis, you never guess the problem. Apperently the MTU size was giving problems
[16:48] <BlackDex> that is something probably set only at the final stage, so that causes no problems during the deployment
[16:49] <BlackDex> it also figures why the kvm-instance worked, as that is on the same server, and no switch in between
[16:49] <BlackDex> thx for the help :)
[16:54] <kklimonda> are there plans for MAAS to provide CA?
[17:13] <pmatulis> BlackDex, wow ok! welcome
[17:25] <roaksoax> kklimonda: CA ?
[17:26] <kklimonda> roaksoax: certificate authority
[17:30] <stokachu> kklimonda: why would it?
[17:30] <roaksoax> kklimonda: not in the short term
[17:30] <roaksoax> if you want https, you'll need to put say, haproxy in fron
[17:33] <kklimonda> stokachu: for example to configure your local CA on all nodes, or perhaps to have per-node client certificate.
[17:34] <kklimonda> stokachu: I hit it when I was trying to make lxd deploy in an environment where internet connection was spotty
[17:34] <kklimonda> with juju, it was trying to connect to https://streams.canonical.com/ and this is hardcoded
[17:36] <kklimonda> I needed a certificate trusted by lxd/juju for that mirror, and I've ended up installing it with late_commands
[17:37] <kklimonda> but for example kubernetes cluster requires a CA too
[18:20] <fabi> hi @ll
[18:21] <fabi> quick question: I followed all the steps here: https://docs.ubuntu.com/maas/2.1/en/manage-backup but for some reason I can't restore my backup on another machine failing with some kind of django error message "django.core.exceptions.ImproperlyConfigured: settings.DATABASES is improperly configured. Please supply the ENGINE value. Check settings documentation for more details."
[18:34] <pmatulis> fabi, i suggest opening a bug
[18:35] <pmatulis> https://bugs.launchpad.net/maas/+filebug
[18:35] <mup> Bug #1674788 opened: machine allocation on a (virsh) pod fails: frozenset does not support indexing <MAAS:New> <https://launchpad.net/bugs/1674788>
[18:35] <pmatulis> roaksoax, can we get the topic to point to the mailman list?
[18:38] <fabi> pmautils, thanks will investigate and do!
[19:47] <mup> Bug #1674807 opened: View the default-gateway set for a node <MAAS:New> <https://launchpad.net/bugs/1674807>
[21:17] <mup> Bug # changed: 1588350, 1623751, 1669567, 1673377
[21:17] <mup> Bug #1674818 opened: [2.2] on the device details page, add interface and edit interface forms are inconsistent <MAAS:Triaged> <https://launchpad.net/bugs/1674818>
[21:17] <mup> Bug #1214172 changed: juju/MAAS Tag constraints do not work in Precise <maas (Ubuntu):Won't Fix> <https://launchpad.net/bugs/1214172>
[21:20] <maticue_> Hi everyone! We're implementing MAAS region controller + MAAS rack controller. First question is: Is there any limit on the how many MAAS rack controller can be managed by a MAAS region controller?
[21:21] <maticue_> My second question is. I'd like to manage the DNS service using mass-cli. I could create domains, and registers.. everything goes well. However I see a really limited set of option when I create a new DNS domain. For example, they always are "master" and I can't declare using mass-cli a DNS slave. Is there any workaround for this?
[21:25] <roaksoax> maticue_: no limit, but we have not tested against hundreds of then. Maximum we've tested is about 15
[21:26] <maticue_> roaksoax: thanks!! and, do you know who I could resolve dns custom configuration? or at least who can answer that question?
[21:28] <roaksoax> lamont: ^^
[21:29] <lamont> ah, this #maas.
[21:29]  * lamont was quite confused
[21:30] <lamont> maticue_: the maas region will always be the master (in its own mind at least) of any dns domain/zone for which it is told to be authoritative.
[21:30] <lamont> adding a secondary that slaves from the region controller is trivial: just add the NS RR via dnsresource-records
[21:32] <lamont> maas SESSION dnsresource-records create name=@ domain=$DOMAIN rrtype=ns rrdata=${NSHOST}.
[21:32] <lamont> maticue_: what exactly are you trying to do with the DNS?  (most of what you might want to do with delegation is very doable)
[21:35] <maticue_> lamont: great! Now I can see it. However, my idea is to have an authoritative DNS server different than MAAS DNS server, near rack controller. However, I want my MAAS DNS server contains all domains and registers and manage them using the maas-cli . Not sure if I'm clear
[21:38] <lamont> the part that we don't let you have control over: every domain/zone for which maas is authoritative _will_ have the region controller listed as an NS RR.  (See also launchpad.net/bugs/1672220 -- oops).  You can certainly deploy (via maas or "oldschool") an additional NS closer to the rack, add that NS RR to the RRset (for each and every domain you care about...) and thne configure named.conf on
[21:38] <lamont> the slave to pull from (at least) the maas region
[21:40] <lamont> n.b. to simplify things, maas DNS zones are (cough, pay no attention to SRV, cough) limited to labels that contain no dots.  That is, each DNS zone is exactly one domain deep.
[21:41] <lamont> maticue_: there isn't a way for the maas regiond to get told to edit a DNS zone other than those for which it is the master.  (the update changes the maas db, and then the zone file is generated from the db.)
[21:42] <lamont> what I generally do is give the maas server a real honest to goodness domain (maas.example.com), and then add NS RRs for maas.example.com. to the example.com. zone upstream.  I also tell maas to use an upstream resolver.
[21:43] <lamont> at that point, since maas has nothing to do with the upstream resolver config, I just make BIND do what it needs to do to make everything happy
[21:43] <lamont> and I suppose that could be done with split-dns, or even in isolation.
[21:43] <lamont> does that help?
[21:44] <lamont> where I was a bit fuzzy there is that "authoritative" does not clearly indicate master/slave status for the zone
[21:45] <lamont> host other than maas-region as authoritative secondary? trivial.  host other tham maas-region as authoritative-master? only if the maas-region isn't authoritative for the DNS zone.
[21:47]  * lamont forsees a blog post in his near future
[21:47] <maticue_> lamont: that is an excellent information. You give me a lot of reasons to think about. I'm pointing to "host other than maas-region as authoritative secondary"
[21:48] <lamont> that's the dnsresource-records create above, and configure the secondary to grab from the regiond
[21:48]  * lamont has been maintaining bind for way too long
[21:49] <maticue_> great, I'll test in that way. thank you so much!
[21:49] <maticue_> lamont++
[21:51] <lamont> happy to help
[22:46] <lamont> maticue_: http://voices.canonical.com/lamont.jones/2017/03/21/adding-a-secondary-name-server-for-a-domain-in-maas/