[05:01] <mup> Bug #1672947 opened: MAAS accepts 0.0.0.0/0 as a subnet, but this breaks DNS update code <MAAS:New> <https://launchpad.net/bugs/1672947>
[05:27] <ybaumy> can i use a apt proxy for one subnet and for another not?
[05:28] <ybaumy> or is this a global parameter
[09:16] <mup> Bug # changed: 1254807, 1386504, 1441408, 1549397, 1571031, 1582323, 1598175, 1600328, 1602412, 1606508, 1611999, 1614584, 1620478, 1621507, 1628514, 1629982, 1630361, 1630636, 1632853, 1633378, 1633397, 1633401, 1633452, 1633457, 1633462, 1633467, 1633470, 1633600, 1633717, 1633822, 1636250,
[09:16] <mup> 1636251, 1636324, 1636873, 1636874, 1636992, 1637009, 1637182, 1637192, 1637246, 1637401, 1638284, 1638285, 1638288, 1638575, 1638589, 1639182, 1639247, 1639258, 1639288, 1640147, 1640259, 1640780, 1642033, 1642200, 1643552, 1645067, 1645319, 1645912, 1646162, 1646163, 1646748, 1646891, 1646955,
[09:16] <mup> 1647703, 1648456, 1648836, 1651452, 1651675, 1655049, 1656208, 1656717, 1657491, 1659152, 1659164, 1659244, 1659511, 1659607, 1659672, 1659959, 1660185, 1660188, 1660858, 1660863, 1660864, 1661214, 1661579, 1663276, 1663290, 1663517, 1663643, 1663686, 1664285, 1664664, 1664667, 1664732, 1664813,
[09:16] <mup> 1665143, 1665459, 1665478, 1665839, 1667426, 1667754, 1668731, 1668759, 1669213, 1669221, 1669225, 1669226, 1669246, 1669425, 1669428, 1669547, 1669568, 1669570, 1669783, 1669833, 1670326, 1670337, 1670821
[09:46] <mup> Bug #1671897 changed: ui to browse combos of tags is inconsistent with juju's notion of combos of tags <ui> <uosci> <MAAS:Invalid> <https://launchpad.net/bugs/1671897>
[09:49] <mup> Bug #1671897 opened: ui to browse combos of tags is inconsistent with juju's notion of combos of tags <ui> <uosci> <MAAS:Invalid> <https://launchpad.net/bugs/1671897>
[09:52] <mup> Bug #1671897 changed: ui to browse combos of tags is inconsistent with juju's notion of combos of tags <ui> <uosci> <MAAS:Invalid> <https://launchpad.net/bugs/1671897>
[11:37] <mup> Bug #1665482 changed: [2.2] MAAS shows install.log from previous deploy on a machine that failed to commission <MAAS:Fix Released> <https://launchpad.net/bugs/1665482>
[13:41] <rainmaker> Hi all, is there any way to force maas to use eth1 to probe the BMC of the server? I'm having trouble turning on servers with 2 nics connected since the bmc shares port 1
[14:28] <wargamez> Hi. Is maas 2.0 supported by landscape?
[14:29] <roaksoax> rainmaker: i dont fully understand what the issue is there, but you only would need the rack controller reacheable to the IP address of the BMC, or one on the same subnet
[14:34] <cnf> in maas, what is the difference between a fabric and a space?
[14:39] <roaksoax> wargamez: for autopilot? I think they are working in it
[14:39] <roaksoax> cnf: fabric is a swithc or a set of switches
[14:39] <cnf> hmm
[14:39] <roaksoax> cnf: in 2.2+ space concept is being changed from L3 to L2. Basically, a space tells that a vlan or a set of vlans can communicate to each other
[14:39] <cnf> roaksoax: because the docs say "A fabric is a set of interconnected VLANs that are capable of mutual communication. "
[14:40] <roaksoax> pmatulis: ^^
[14:40] <cnf> so i configured my fabrics as if they where spaces
[14:41] <cnf> roaksoax: so i can have 10 vlans in 8 spaces  on one fabric, really?
[14:41] <cnf> so why would you define different fabrics on maas?
[14:41] <cnf> here, it's all just one big "virtual switch"
[14:42] <roaksoax> cnf: spaces is not mandatory in 2.2+
[14:43] <cnf> well, i was asking in juju how to have juju place things on the right server, because not every server has / should have an ip in every vlan
[14:43] <cnf> and i got pointed to spaces
[14:43] <cnf> (my main goal is deploying openstack with juju btw)
[14:43] <pmatulis> roaksoax, so you want "A fabric is a switch or a set of switches." ?
[14:43] <roaksoax> pmatulis: we can clarify the terms later, but just pointing out that the term in ther is actually ckinda referring to spaces
[14:44] <mup> Bug #1673087 opened: Save/Load Network and Storage Configurations <MAAS:Triaged> <https://launchpad.net/bugs/1673087>
[14:44] <mup> Bug #1673091 opened: Tags with dots are not saved <error-surface> <MAAS:Triaged> <https://launchpad.net/bugs/1673091>
[14:44] <cnf> ok, so i should move everything back into fabric-0 then
[14:44] <cnf> i think
[14:49] <pmatulis> roaksoax, comes from here: http://bazaar.launchpad.net/~maas-committers/maas/2.1/view/head:/docs/networking.rst
[14:50] <wargamez> roaksoax: Yes for autopilot. I am not able to connect to maas 2.X with it it says 401 gone. Is there a maas 1.9 for ubuntu 16.04 available somewhere?
[14:50] <pmatulis> roaksoax, please open a doc bug on it with specifics
[14:51] <cnf> it has the same info text in the GUI btw
[14:51] <roaksoax> wargamez: i dont think it is released, but they have been working on it
[14:52] <cnf> hmm, what a mess :P
[14:52] <roaksoax> cnf: note that fabrics / spaces is a design thing. If all your machines are in the same fabric, and all your machines are connected to the same 'untagged' vlan (i.e. all pxe boot on the same untagged vlan), then yes that sounds all your machines should be in the same fabric
[14:53] <cnf> roaksoax: i have a lot more vlans than that
[14:53] <roaksoax> cnf: is you have say X machines pxe boot on untagged vlanX and Y machines pxe boot on untagged vlanY, then it sounds you need 2 fabrics
[14:53] <cnf> but i have 1 vlan just for MAAS
[14:53] <roaksoax> cnf: yeah just an exmape :)
[14:53] <cnf> but here, everything is one switch
[14:53] <cnf> well, about 5 switches, but they behave as 1
[14:54] <cnf> ignoring the vmware distributed vswitches etc
[14:54] <cnf> hmm
[14:54] <cnf> what are the concequenses of having different fabrics?
[14:55] <cnf> (seems i can't move VLAN's between fabrics)
[14:57] <cnf> so you would have a fabric per top of rack switch, for example, but all pxe boot vlan's would be in one space?
[14:57] <cnf> or am I misunderstanding this?
[14:58] <roaksoax> cnf: i sec, otp
[14:59] <cnf> sure
[15:03] <roaksoax> cnf: ok, sorry about that.
[15:03] <roaksoax> cnf: say you have this:
[15:03] <roaksoax> MAAS (region/rack) -- switch1 -- node01
[15:03] <roaksoax>                    -- switch2 -- node02
[15:03] <roaksoax>                    -- switch3 -- node03
[15:04] <roaksoax> cnf: and node01/node02/node03 can talk to each outher in the same vlan
[15:04] <roaksoax> cnf: and PXE boot from MAAS in the same vlan, from the same subnet
[15:04] <roaksoax> cnf: then that would be 1 fabric
[15:05] <roaksoax> cnf: i guess the right term would be that all those 3 switches are trunked
[15:06] <cnf> right
[15:07] <cnf> i'm not sure when to use different fabrics, i guess
[15:07] <cnf> as opposed to using spaces
[15:07] <cnf> roaksoax: so if you had a VLAN for pxe booting and maas mgmt, and one for storage traffic, would those be different fabrics?
[15:07] <cnf> when they are on the same switch
[15:08] <roaksoax> cnf:
[15:08] <roaksoax> MAAS eth0-10.10.10.2 -- switch1.fabric0.untagged -- node01.eth0    -- 10.10.10.10
[15:08] <roaksoax>                                 fabric0.vlan10   -- node01.eth0.10 -- 192.168.10.20
[15:08] <roaksoax>                      -- switch2.fabric0.untagged -- node02
[15:08] <roaksoax>                      -- switch3.fabric0.untagged -- node03.eth0    -- 10.10.10.11
[15:08] <roaksoax>                                 fabric0.vlan10   -- node03.eth0.10 -- 192.168.10.21
[15:08] <cnf> ok
[15:13] <roaksoax> MAAS eth0-10.10.10.2 -- switch1.fabric0.untagged -- node01.eth0    -- 10.10.10.10   -- space.undefined
[15:13] <roaksoax>                                 fabric0.vlan10   -- node01.eth0.10 -- 192.168.10.20 -- space.test
[15:13] <roaksoax>                      -- switch2.fabric0.untagged -- node02
[15:13] <roaksoax>                                 fabric0.vlan20   -- node02.eth0.20 -- 192.168.20.21 -- space.storage
[15:13] <roaksoax>                      -- switch3.fabric0.untagged -- node03.eth0    -- 10.10.10.11   -- space.undefined
[15:13] <roaksoax>                                 fabric0.vlan10   -- node03.eth0.10 -- 192.168.10.21 -- space.test
[15:13] <roaksoax>                                 fabric0.vlan30   -- node03.eth0.30 -- 192.168.30.21 -- space.storage
[15:13] <roaksoax> cnf: or the above too
[15:14] <roaksoax> cnf: so in maas 2.2+ L2 spaces, you can have vlan20 and vlan30 in the same space, each with different subnets, and you are saying basically that machjines in vlan30 and machines in vlan20 can communicate to each other
[15:14] <roaksoax> cnf: on thjose subnets via those spaces
[15:15] <cnf> ok
[15:15] <cnf> so do i need separate spaces for ipv4 or ipv6 ?
[15:16] <roaksoax> cnf: no necessarily, you can have both ipv4/ipv6 subnets in the same vlan
[15:16] <cnf> but in the same space?
[15:16] <cnf> because technically, they can't communicate :P
[15:17] <cnf> hmm, but spaces are per vlan, of course
[15:17] <roaksoax> yeah, so you can have ipv4/ipv6 on vlan10 and ipv4.1/ipv6.1 in vlan20, both in the same space
[15:17] <roaksoax> what you are saying there is, ipv4 on vlan10 can communicate with ipv4.1 in vlan20
[15:17] <cnf> ok
[15:17] <roaksoax> the same for ipv6
[15:17] <cnf> so when would you use different fabrics?
[15:19] <roaksoax> cnf: when you have infrastructure that you dont want it to communicate with each other
[15:19] <roaksoax> cnf: for example, you can have 2 different openstack clouds, each on their own fabric
[15:19] <cnf> hmm, ok
[15:19] <roaksoax> cnf: the isntances could communicate to each other because they are "public" addresses
[15:19] <cnf> and have the same vlans with the same subnets, but there is no link between the 2?
[15:20] <cnf> right
[15:22] <cnf> ok, i'm going to have to jiggle some things around
[15:22] <cnf> roaksoax: thanks
[15:23] <roaksoax> cnf: this may help a bit too: https://docs.ubuntu.com/maas/devel/en/release-notes#important-announcements_1
[15:49] <cnf> hmm
[15:57] <ThiagoCMC> Hey guys, does the PXE boot stuff works on top of tagged vlans? Like: "eth0.100"? While just eth0 is the regular "ubuntu maas" IP, for accessing its UI, ssh into it, etc...
[15:59] <ThiagoCMC> The server was PXE booted by MaaS, but the commisioning is faling: "Could not query power state: Connection timed out while performing power action.  Check BMC configuration and connectivity and try again.."
[15:59] <ThiagoCMC> not sure what to do...   =/
[15:59] <ThiagoCMC> I changed the "power user / pass", to Dell's default but, still doesn't work... I can use those same user/pass on iDrac.
[16:00] <rainmaker> anyone here installed openstack? how did you have success? using autopilot or juju deploy openstack-base?
[16:01] <roaksoax> rainmaker: last time i did was with conjure-up and maas 2.2
[16:01] <roaksoax> ThiagoCMC: if the bios handles it, it should yes
[16:02] <rainmaker> roadsoax: i used conjure-up for deploying it on a single laptop.. but will it still work for a production enviornment?
[16:03] <ThiagoCMC> Hmm... Double checking BIOS settings... Thanks!
[16:03] <ThiagoCMC> =)
[16:11] <mup> Bug #1673135 opened: [2.2b3] Machine fails to deploy , but install log is not immediately stored. <MAAS:Triaged> <https://launchpad.net/bugs/1673135>
[16:13] <cnf> hmz
[16:13] <cnf> what a mess :P
[16:15] <ThiagoCMC> roaksoax, "iDRAC -> iDRAC Settings -> Network/Security -> Network -> IPMI Settings [x]Enable IPMI Over LAN" - Worked! Thanks man!
[16:24] <cnf> roaksoax: i can't pick what vlan to assign in a fabric on a node
[16:24] <cnf> it's grayed out, and only the 1st one is selected?
[16:26] <zeestrat> rainmaker: I'd look at building your own bundle either from the base examples from https://github.com/openstack-charmers/openstack-bundles or something like this HA example: https://launchpadlibrarian.net/298175262/bundle.yaml
[16:28] <zeestrat> rainmaker: My experience is that openstack is just not something that is going to work out of the box so we needed to take a moment to look at all the components.
[16:30] <Budgie^Smore> zeestrat, I would say that Conanical has made it pretty easy to get a basic clean openstack cluster to work out of the box, my biggest issue with it was (and also my weakness) setting up the servers networking correctly to handle all the different VLANs
[16:34] <zeestrat> Budgie^Smore: Oh, absolutely. My recommendation is just to take a moment and think about the normal things such as storage and network as the latter usually never works automagically.
[16:34] <cnf> hmm
[16:35] <cnf> i seem to have painted myself into a corner
[16:35] <cnf> "Can't delete fabric; the following interfaces are still connected: eth0 (unknown) on <unknown-node>, eth0 (unknown) on <unknown-node>"
[16:35] <cnf> i don't seem to have said nodes...
[16:41] <cnf> hmz, how the hell do i clean this up
[16:44] <cnf> postgres stuff it is :/
[16:49] <cnf> hmm, so my database is inconsistent
[16:49] <cnf> already?
[16:49] <cnf> how the hell did that happen :/
[16:51] <cnf> anyone proficient enough with maas to help me clean this up?
[16:52] <roaksoax> mpontillo: ^^ :)
[16:57] <Budgie^Smore> zeestrat oh yeah, you definitely have to get your network layer setup correctly for things to go smoothly. http://blog.naydenov.net/2015/11/deploying-openstack-on-maas-1-9-with-juju-network-setup/ is a walk through that I used when I deployed my first openstack cluster
[16:59] <cnf> https://bpaste.net/show/b761a057d1c7
[16:59] <cnf> that looks wrong...
[16:59] <cnf> no node_id
[17:00] <cnf> and why can't i pick the vlan on an interface?
[17:01] <cnf> https://www.dropbox.com/s/m971jqnq8mve3be/Screenshot%202017-03-15%2018.01.03.png?dl=0
[17:01] <cnf> should the VLAN field be grayed out?
[17:04] <cnf> hmz
[17:04] <Budgie^Smore> cnf I think that VLAN is associated with the fabric so it would make sense to grey it out
[17:04] <cnf> Budgie^Smore: there are 5 vlans associated with that fabric
[17:05] <cnf> and the one selected is NOT the one i want
[17:06] <cnf> hmz, i don't understand this ^^;
[17:09] <Budgie^Smore> does maas allow multiple subnets / vlan?
[17:10] <mpontillo> cnf: let me take a step back: what specific version of MAAS are you using? (latest in the 2.2 or 2.2-beta series, I imagine?)
[17:10] <mpontillo> Budgie^Smore: yes, you can have multiple subnets in a VLAN
[17:10] <cnf> mpontillo: whatever was default 3 weeks ago for "apt install maas" on 16.04 :P
[17:10] <cnf> uhm,
[17:10] <cnf> MAAS Version 2.1.3+bzr5573-0ubuntu1 (16.04.1)
[17:12] <mpontillo> cnf: ok, thanks. the following query might help us understand why you have stray interfaces on your fabric. https://gist.github.com/mpontillo/94b227942fbcfc79dcad5124927ca9d9
[17:12] <mpontillo> cnf: use "sudo maas-region dbshell" to get a postgres console, then do "\pset pager off"
[17:12] <cnf> i'm already on
[17:14] <cnf> let me sanitize some ip addresses
[17:14] <mpontillo> cnf: another useful query is "select * from maas_support__node_networking;" (that's a view) -- but it's more node-centric, and it sounds like unknown interfaces are the issue for you, which are created in certain cases when we don't have a specific node
[17:15] <mpontillo> cnf: my guess is they're from leftover DHCP leases that MAAS was notified about, and the fact that you can't delete the fabric because of them is a bug
[17:15] <cnf> mpontillo: https://bpaste.net/show/8c98a8f22394
[17:16] <cnf> the last query doesn't have any reference to the floating interfaces
[17:21] <cnf> mpontillo: so i decided to keep the fabric in question., but i still think it's nasty to have this problem
[17:21] <cnf> any suggestions on how to clean it up?
[17:21] <mpontillo> cnf: I was just about to give you a workaround to clean up all the unknown interfaces so you could delete the fabric. https://gist.github.com/mpontillo/1a6faee09fe674c62dbaab27eb9164f4
[17:22] <cnf> nice
[17:23] <mpontillo> cnf: though if that is fabric-0 I'm honestly not sure if we'll let you delete it; that might be the "default fabric", let me know ;-)
[17:23] <cnf> that seems to have done it, i think
[17:23] <mpontillo> cnf: ok cool
[17:23] <cnf> it wasn't 0
[17:23] <cnf> so
[17:23] <cnf> uhm
[17:23] <cnf> mpontillo: what happened is i misunderstood fabrics from the docs
[17:23] <cnf> and configured them as spaces
[17:24] <cnf> then later learned i should have used spaces for this, so i made the right spaces
[17:24] <cnf> and tried to put everything on fabric-0 again
[17:24] <cnf> which is when i ran into this
[17:24] <mpontillo> cnf: yeah, we think of fabrics as basically an interconnected set of (non-virtual) switches; traditional switches in which you might use 802.1q VLANs on -- it sounds like you have vswitches in your environment though?
[17:24] <cnf> then i learned that a "fabric" is what is on a "cable" really
[17:24] <cnf> mpontillo: yeah
[17:25] <cnf> it's a juniper qfabric
[17:25] <cnf> with most things on a 2 x 10g LAG
[17:25] <cnf> but i never did figure out how to pxe boot from a LAG interface
[17:25] <cnf> so the maas network is on a separate copper cable, from the same qfabric, really
[17:25] <mpontillo> cnf: OK, I'd like to better understand your environment; if you don't mind me asking, are you using MAAS on physical or virtual hardware? is this a production or demo/staging type environment?
[17:26] <cnf> tis is a PoC atm, to evaluate using MaaS / juju to install / manage openstack
[17:26] <cnf> the MAAS controller is on a VM, the rest are physical machines
[17:26] <cnf> (PoC is Proof of Concept if you where not familiar with the TLA)
[17:27] <mpontillo> OK, sounds good, yes I know that one ;-)
[17:27] <cnf> so _normally_ we have 1 copper network (100mbit) for IlO / IPMI access
[17:27] <cnf> and everything else on optical LAGs
[17:28] <cnf> but as said, i never found out how to pxe boot on the LAG, so i added a copper network for the MAAS network
[17:28] <cnf> it's the same virtual switch, but a separate connection to the machines
[17:29] <mpontillo> cnf: all right. so you may have two or three VLANs, but it may look like two or three fabrics to MAAS?
[17:29] <mpontillo> (it's fine to model it as three fabrics, btw, that will probably mean less headache if you aren't using VLAN tags anywhere)
[17:29] <cnf> so what i am learning, i think? is that a fabric isn't a switch, but really a "cable" connected to the machine
[17:30] <mpontillo> cnf: we use a fabric to model a traditional switching infra with consistent VLAN tags inside. in your case, if you have three completely separate VLANs that can in no way communicate even by fiddling with the VLAN tags, then yeah, telling MAAS it's three fabrics will probably give you the best experience
[17:31] <mpontillo> cnf: if you have a switch with trunk ports configured where each host interface can retag traffic on the different VLAN IDs, then you'd want to use a fabric with multiple VLANs inside. but it doesn't seem like that's true in your env
[17:32] <cnf> well, it is on the fibers
[17:32] <cnf> the LAG is a trunk
[17:32] <mpontillo> cnf: okay, then I would model the LAG's VLANs if you want the deployed nodes to be able to configure VLAN interfaces on them
[17:33] <cnf> so atm i have fabric-0 with all the VLAN's, a fabric-maas with the maas vlan, and a fabric-mgmt with carries the iLo / IPMI traffic
[17:33] <mpontillo> cnf: sounds good to me.
[17:33] <cnf> for the maas controller, this looks like a separate interface
[17:33] <cnf> the ipmi one, that is
[17:33] <mpontillo> cnf: that should be fine
[17:34] <cnf> cool
[17:34] <cnf> so, as I understand it
[17:34] <cnf> juju can't configure networking
[17:34] <cnf> i need to configure what i want on a machine in maas, and then juju gets to use what is there, right?
[17:37] <mpontillo> cnf: yes, that makes sense. so for juju what you might do first is define three spaces to start with: 'mgmt', 'maas', and 'aggregate' - since you're on MAAS 2.1, those would be assigned to each subnet MAAS knows about in those spaces
[17:38] <cnf> right
[17:38] <cnf> i also addes spaces for public, openstack-mgmt and openstack-storage
[17:39] <cnf> which are all in fabric-0
[17:39] <mpontillo> cnf: are you able to define 802.1q VLANs (based on VID) inside the LAG fabric? if so then you could define the VLANs and subnets in the 'aggregate' network you want to use with juju, and define spaces appropriate for those
[17:39] <cnf> right
[17:39] <cnf> mind if i past something in pm?
[17:40] <mpontillo> cnf: ok. in MAAS 2.1, spaces must be assigned to subnets, so if you've simply created the spaces they aren't really in use until you tell MAAS which subnets they're associated with (as mentioned earlier, in MAAS 2.2 they are migrating to VLANs)
[17:40] <mpontillo> cnf: sure, if you have sensitive pastes you'd rather not make public, feel free to PM them
[17:40] <cnf> it's public ip ranges
[17:40] <cnf> i'd rather not broadcast those :P
[17:41] <mpontillo> np
[17:41] <cnf> does that look sane?
[17:41] <mpontillo> cnf: yeah that looks good to me.
[17:42] <cnf> cool
[17:42]  * mpontillo likes the "Available IPs: 100%" next to your /64; I don't imagine that will change much over time ;-)
[17:48] <cnf> :P
[18:05] <cnf> mpontillo: ok, thanks for your help
[18:05] <cnf> i'm calling it a day
[18:05] <ThiagoCMC> Hey guys, how to configure MaaS in a way that it is not the gateway of the bare-metal servers?
[18:05] <cnf> 19:00 here, i'm getting hungry and a bit sleepy
[18:05] <ThiagoCMC> I tried to delete the gateway on DHCP config but, it reappears...
[18:06] <cnf> ThiagoCMC: each subnet lets you define a gatway, and cusom routes
[18:06] <ThiagoCMC> I want the PXE network to have no gateway, and another interface of the bare-metal boxes will be the gateway...
[18:06] <ThiagoCMC> Hmm...
[18:06] <ThiagoCMC> well, I just don't want the maas as a gateway, while keep it as metadata / cloud-init as usual.
[18:07] <mpontillo> ThiagoCMC: you can set the gateway per subnet
[18:07] <ThiagoCMC> How the bare-metal boxes will have 2 gateways without using iproute2 ?
[18:07] <ThiagoCMC> Or, does it uses iproute2 multiple tables?
[18:07] <ThiagoCMC> for each gateway?
[18:07] <ThiagoCMC> Or just metrics?
[18:08] <mpontillo> ThiagoCMC: well, iproute2 is used, but it's true that MAAS could handle overlapping default routes better. you can define static routes
[18:08] <mpontillo> or rather, overlapping routes in general. we've heard requests for policy based routing
[18:10] <mpontillo> ThiagoCMC: so let me see if I understand correctly. when you PXE boot you want to use the PXE network's default router for the gateway (such as to reach the Ubuntu archive, etc. but you have another interface you want to use for just about all other traffic (assuming it's online)?
[18:11] <mpontillo> ThiagoCMC: when you say "I want the PXE network to have no gateway"... that's okay, but I see how that could be problematic with MAAS since during enlistment, commissioning, and deployment we won't bring up your data-plane interfaces
[18:19] <roaksoax> you can already achieve that
[18:19] <roaksoax> you cant two default gateways for a machine
[18:20] <ThiagoCMC> I know, with iproute2, you can...   =)
[18:20] <roaksoax> if you have a pxe network with the default gateway that is different from having gateway for other eoutes
[18:20] <roaksoax> or viceversa
[18:20] <mup> Bug #1673204 opened: LXD not getting IP address, MAAS 2.2b3 throwing django.db.utils.IntegrityError and  AssertionError <MAAS:New> <https://launchpad.net/bugs/1673204>
[18:21] <ThiagoCMC> mpontillo, oh, I see how that enlistment / deployment can be problematic...
[18:21] <roaksoax> sounds like you need to define your default gatewat forst and then configure routes for other places
[18:48] <zeho> I'm trying to figure out why i'm unable to deploy autopilot from my maas server with juju. I'm looking at the commands.log file and ls
[18:49] <zeho> and I can't tell what is wrong. What I do see is the following:
[18:49] <zeho> [ERROR: 03-15 13:19:34, gui.py:270] Problem with juju bootstrap.
[18:49] <zeho> Traceback (most recent call last):
[18:49] <zeho>   File "/usr/lib/python3.4/concurrent/futures/thread.py", line 54, in run
[18:49] <zeho>     result = self.fn(*self.args, **self.kwargs)
[18:49] <zeho>   File "/usr/share/openstack/cloudinstall/controllers/install/multi.py", line 146, in do_install
[18:49] <zeho>     raise Exception("Problem with juju bootstrap.")
[18:49] <zeho> Exception: Problem with juju bootstrap.
[18:49] <zeho> [DEBUG: 03-15 13:19:34, error.py:35] showing error view for: Problem with juju bootstrap.
[18:49] <zeho> [ERROR: 03-15 13:19:34, task.py:71] ran off end of task list, can't start Bootstrapping Juju
[18:49] <zeho> [DEBUG: 03-15 13:19:34, utils.py:627] ssh keys exist for this user, they will be used instead.
[18:49] <zeho> [DEBUG: 03-15 13:19:34, multi.py:139] Bootstrapping Juju: JUJU_HOME=/home/maasadmin/.cloud-install/juju juju  bootstrap  --to autopilot
[18:49] <zeho> [DEBUG: 03-15 13:19:35, multi.py:145] Problem during bootstrap: '{'err': 'WARNING ignoring environments.yaml: using bootstrap config in file "/home/maasadmin/.cloud-install/juju/environments/maas.jenv"\nWARNING This juju environment is already bootstrapped. If you want to start a new Juju\nenvironment, first run juju destroy-environment to clean up, or switch to an\nalternative environment.\nERROR environment is already bootstrapped\n', 'o
[18:49] <zeho> utput': '', 'status': 1}'
[18:58] <firl> anyone on that might be able to help me understand the best way to integrate mellanox into a node for maas 2.1?
[20:08] <mpontillo> firl: what do you mean by "integrate mellanox"?
[20:09] <firl> when I commission a host that I can see an ip over ib in the networking
[20:10] <firl> mpontillo: I know a year ago it wasn’t at a place to be able to do it. I wasn’t sure if things have changed
[20:11] <mpontillo> firl: sorry, I may not be up to date on the terminology for this, but what is "ip over ib"? for MAAS 2.2 I worked on some switch ASIC identification code that runs during commissioning; we have the ability to deploy onto switches, but it can get complex depending on what you want to do
[20:12] <firl> sure, infiniband = ib. The drivers that require installation are 3rd party for them to be recognized during commissioning.
[20:12] <firl> so the IPoIB is just ethernet over infiniband ( mellanox )
[20:14] <wililupy> firl: can you give me some info on your setup?
[20:14] <mpontillo> firl: ah, I see what you mean now. mellanox being a vendor that makes lots of different things it didn't click that you were talking about InfiniBand, sorry. MAAS currently only models Ethernet interfaces, so IB cannot be fully supported, unless you can PXE boot from a non-IB interface and run a script post-deployment to configure IB
[20:14] <firl> I can do that
[20:14] <firl> is there a way to do a post-deployment script during commissioning?
[20:15] <firl> every host has, 1 pxe net, 1 ipmi net, a 20gb bonded interface, and a dual 54 mellanox port card
[20:15] <mpontillo> firl: yes, on the settings page you can upload a custom commissioning script. but doing so may not help since your IB interfaces won't have 6-byte MAC addresses and it's not likely that the MAAS commissioning script will do anything with them. if you're okay with MAAS not knowing about your IB devices, that would be easier (though undesirable for other
[20:15] <mpontillo> reasons)
[20:16] <wililupy> firl: When I did this, I had the power control set to my DLI PDU to manage power up/down/status since there is no power control on mellanox switches.
[20:16] <firl> ya
[20:16] <wililupy> You also need to set PXE as default boot. and set a tag up in MAAS for the serial console so that you can manage it:
[20:17] <firl> ya that’s already all configured
[20:17] <firl> idrac technically but ya
[20:17] <wililupy> maas admin tags create name=mellanox-sn2700 kernel_opts="console=tty0 console=ttyS0,115200n8"
[20:18] <firl> wililupy mpontillo: so comissioning is one thing, what about deployment when I deploy a node how do I have a 3rd party script run to init the interfaces ?
[20:18] <firl> so that I can have juju use it
[20:20] <mpontillo> firl: I would do that with a custom curtin_userdata script (found in /etc/maas)
[20:20] <firl> ok, I will digest this. It might be a few weeks before I will have time to do something that in depth
[20:25] <mpontillo> firl: sure. sorry, I meant /etc/maas/preseeds -- and you can have more specific files in there if you want, such as "curtin_userdata_amd64_generic_xenial_myhostname" which would match Xenial deployments [with a generic kernel] to AMD64 machines, where the hostname is "myhostname"
[20:25] <mpontillo> firl: you should be able to leave off the [_X] pieces if you want to write a more generic preseed YAML
[20:26] <firl> nice, yeah I can do a bash script check to see if the device exists on the system
[20:27] <firl> the hangup for juju to be able to use it originally was that it required post configuration and juju wouldn’t recognize it because it was running before the post configuration could go
[20:27] <firl> so I think this could work, not easily managed in a gui, but still work quite nicely
[20:31] <mpontillo> firl: yeah, most people just use the GUI for the initial setup and then automate everything from there AIUI
[20:32] <firl> ya
[20:32] <firl> for the people I need to hand off to, gui’s are easier to understand hah
[20:32] <mpontillo> firl: we do have a facility for custom drivers as well (drivers.yaml) but there is a bug where it doesn't work properly in MAAS 2.1 which has been fixed in MAAS 2.2, and it is only for deployment, not commissioning. it can identify hardware by PCI ID and add a custom repo with a DKMS module
[20:32] <firl> oooo
[20:32] <mpontillo> firl: other issue with doing it that way is the movement away from DKMS and toward UEFI boot with signed kernels
[20:33] <firl> yeah, I have bios boot for everything because it is more supported
[20:33] <firl> changing the bios on the 50 machines I help manage is a pain
[21:06] <kklimonda> I've been seeing this issue randomly over the last few deployments: https://launchpad.net/bugs/1673204 - is there something I can do to debug it further?
[21:08] <kklimonda> wow, I just read the code that is failing