=== frankban|afk is now known as frankban
[08:53] <slevchenko> <brendand> slevchenko, which version of MAAS are you using? It's MAAS 2.0 I'm using and I want to assign salt-installation script to a group of nodes. Group may be any means, tags for example.
[08:56] <brendand> slevchenko, i *think* you would have to do that via the command line
[08:56] <brendand> slevchenko, you can use allocate to select a group of machines, then you would need to provide the script as a cloud-init user_data
[08:57] <brendand> i *think* - there might be an easier way
[08:57] <brendand> roaksoax, ^
[08:57] <roaksoax> you can also do post_install hooks in curtin
[08:57] <slevchenko> It's even better for me, but I can't find out how to do it. I was able to do it for a certain node
[08:57] <roaksoax> well, by preseeding in curtin
[08:58] <brendand> slevchenko, http://maas.ubuntu.com/docs2.0/api.html?_ga=1.143107125.1468356320.1463157245#machines
[08:58] <slevchenko> Yes I understand, there is only one problem for me, I need to do it for a group, not node wuith certain name
[08:58] <brendand> slevchenko, there is an operation 'allocate', you can provide some constraints
[08:58] <slevchenko> Oh thx, I'll try it
[09:00] <brendand> roaksoax, how do you do that? i don't see anything in the docs
[09:00] <roaksoax> brendand: api
[09:02] <brendand> roaksoax, the only references to 'curtin' i see in the api docs is to get the curtin config
[09:03] <brendand> and a 'curtin_verbose' config option
[09:05] <slevchenko> <brendand> slevchenko, you can use allocate to select a group of machines, then you would need to provide the script as a cloud-init user_data
[09:05] <slevchenko> One mor thing,  by *provide the script* you mean some sort of loop `for $machine in $allocated_mcachines; do user_data` or it's really possible to assign userdata for whole group with maas-cli ?
[09:15] <brendand> slevchenko, how are you deploying the machines?
[09:17] <slevchenko> At this moment I'm researching a proper method to do it. So right now, I just applying Ubuntu 16.04 button to nodes (discoverd through PXE) in UI and press 'deploy'
[09:19] <slevchenko> Right now my goal is to automate Salt-master setup, and then do batch salt-minions setup
[09:23] <slevchenko> https://maas.ubuntu.com/docs/development/preseeds.html If I undrstood correct it's possible up to certain node.
[09:23] <slevchenko> "{prefix}_{osystem}_{node_arch}_{node_subarch}_{release}_{node_name}" <- I mean this part
[09:25] <brendand> slevchenko, yeah. i'd probably only do that if modifying the preseed is necessary to get the machine to deploy
[09:25] <slevchenko> Is it possible for "{prefix}_{osystem}_{node_arch}_{node_subarch}_{release}_{node-group\tag\whatever}" ?
[09:25] <brendand> slevchenko, cloud-init is far more user-friendly if it's post-installation tasks you're after
[09:26] <slevchenko> So I'll need to modify cloud-init's bits and pieces directly, without invloving MAAS?
[09:27] <brendand> slevchenko, you should read up on cloud-init, it's like an extensible yaml based configuration framework
[09:27] <brendand> slevchenko, btw where have you seen the concept of 'node-group'?
[09:28] <brendand> ah, in 1.9
[09:29] <brendand> slevchenko, you'll notice that is no longer an object in the 2.0 api. it might have an analog, but i'm not sure
[09:29] <slevchenko> If memory serves me it was somewhere in cli help, let me check
[09:31] <brendand> it shouldn't be in 2.0
[09:33] <slevchenko> Yes it's not. But it was present in erlier versions, before update
[09:33] <brendand> slevchenko, 2.0 is a new major version, there are some quite fundamental changes to how maas works
[09:34] <slevchenko> So sole possible grouping concept is TAGS now, right ? Apart from domains, controllers etc
[09:38] <brendand> slevchenko, there is also 'zones', but that's really intended to be used for physical grouping of machines, not conceptual
[09:38] <brendand> slevchenko, so i would say use tags
[09:39] <slevchenko> Ok htx
[09:39] <slevchenko> *thx
[10:53] <slevchenko> Guys does anyone know, how to start a node from CLI in MAAS 2.0 ? Answers I found earlier seems to refer older versions
[10:57] <brendand> slevchenko, you first need to allocate it using 'machines allocate <some constraints>', then call its 'deploy' operation
[10:57] <brendand> let's say you have a machine with the tag 'foo'
[10:58] <brendand> maas profile machines allocate tags=foo
[10:58] <brendand> that returns one or more machines, then you need to find the system_id of the machine and do
[10:58] <brendand> maas profile machine deploy <system_id>
[11:00] <slevchenko> Thx, but this time I'm trying to do something like this: http://askubuntu.com/a/636867
[11:00] <slevchenko> script=$(base64 addkey.sh)
[11:00] <slevchenko> $ maas myuser node start node-79b67e82-d25c-11e4-a333-00163eca91de \
[11:00] <slevchenko>   user_data=$script distro_series=trusty
[11:01] <slevchenko> But in 2.0 'node' has no start,stop etc options
[11:01] <brendand> slevchenko, yes, exactly
[11:02] <brendand> slevchenko, start is now 'deploy'
[11:02] <slevchenko> So I'm trying to figureout how to do same thing in 2.0
[11:02] <slevchenko> and user_data=$script part ?
[11:03] <brendand> slevchenko, it's the same, you just use deploy instead of start
[11:03] <brendand> slevchenko, i gave you a link to the 2.0 api documentation
[11:04] <slevchenko> oh, is there any 2.0 documentation about that ?
[11:04] <brendand> slevchenko, yes - i did give you a link earlier, but here it is again: http://maas.ubuntu.com/docs2.0/api.html
[11:05] <brendand> slevchenko, but the command is essentially the same, just the system_id replaces the node id, and the command is called deploy, not start
[11:05] <brendand> oh, and the api is 'machine', not 'node'
[11:17] <slevchenko> Thanks Brendan
[11:19] <slevchenko> So can I use 'cloud-config' as my user_data right ?
[11:20] <brendand> slevchenko, i believe so, the provided file should look something like https://cloudinit.readthedocs.io/en/latest/topics/examples.html#yaml-examples
=== Kiall_ is now known as Kiall
=== haasn` is now known as haasn
[14:35] <Braven> I am working with a dell IDRAC. For the IDRAC the Maas web GUI is getting "Failed to query node's BMC — Power state could not be queried" errors
=== cmagina_ is now known as cmagina
=== jamespag` is now known as jamespage
[17:09] <zeestrat> Braven: Did you manage to fix your problem? If not, have you checked that IPMI is enable over LAN in the iDRAC settings?
[17:09] <zeestrat> Braven: Somewhere around here I think. iDRAC -> iDRAC Settings -> Network/Security -> Network -> IPMI Settings -> [x]Enable IPMI Over LAN
[17:09] <Braven> I can take a look at it
[17:10] <Braven> What is weird the drac finally works
[17:14] <pragsmike> braven is it enterprise iDRAC, or express iDRAC?
[17:14] <pragsmike> enterprise has the dedicated ethernet port, express shares the first host port
[17:15] <Braven> enterprise. It worked before but we had to rebuild the rack controller
[17:15] <Braven> because of DHCP issue with it
[17:17] <pragsmike> so you got it working then?
[17:18] <narindergupta> mbeierl, hi lets pose the query here?
[17:18] <mbeierl> narindergupta: sure, but I am not sure the overall phrasing as "labconfig.yaml" is not relevant
[17:19] <pragsmike> braven: or do you mean the drac works, but just not with maas
[17:19] <narindergupta> mbeierl, i think what we would like to know how maas determines the vlan on a subnet?
[17:20] <narindergupta> roaksoax, mbeierl is trying to configure the vlan in maas and maas discovery of nodes some vlan auto detected but looks like subnet does not match.
[17:20] <mbeierl> How does maas determine the VLANs and subnets to assign to a given fabric?  I have two subnets on the same NIC: 1) tagged VLAN 904, which is subnet 10.9.14.0/24, and 2) untagged subnet 10.9.12.0/24
[17:20] <mbeierl> But for some reason, in MAAS, I see fabric-1 with VLAN 904 and subnet 10.9.12.0/24
[17:21] <mbeierl> and a second fabric, (fabric-3) with untagged VLAN, subnet 10.9.14.0/24
[17:21] <Braven> IDRAC work with the Web GUI and MAAS. But MAAS is get this WARNING "The Failed to query node's BMC — Power state could not be queried <server IP> BMC busy"
[17:24] <pragsmike> braven: when you say it works with maas do you mean maas can power the machine up and down, but it gets that warning?
[17:24] <pragsmike> mbeierl: Supposedly, By default MAAS creates one fabric per physical NIC it discovers in /etc/network/interfaces during installation.
[17:26] <Braven> Yes MAAS can power the IDRAC up and down. But it take a few attempts. MAAS status also get stuck on commissioning in the GUI.
[17:26] <pragsmike> mbeierl: you had the vlan interfaces defined already when you installed maas (rackd)?
[17:26] <pragsmike> vlans defined on the machine where you ran rackd that is
[17:27] <mbeierl> pragsmike: A little context - MAAS is in a VM with bridged interfaces to the physical host with the real eth0.904, etc, interfaces
[17:28] <mbeierl> pragsmike: looking at that now...
[17:28] <pragsmike> mbeierl: ah, ok. I've not tried having vlans on the host, just in the guest (lxc container in my case)
[17:28] <mbeierl> pragsmike: but you gave me something to look at...
[17:29] <pragsmike> mbeierl: I just have the raw device eth1 on the host, and it's bridged to eth1 in the guest, and the guest is where the vlan interfaces are defined
[17:30] <mbeierl> pragsmike: right - bridged interfaces mask that from the guest VM so maybe I mixed something up there
[17:30] <pragsmike> i'm puzzled as to why you wound up with two fabrics
[17:30] <pragsmike> oh, unless it thought they were physical nics
[17:31] <mbeierl> indeed, in the VM it appears as two NICs
[17:31] <mbeierl> because of the bridge in the host
[17:32] <pragsmike> anyway if you can bridge the physical nic into the vm, and let the guest configure the vlan children on the vm's nic, that should work
[17:32] <pragsmike> afk for a while
[17:32] <mbeierl> pragsmike: will look at that, thanks!
[17:36] <pragsmike> mbeierl: I have some notes about how i set things up here: https://github.com/pragsmike/maas-openstack-lab
[17:36] <mbeierl> pragsmike: awesome, thanks!
[17:52] <Braven> Where in MAAS are the logs
[17:56] <wililupy> Question: I'm trying to add a device to MAAS but it says the IP is already in use, but I can't find any record of it, and the logs are not telling me anything. Is there a way to look to see what/where this IP is being used?
[17:56] <wililupy> I've tried maas default dnsresources read ip=ip.add.re.ss but it does not list anything with the IP address.
[17:59] <Braven> look in /var/lib/maas/dhcp/dhcpd.leases
[18:02] <wililupy> not there either. Its a static IP address not in my dhcp pool, which is why its funny that it is saying its in use...
=== frankban is now known as frankban|afk
[18:04] <wililupy> The IP address used to be attached to a server, but we have retired that server and removed it from maas. It looks like there might be something lingering behind not allowing me to reuse this IP address...
[18:05] <wililupy> I was hoping the maas.log would tell me what is still using it since MAAS is saying that it is still being used, but it is not being that helpful....
=== zz_CyberJacob is now known as CyberJacob
[18:53] <brendand> wililupy, how about 'maas default ipaddresses read'? do you see it in there?
[18:57] <wililupy> brendand no
[18:58] <wililupy> That doesn't return any up addresses. Hmmm...
[19:02] <ltrager> wililupy: try maas <profile> ipaddresses read all=true
[20:00] <brendand> ltrager, all is only in 2.1 though
[20:01] <ltrager> brendand: ah I forgot that
[20:01] <brendand> wililupy, if you're using 2.0 that won't work
[20:01] <brendand> wililupy, it would be great if you could post a question on http://askubuntu.com/
[20:11] <mpontillo> wililupy: yeah, this was fixed in MAAS 2.1 - it may be orphaned in the database. see https://bugs.launchpad.net/maas/+bug/1629061 -- someone else ran into this and was able to delete the record from the database directly, but obviously that's not ideal
[20:15] <wililupy> thanks mpontillo, brendand and ltrager. I"m using 2.0 atm. mpontillo, is there a good howto/doc on how to remove the orphan from the database? I'm not a postgres guy...
[20:17] <blake_r> wililupy: did you check the subnet details page for the subnet that the IP address you want to exist?
[20:17] <blake_r> wililupy: it should be listed on the subnet details page
[20:18] <wililupy> blake_r: it does show up there, but no way to remove it...
[20:18] <blake_r> wililupy: does it say what its linked to
[20:18] <wililupy> unknown
[20:19] <wililupy> and the node is blank
[20:19] <wililupy> blake_r ^^
[20:27] <mpontillo> wililupy: I would do "sudo maas-region dbshell" followed by "select * from maasserver_staticipaddress where ip=<unwanted-ip>;"
[20:27] <mpontillo> wililupy: can you post the output of those commands? I'm curious what type of address got "stuck"
[20:27] <mpontillo> wililupy: that won't delete the address; if you're convinced that is the one you want to delete, you could then do ""delete from maasserver_staticipaddress where ip=<unwanted-ip>;". but you're venturing into "unsupported" territory here.
[20:28] <wililupy> mpontillo: ack,
[20:30] <wililupy> maasdb=# select * from maasserver_staticipaddress where ip=10.1.10.5;
[20:30] <wililupy> ERROR:  syntax error at or near ".10"
[20:30] <wililupy> LINE 1: select * from maasserver_staticipaddress where ip=10.1.10.5;
[20:30] <wililupy>                                                               ^
[20:30] <wililupy>                                                               ^
[20:30] <mpontillo> wililupy: ah sorry, you need to single-quote the IP address, such as ip='10.1.10.5'.
[20:31] <wililupy> haha! found it.
[20:31] <mpontillo> wililupy, can you tell me its alloc_type?
[20:32] <wililupy> 1
[20:32] <mpontillo> wililupy: okay so that is a STICKY IP address, such as one that was reserved by a user for a machine
[20:33] <mpontillo> wililupy: actually we call it "Static" in the UI. it should have been deleted when the device was deleted, I think
[20:33] <wililupy> yeah. It was a server that they have retired and want to repurpose the IP for their network device on that subnet.
[20:35] <wililupy> ERROR:  update or delete on table "maasserver_staticipaddress" violates foreign key constraint "D8c61f24ad88a66a26296efd4314384e" on table "maasserver_bmc"
[20:35] <wililupy> DETAIL:  Key (id)=(53) is still referenced from table "maasserver_bmc".
[20:36] <mpontillo> wililupy: aha. so MAAS believes there to be a machine somewhere that is using that IP address for power control.
[20:39] <mpontillo> wililupy: run this to figure out which node(s) are using that address as a BMC: select s.ip, s.alloc_type, b.power_type, n.hostname from maasserver_staticipaddress s JOIN maasserver_bmc b ON s.id = b.ip_address_id LEFT OUTER JOIN maasserver_node n on n.bmc_id = b.id;
[20:46] <Braven> I am having an issue with my Maas setup.
[21:31] <wililupy> mpontillo: Figured it out. It must have been a kvm server becuase it is pointing to 4 vm's that are no longer in use as well..
[21:36] <mup> Bug #1639054 opened: syslog flooded with dhcpd messages that seem to be due to the use of actions in MAAS 2.0 <MAAS:New> <https://launchpad.net/bugs/1639054>
[21:42] <mup> Bug #1639054 changed: syslog flooded with dhcpd messages that seem to be due to the use of actions in MAAS 2.0 <MAAS:New> <https://launchpad.net/bugs/1639054>
[21:48] <mup> Bug #1639054 opened: syslog flooded with dhcpd messages that seem to be due to the use of actions in MAAS 2.0 <MAAS:New> <https://launchpad.net/bugs/1639054>
=== blahdeblah_ is now known as blahdeblah
[23:19] <wililupy> thanks mpontillo. Those commands helped get rid of that stray IP so they could reuse it for their network device. Everything is good again. They asked when 2.1 will be officially released?
[23:28] <ltrager> wililupy: MAAS 2.1 is currently in Ubuntu Yakkety and can be used by adding our stable ppa - sudo add-apt-repository ppa:maas/stable
[23:28] <ltrager> wililupy: we're planning on getting it into Xenial in the next couple of weeks
[23:41] <wililupy> thanks ltrager. I'll tell them about the ppa and see if they go that route or if they will wait for it to make it to the xenial archive.
=== CyberJacob is now known as zz_CyberJacob
[23:57] <mpontillo> Braven: what seems the be the problem?
[23:57] <mpontillo> wililupy: glad everything is up and running again; thanks for confirming the source of the issue!