[00:31] <maileh> roaksoax: anything you might suggest and i have'nt recieved anything after filing the bug
[00:52] <maileh> this is another extract from Commission Summary hw:setting:                 id: modified                 value: 2016-03-14 22:24:35               - lshw:setting:                 id: mount.fstype                 value: ext4               - lshw:setting:                 id: mount.options                 value: ro,relatime,data=ordered               - lshw:setting:                 id: mounted ....looks like it is OK
[00:54] <maileh> roaksoax: anything yet ???
[01:33] <mup> Bug #1576468 opened: APC Power Driver - NoneType' object has no attribute 'decode' <MAAS:Triaged by newell-jensen> <MAAS 1.9:Triaged by newell-jensen> <https://launchpad.net/bugs/1576468>
[02:40] <maileh> alexlist: can you help with my issue
[02:58] <maileh> helo anyone online now ???
[03:05] <maileh> helo
[07:54] <maileh> hellow
[07:55] <DavidRama> hello
[07:58] <maileh> hi david .... are you able to help my issue
[07:59] <maileh> MAAS successfully commisioned my two nodes yet it shows error on my machines detail page on storage section saying that i need to commossion my nodes before disk can be setup
[08:01] <maileh> david: ????
[09:50] <DavidRama> maileh: sorry I'm new to that also
[15:38] <mup> Bug #1576758 opened: [2.0b3] IP Ranges section on the subnet page should be shown even if no ranges <MAAS:New> <https://launchpad.net/bugs/1576758>
[17:53] <bdx> hey whats up everyone?
[17:54] <bdx> will beta -> stable upgrades be supported?
[17:54] <bdx> for maas2.0
[17:55] <roaksoax> bdx: upgradability is a primary focus for maas
[17:55] <roaksoax> bdx: but yes, you'll be able to upgrade from beta to final without issues
[18:04] <bdx> roaksoax: awesome, thanks
[18:05] <bdx> roaksoax: when are you guys planning on dropping beta4?
[18:06] <roaksoax> bdx: we are testing right now
[18:06] <roaksoax> bdx: and waiting for a couple bug fixes to land
[18:07] <bdx> roaksoax: right on, will beta4 have improved functionality for lxd/lxc networking?
[18:07] <roaksoax> bdx: that actually comes from Juju
[18:07] <roaksoax> bdx: since MAAS doesn't really deploy lxd containers
[18:08] <roaksoax> bdx: but yes, maas 2.0 w/ juju 2.0 should have better lxd container networking
[18:08] <bdx> roaksoax: doesn't maas provision the network interfaces on containers though?
[18:09] <roaksoax> bdx: not for containers
[18:09] <bdx> ok
[18:10] <roaksoax> bdx: so since MAAS 1.8+ i think we supported registering containers , but juju never used the feature by default
[18:10] <roaksoax> bdx: maas ensures that IP addresses are reserved for the container and specific interface and such
[18:10] <roaksoax> bdx: but juju never used the feature by default
[18:10] <roaksoax> bdx: when you enabled it, juju didn't write e/n/i for the container, so maas would deliver everythin via DHC{
[18:10] <roaksoax> bdx: when you enabled it, juju didn't write e/n/i for the container, so maas would deliver everythin via DHCP
[18:11] <roaksoax> bdx: but since MAAS doesn't really provision the container, it cannot write e/n/i for it
[18:11] <bdx> totally
[18:11] <bdx> but the container gets its provisioning metadata from MAAS yea?
[18:11] <roaksoax> bdx: so, supposedly, Juju 2.0 will enable container registration in MAAS by default, and correctly e/n/i
[18:11] <roaksoax> bdx: but haven't tested yet
[18:11] <roaksoax> bdx: nope, conatiner gets everything from juju, other than the IP addresses
[18:12] <roaksoax> bdx: basically, juju just says "register a device under machine XYZ, and I want IP addresses for A, B, C interfaces/mac addresses"
[18:12] <bdx> I see
[18:12] <roaksoax> bdx: and maas returns that info, and juju creates the container, and configures it as ti should
[18:12] <bdx> but how does juju/maas know what interface to attach the container to?
[18:13] <roaksoax> bdx: so say in a machine you configured eth0 to subnet1, eth1 to subnet2
[18:13] <roaksoax> bdx: when you deploy a machine, juju asks for a machine in subnet1/subnet2
[18:13] <roaksoax> bdx: and if you want your container in subnet1
[18:13] <roaksoax> bdx: it puts it in subnet1
[18:14] <roaksoax> bdx: so MAAS provides the interfaces juju needs to do that
[18:14] <bdx> I see, do you know where this code lives, does it exist yet?
[18:14] <roaksoax> bdx: putting it on a different way, MAAS provides juju with information about the phisical world, so juju can do stuff
[18:15] <bdx> totaly
[18:15] <roaksoax> bdx: on juju, I don't know where it lives
[18:15] <bdx> ok
[18:15] <roaksoax> bdx: on maas, we do it via constraints
[18:15] <roaksoax> mpontillo: ^^ where are the network constraints ?
[18:15] <bdx> but if no constraints are passed, is a default used?
[18:15] <roaksoax> bdx: yeah if no constraints are passed, juju just takes the first interface of MAAS IIRC
[18:18] <bsod90> hey guys! I have a question: when maas is deploying one of my nodes which has 2 NICs connected to 2 different networks, both enabled, one getting IP from MAAS DHCP, another one from the other network DHCP. How does it decide which default route to set? I'd like it to always point to our company network rather that management one, but I'm feeling like it's set just randomly.
[18:20] <bdx> bsod90: your machine will use the last gateway route configured
[18:20] <bdx> bsod90: I get around that by not setting the gateway in my subsequent dhcp configured interfaces
[18:20] <roaksoax> bsod90: you can set that in maas : maas <session> node-interface set-default-gateway
[18:21] <bdx> roaksoax: I see, what if your interfaces can't talk on the same net?
[18:21] <bdx> similar to my situation
[18:21] <roaksoax> bdx: then this may solve your problem? https://bugs.launchpad.net/maas/+bug/1519828
[18:21] <roaksoax> :)
[18:21] <roaksoax> bdx: we might do that for 2.1
[18:22] <bdx> if I set dhcp on multiple subnets using maas, my nodes error when pxe booting due to getting dhcp from the wrong subnet
[18:23] <bsod90> I see. Thank you, bdx and roaksoax
[18:23] <bdx> roaksoax: so, I just configured 3rd party dhcp <- also doesn't set the gateway on subsequent interfaces
[18:23] <mpontillo> roaksoax: bdx: when you use the "machines allocate" endpoint you can specify a list of constraints (should be documented in the normal way the APIs are doc'd)
[18:23] <roaksoax> bdx: you are setting DHCP on multiple subnets under the same VLAN ? or different VLANs ?
[18:23] <mpontillo> roaksoax: bdx: you can also use the "verbose" and "dry_run" options on that endpoint to experiment with constraints and see a little more info
[18:24] <bdx> different vlans
[18:24] <bdx> mpontillo: oooh thats awesome
[18:24] <mpontillo> roaksoax: bdx: basically when that API returns you will see a "constraints_by_type" object on the node, specifying which storage or interface constraints matched what you specified
[18:24] <roaksoax> bdx: so that means the machine has eth0 and eth1, eth0 being PXE, but it DHCP's from the range that is supposed to be on a different VLAN to where the node has been connected to ?
[18:25] <roaksoax> bdx: and physically, they are different 'untagged' VLANs or the same VLAN in the switch?
[18:25] <bdx> roaksoax: I can replicate in all scenarios ...
[18:26]  * mpontillo steps out for lunch
[18:27] <bdx> roaksoax: a node with multiple interfaces, each interface gets dhcp from maas on different vlan and subnet
[18:27] <bdx> it hasn't made a difference whether the vlans are on separate switches, I disallow all comms from one to the other at the router level
[18:28] <roaksoax> bdx: right, but in MAAS you do that by enabling DHCP on different vlans on the same fabric, or same VLANS (for example, untagged), on different fabrics
[18:29] <bdx> roaksoax: entirely
[18:29] <roaksoax> bdx: so say, fabric0->untagged->subnet1 fabric1->untagged->subnet2
[18:29] <roaksoax> bdx: and fabric0/fabric1 is a different collection of switches
[18:29] <roaksoax> anyway
[18:29] <roaksoax> i'm giuessing this may be the issue with isc-dhcp we have a bug for
[18:30] <bdx> roaksoax: I see, yea, but how do you stop maas from handing out pxe on non mgmt subnets?
[18:31] <bdx> I think that is (at a high level) the root issue
[18:32] <roaksoax> bdx: oh so you mean you dont want to provide a next-server in certain subnet's range ?
[18:32] <roaksoax> bdx: can you file a bug for that ?
[18:32] <bdx> roaksoax: entirely, provide dhcp, but not next. but I don't know how to make that happen within the context of maas
[18:33] <bdx> yea
[18:33] <roaksoax> bdx: i was thiking about that couple weeks ago
[18:33] <roaksoax> bdx: but completely forgot about it :)
[18:33] <bdx> yea, its been biting me since 1.7
[18:33] <roaksoax> bdx: but yes, I do think it makes sense. You may want to enable DHCP on VLAN1, but not specifically for PXE, just for machines to get IP'sl from there
[18:33] <roaksoax> bdx: but in 1.9/2.0 you do know you don't really need to set DHCP for a NIC that's not management ...
[18:34] <roaksoax> bdx: you can allow maas to configure e/n/i for that interface, in the subnet you want
[18:34] <roaksoax> bdx: which is not "management"
[18:35] <bdx> so, what you are saying basically, is that the work around is to use other methods than dhcp to configure subsequent interfaces ?
[18:35] <bdx> I see
[18:36] <roaksoax> bdx: right, so say eth0 (pxe) -> fabric0 -> subnet1 -> auto-assign -> this would be NIC for the management netework
[18:36] <roaksoax> bdx: but then, eth1 -> fabric1 -> subnet1 -> auto-assign
[18:36] <roaksoax> bdx: maas would automatically pick an IP on subnet1
[18:37] <roaksoax> bdx: so you could even do:
[18:37] <roaksoax> eth0 (pxe) -> fabric0 -> untagged -> subnet1 -> auto-assign
[18:37] <bdx> Ahhh, auto-assign does not use dhcp?
[18:37] <roaksoax> eth1.1 -> fabric0 -> vlan1 -> subnet2 -> auto-assign # no DHCP is enabled in VLAN10, but MAAS will automatically pick an IP on subnet2
[18:38] <bdx> entirely
[18:38] <roaksoax> bdx: starting from 2.0, DHCP is really only used for enlistment and commissioning
[18:38] <bdx> ahhh, I see. Well that basically solves the issue
[18:38] <roaksoax> bdx: (same is the case for 1.9, but we had static ranges in the past, MAAS 2.0 no longer has static ranges)
[18:38] <bdx> I see that
[18:39] <roaksoax> bdx: but the bug you mention, about allowing to enable DHCP without PXE is completely valid
[18:39] <bdx> ok, I'll file it
[18:39] <roaksoax> thanks!
[18:39] <bdx> so, while I've got your attention .... the other issue that has caused a great deal of contention for me is disk replacement
[18:40] <bdx> I'm sure you are familiar with the issues surrounding disk replacement ?
[18:40] <roaksoax> bdx: meaning, you have a machine deployed, disk failed, you want to replace it, but want to keep your machine deployed, and not release it and recommission /
[18:40] <roaksoax> ?
[18:40] <bdx> exactly
[18:41] <roaksoax> bdx: yes, I've heard about the issue
[18:41] <roaksoax> we currently not support that yet, but I'll definitely raise that
[18:41]  * roaksoax takes note
[18:41] <bdx> if I reboot with out recommissioning, my disks numbering get out of whack and I endup borking the node
[18:41] <bdx> thank you
[18:42] <bdx> this has caused me multiple trips to the datacenter, and has been probably the lagest point of contention I've had using MAAS to date
[18:42] <bdx> I appreciate you looking into it
[18:42] <bdx> I filed a bug a while back .... let me see if I can't dig it up
[18:43] <roaksoax> bdx: np! the only issue I can think related to that, is that the new disk won't have the same partitioning as maas think the disk has
[18:43] <roaksoax> but we can definitely explore that and see if that lands in the roadmap for 2.1
[18:45] <bdx> yea, so, I can't get maas to recognize the new disk w/o recommissioning, the os will reletter the disks upon reboot, and then maas has a new /dev/sda, that wasn't previously sda :-(
[18:46] <bdx> the os does at least
[18:46] <bdx> maas retains the previous disk assignments
[18:46] <bdx> and thus the issue
[18:46] <bdx> thanks for hearing me out
[18:47] <roaksoax> bdx: yeah, I know what you mean. We've talked about that before indeed
[18:48] <roaksoax> bdx: maas doesn't have a way to discover current partitioning
[18:48] <roaksoax> so maas would need to grow a way to enter into a maintenance mode while deployed
[18:48] <roaksoax> and do a "recommission"
[18:48] <roaksoax> but force the user to re-partitioning
[18:48] <roaksoax> and maas would just update the knowledge it has about disks
[18:48] <roaksoax> or something along those lines
[18:48] <bdx> entirely, that would be HUGE
[18:49] <bdx> I feel like MAAS deployed storage nodes are ticking timebombs to that affect
[18:49] <roaksoax> yeah I'll bring that up when we discuss MAAS roadmap next
[18:50] <bdx> SUPER!
[18:53] <bdx> the CIO of my company constantly brings up the storage thing as a downside to implementing MAAS in production ... you can use that as firepower if you want
[18:54] <roaksoax> bdx: hehe, don't worry it is already added in the ideas section
[18:54] <roaksoax> but will use that as feedback from the field
[19:12] <Chuckuzzo> using version 1.9.1, MAAS CLI to assign a VLAN to a space.  Getting "Too many Subnet objects match the given query"… any idea?
[19:18] <roaksoax> mpontillo: ^^
[19:19] <mpontillo> Chuckuzzo: can you pastebin the exact command you're using?
[19:19] <mpontillo> (or just paste it, should be short) ;-)
[19:20] <Chuckuzzo> maas mymaas subnet update vlan:50 name=public-api space=4 gateway_ip=10.50.0.1
[19:20] <Chuckuzzo> Following Dimiter's blog
[19:20] <Chuckuzzo> https://insights.ubuntu.com/2016/01/23/maas-setup-deploying-openstack-on-maas-1-9-with-juju/
[19:20] <mpontillo> Chuckuzzo: ah, yeah, it would be nice if that affected both subnets in that VLAN, come to think of it. but that's currently not how it works
[19:21] <mpontillo> Chuckuzzo: it seems that you need to narrow your subnet query so that it only matches a single subnet
[19:21] <Chuckuzzo> Would that be in MAAS setup or the OS network side?
[19:22] <mpontillo> Chuckuzzo: well, you can use the same command, but to place your subnet into that space use "ip:<any-ip-address-in-the-subnet>" for each subnet you want to place into the space
[19:23] <mpontillo> Chuckuzzo: in place of "vlan:50" that is
[19:23] <mpontillo> Chuckuzzo: or you can specify the subnet by ID, but that would require looking it up
[19:23] <Chuckuzzo> I'll give that a try
[19:32] <Chuckuzzo> That worked
[19:32] <Chuckuzzo> Many thanks!
[19:33] <mpontillo> Chuckuzzo: np
[21:06] <mup> Bug #1576854 opened: MAAS should be able to use power commands with rack controllers <MAAS:New for ltrager> <https://launchpad.net/bugs/1576854>