[09:36] <mup> Bug #1520645 opened: Unable to enlist node in gMAAS <MAAS:Confirmed> <https://launchpad.net/bugs/1520645>
[10:14] <thoms> Hello. I need help about adding a "vmware" (vcenter) node to MAAS. I added the Vcenter CA to the openssl store of the MAAS server but when I try to add a chassis, vmware I keep getting Failed to probe and enlist VMware nodes: (vim.fault.HostConnectFault) {#012   dynamicType = <unset>,#012   dynamicProperty = (vmodl.DynamicProperty) [],#012   msg = '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify faile$.. does MAAS have an alternativ
[12:45] <nagyz> blake_r, are you around?
[13:29] <blake_r> nagyz: yeah
[13:31] <nagyz> blake_r, I was wondering about https://bugs.launchpad.net/maas/+bug/1495779
[13:32] <nagyz> not sure if people get notified for closed bugs, so pinged you here. :)
[13:32] <nagyz> does my comment make any sense? if not, I'd be happy to elaborate
[13:32] <nagyz> currently scripting setup of nodes so they use 2 interfaces for bonding and I was hoping I wouldn't need to click through 100+ nodes :P
[13:33] <blake_r> nagyz: unconfigured on the UI is the same a mode=link_up
[13:33] <blake_r> nagyz: so its doing the same thing
[13:34] <nagyz> is there actually any difference if I leave it on the subnet vs unconfigured for an interface that won't have an IP actually?
[13:34] <blake_r> nagyz: being on a subnet with mode=link_up is just like being unconfigured
[13:34] <blake_r> nagyz: the subnet is just meta data to say this interface has access to this subnet, so it places that interface in that space, but unconfigured in that space
[13:35] <blake_r> nagyz: it is designed that way for running something like the neutron gateway on that node, which needs its endpoint in a space, but must not have any ip address configured on that interface
[13:36] <nagyz> ok, let me try if setting mode=link_up actually does what I want.
[13:36] <nagyz> in the meantime, are you aware of any DNS/DHCP related issues in 1.9?
[13:36] <nagyz> I think I'm still seeing a behaviour where enlisting just gets broken if I enable DNS support (but would need a lot of time to reproduce in a clean setup)
[13:41] <blake_r> nagyz: that is very strange, let me know if you can get more detail on that
[13:41] <nagyz> ok, I can try it in a clean environment later - I'd love to use the built-in DNS functionality instead of writing a sync script to designate... :-)
[13:41] <nagyz> so going back on how to clear an interface...
[13:42] <nagyz> basically by default after commissioning there is an interface on the subnet with an auto assign IP
[13:42] <nagyz> my script then goes, creates a bond from two other interfaces, and sets the bond iface to static
[13:42] <nagyz> and now this is the part where I'd like to clear the original interface.
[13:43] <nagyz> http://pastebin.com/X8WwbLVt
[13:43] <nagyz> this is the current iface definition
[13:43] <nagyz> running interface link-subnet id id mode-link_up gets me an error message
[13:44] <nagyz> "Cannot configure interface to link up (with no IP address) while other links are already configured"
[13:44] <nagyz> if I click "unconfigured" on the web now, the links array becomesempty basically
[13:50] <nagyz> I'm sure I'm missing something.
[13:56] <nagyz> if I do an unlink-subnet, then the IP address association disappears
[13:57] <nagyz> but even after I cannot run link-subnet ... mode=link_up
[14:31] <nagyz> blake_r? :-)
[14:39] <blake_r> nagyz: you need to remove all links and then it will go to LINK_UP automatically which is unconfigued
[14:39] <blake_r> nagyz: you cannot set it to link_up with other links created
[14:39] <nagyz> how would i do this from the cli?
[14:39] <blake_r> nagyz: when you create the bond the parent interfaces will all go directly to configured
[14:39] <nagyz> eg remove all links
[14:40] <blake_r> nagyz: you need to call "unlink_subnet" with "link_id=<id>"
[14:40] <nagyz> that doesn't work as discussed in the bug report - I just get back the same as it was just with a different id
[14:40] <nagyz> or I really don't understand something.
[14:40] <blake_r> nagyz: when you create a bond the parents will go to unconfigured
[14:40] <blake_r> nagyz: you dont need to do that manually
[14:41] <blake_r> nagyz: and by default the bond will be unconfigured as well
[14:42] <nagyz> yes, I understand that. the bond is working fine
[14:47] <nagyz> so by default I have 4 interfaces, eth{0,1,2,3}. by default when I enlist it's using eth0 but I want to create a bond of eth1 and eth2.
[14:47] <nagyz> bonding works, I've managed to script that fully
[14:47] <nagyz> however, now even though it's pxebooting from eth0, it will only need to configure bond0 (and eth1 and eth2 as slaves) in /etc/network/interfaces
[14:48] <nagyz> so what I want is to explain to maas that "please forget that eth0 had any networks"
[14:49] <nagyz> unlink-subnet does clear the IP assignment (from the GUI I can see it going from "auto assign" to "unconfigured")
[14:50] <nagyz> but I'm still looking for the CLI equivalent of setting the subnet to unconfigured on the GUI - and the referenced command in the bug (mode=link_up) is not that.
[14:51] <nagyz> I'm not sure I can describe my issue any more clear :-)
[14:52] <nagyz> is it clear now what I'd like to accomplish?
[15:20] <blake_r> nagyz: if the only link on the interface is link_up, then it will be unconfigured in the WebUI
[15:21] <blake_r> nagyz: if you need to remove other links use link_subnet
[15:27] <nagyz> blake_r, there is only a single link there and no way to get rid of it from the CLI.
[15:27] <nagyz> if I select "unconfigured" from the GUI then I see the links array as empty
[15:28] <blake_r> nagyz: that is incorrect then from the UI, all links should never go away that is a bug
[15:28] <blake_r> nagyz: the API is correct having one link is just like unconfigured
[15:28] <blake_r> nagyz: that link needs to be LINK_UP
[15:29] <nagyz> http://pastebin.com/BCjvCqvn
[15:29] <nagyz> before and after clicking
[15:29] <nagyz> mode stays link_up, but the subnet definition is totally gone
[15:30] <nagyz> unlike with unlink-subnet, where it always stays there.
[15:31] <blake_r> nagyz: if the link is "LINK_UP" the subnet is not used on the deployed node, it is only there for metadata and to place the node in that space "aka. the space the subnet belongs"
[15:32] <nagyz> I understand that, but I'd really like to get rid of it - to do the exactly same thing as on the UI.
[15:32] <nagyz> now, either the UI is faulty as I can set the subnet unconfigured (which removes the whole subnet definition for the interface)
[15:32] <nagyz> or the CLI is inconsistent as it doesn't allow this
[15:38] <blake_r> nagyz: then just do "link_subnet mode=link_up" on the interface once it has only that one "link_up"
[15:39] <nagyz> I cannot do that as that raises the error that I refered to above
[15:39] <nagyz> the point would be to replace clicking on the GUI to set the interface's subnet to "unconfigured" :-)
[15:39] <nagyz> maybe I should have started with that
[15:40] <blake_r> nagyz: well then that is a bug as you should be able to perform that operation
[15:44] <nagyz> shall I open a bug? :-)
[15:44] <blake_r> nagyz: yes please
[16:31] <mup> Bug #1540453 opened: API doesn't indicate whether a node is deployable <kanban-cross-team> <landscape> <MAAS:New> <https://launchpad.net/bugs/1540453>
[16:43] <mag009_> hey
[18:13] <mag009_> hi I'm trying to deploy a xenial over maas but it seem that the image is not able to load the following module when deploying : nls_iso8859_1 it is required to mount the efi partition in fat32
[18:17] <mag009_> boot.log show this : can't create directory '/root/lib/modules': Read-only file system
[18:35] <mup> Bug #1540522 opened: Xenial deploy failed at efi mount  <MAAS:New> <https://launchpad.net/bugs/1540522>
[18:47] <mup> Bug #1540528 opened: [1.9] cannot scrub subnet information from interface <MAAS:New> <https://launchpad.net/bugs/1540528>
[18:50] <roaksoax-brb> /wi/win 4
[18:56] <mup> Bug #1540528 changed: [1.9] cannot scrub subnet information from interface <MAAS:Confirmed> <https://launchpad.net/bugs/1540528>
[19:05] <mup> Bug #1540528 opened: [1.9] cannot scrub subnet information from interface <MAAS:Confirmed> <https://launchpad.net/bugs/1540528>
[19:29] <mup> Bug #1540522 changed: Xenial deploy failed at efi mount  <curtin:New> <MAAS:Invalid> <maas-images:New> <https://launchpad.net/bugs/1540522>
[19:29] <mup> Bug #1540539 opened: MAAS installation: bind9 chokes on duplicate dnssec-validation setting <canonical-bootstack> <MAAS:Confirmed> <https://launchpad.net/bugs/1540539>
[19:32] <mup> Bug #1540539 changed: MAAS installation: bind9 chokes on duplicate dnssec-validation setting <canonical-bootstack> <MAAS:Confirmed> <https://launchpad.net/bugs/1540539>
[19:32] <mup> Bug #1540522 opened: Xenial deploy failed at efi mount  <curtin:New> <MAAS:Invalid> <maas-images:New> <https://launchpad.net/bugs/1540522>
[19:35] <mup> Bug #1540522 changed: Xenial deploy failed at efi mount  <curtin:New> <MAAS:Invalid> <maas-images:New> <https://launchpad.net/bugs/1540522>
[19:35] <mup> Bug #1540539 opened: MAAS installation: bind9 chokes on duplicate dnssec-validation setting <canonical-bootstack> <MAAS:Confirmed> <https://launchpad.net/bugs/1540539>
[19:35] <mup> Bug #1540548 opened: MAAS installation doesn't create database config <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1540548>
[19:41] <mup> Bug #1540548 changed: MAAS installation doesn't create database config <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1540548>
[19:44] <mup> Bug #1540548 opened: MAAS installation doesn't create database config <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1540548>
[19:47] <mup> Bug #1540548 changed: MAAS installation doesn't create database config <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1540548>
[19:59] <mup> Bug #1540548 opened: MAAS installation doesn't create database config <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1540548>
[21:05] <Skaag> I'm stuck with the "Getting started" document, I have two machines both running MAAS, I have em1 and em2 on both of them (em2 being the private network)
[21:05] <Skaag> If someone is willing to give me a few minutes to help me get up and running, that will be wonderful and much appreciated
[21:05] <Skaag> I'm not sure how to get the two machines to cluster, for example
[21:38] <nagyz> why do you have two machines?
[21:38] <nagyz> for simple installations you can run one machine
[21:38] <nagyz> I guess depends on your node size, but for my ~120 nodes in the system, 1 maas is enough
[21:39] <Skaag> I see
[21:39] <Skaag> I just realized yesterday that the way this works is that you can setup MAAS itself even on a relatively weak VM
[21:39] <Skaag> and let the hardware boot via PXE
[21:40] <Skaag> but what's not clear to me is: the physical machine boots via PXE, how do you run multiple VM's on the same metal?
[21:41] <Skaag> does some "layer" get booted first via PXE, which then allows running multiple VM's also via PXE?
[21:41] <nagyz> not sure I even understand the question...
[21:41] <nagyz> do you want to provision physical servers or VMs?
[21:41] <nagyz> for example we use maas to provision our physical nodes but we use openstack for vms
[21:42] <nagyz> maas is not orchestrating VM creation and whatnot
[21:44] <Skaag> I want to use openstack for VMs
[21:44] <Skaag> I have two relatively powerful machines with tons of storage
[21:45] <Skaag> normally I would use something like proxmox to take as much advantage of the hardware as possible
[21:45] <Skaag> (since all VM's are private, and absolute 100% hack proof isolation is not important)
[21:45] <nagyz> so why not use proxmox?
[21:45] <nagyz> for 2 machines you don't need maas...
[21:46] <nagyz> esp since you can't use maas AND proxmox together as proxmox has it's own installer
[21:46] <Skaag> I want to create a setup that mimics as much as possible what cloud providers offer
[21:47] <nagyz> no cloud provider tells you how they provision their infrastructure, usually
[21:47] <nagyz> and proxmox doesn't support any "cloud".
[21:47] <roaksoax-brb> Skaag: maas uses VM's as if they were hardware
[21:47] <nagyz> you can use maas to deploy the hardware and then install openstack using juju for example
[21:47] <nagyz> roaksoax-brb, a quick question re. the bcache bug in 1.9 + the official trusty image: what's the plan there? :-)
[21:48] <roaksoax-brb> nagyz: can you point me to the bug ? maybe the issue is not actually in MAAS but curtin
[21:49] <roaksoax-brb> Skaag: When you tell MAAS "mannage this VM" or "This chassis (which can be a host with VMs") MAAS uses it as if it were individual hardware out there
[21:49] <nagyz> https://bugs.launchpad.net/maas/+bug/1514094
[21:49] <roaksoax-brb> Skaag: MAAS won't make any distinction between a VM and a baremetal machine
[21:49] <nagyz> right it's a curtin bug actually...
[21:50] <nagyz> but breaks using bcache via maas :)
[21:50] <roaksoax-brb> nagyz: seems fixed thought. What cucrtin version are you using ?
[21:51] <nagyz> roaksoax-brb, whatever is in the image that maas uses to deploy trusty from the /releases repo :-)
[21:51] <roaksoax-brb> nagyz: curtin is not in the images. Curtin is installed in the MAAS server actually
[21:51] <roaksoax-brb> nagyz: dpkg -l | grep curtin in the MAAS Server
[21:51] <nagyz> on the maas node apt-cache show tells me it's 0.1.0~bzr314-0ubuntu1
[21:53] <roaksoax-brb> nagyz: the bug seems fixed on rev304 and rev306
[21:53] <roaksoax-brb> nagyz: so that fix is in curtin
[21:53] <nagyz> I can give it a go again but we've just tried creating bcache backed drives and it didn't work out
[21:53] <nagyz> saw a bunch of modprobe bcache errors
[21:54] <roaksoax-brb> nagyz: try using the MAAS daily image s?
[21:54] <roaksoax-brb> nagyz: and please pb the intsall output, and I can raise it with the curtin guys
[21:54] <nagyz> yeah let me give that a go
[22:08] <nagyz> that nerve-wrecking moment when you do a "cat config-generated-from-python | ssh backbone-switch-1"... :)
[22:09] <nagyz> the switch config was actually generated by a python script from maas's lldp discovery data
[22:09] <nagyz> and it configures over 200 ports now
[22:35] <Skaag> roaksoax-brb: I see, so I could in theory start an instance using whatever virtualization solution I have, and just tell it to boot via PXE
[22:38] <roaksoax-brb> Skaag: correct
[22:39] <roaksoax-brb> Skaag: or if you have pre-created/described say, 10 VM's in say KVM or VMWare ESXi, and you can literally add them all in one go with MAAS
[22:39] <roaksoax-brb> Skaag: with the 'Add Chassis' from the webui
[22:39] <Skaag> understood
[22:39] <Skaag> so then what I need to do is install openstack directly on those two ubuntu machines, and MAAS on a separate machine, just to hold the images, and control provisioning
[22:40] <Skaag> but then if I install openstack, what is the advantage of using a tool such as MAAS, wouldn't it be a duplicate?
[22:41] <roaksoax-brb> Skaag: you can use MAAS/juju to install openstack directly
[22:41] <roaksoax-brb> Skaag: openstack itself will allow you to deploy instances in the cloud, you don't really need maas for that
[22:41] <Skaag> I see
[22:41] <roaksoax-brb> Skaag: if you want to deploy workloads in those instances, you can use Juju with the OpenStack provider
[22:42] <Skaag> but in my case because all I have is 2 machines dedicated to openstack, there's little benefit. I guess MAAS is really for larger outfits who deploy a LOT of hardware all the time (and dynamically)
[22:42] <Skaag> and they can take them up/down depending on demand
[22:42] <Skaag> and everything is 100% dynamic
[22:42] <roaksoax-brb> Skaag correct
[22:42] <Skaag> thank you, I feel I understand the structure much better now
[22:42] <roaksoax-brb> Skaag: if say, you don't put OpenStack on those 2 machines, but you do have 50 VM's running, you can deploy those with MAAS
[22:43] <Skaag> I have no idea how to do that
[22:43] <Skaag> I have MAAS right now on those two machines
[22:43] <Skaag> the idea with creating two instances was for redundancy
[22:43] <Skaag> but I don't know how to make them aware of each other (cluster)
[22:43] <Skaag> and further, I don't know how to create VM instances under maas
[22:47] <mup> Bug #1540453 changed: API doesn't indicate whether a node is deployable <landscape> <MAAS:Opinion> <MAAS 1.9:Opinion> <https://launchpad.net/bugs/1540453>
[22:48] <nagyz> roaksoax-brb, would maas 1.9 be able to power on VMs on vSphere using it's API instead of WOL?
[22:49] <nagyz> and if so, how does a "chassis" map to VMs in VMware? is it only based on prefix? or is it a folder name?
[22:52] <roaksoax-brb> Skaag: MAAS doesn't yet have native HA
[22:52] <roaksoax-brb> nagyz: MAAS 1.8+ IIRC supports VMWare products, but the support is based on python-pyvmomi's library, which is VMware's
[22:52] <roaksoax-brb> nagyz: you dont really need WoL
[22:53] <roaksoax-brb> nagyz: when you add a "chassis" you can send a prefix filter
[22:54] <nagyz> roaksoax-brb, so if I actually want maas to start the VM, will it do it via calling the native API?
[22:56] <roaksoax-brb> nagyz: yes
[22:56] <roaksoax-brb> nagyz: maas never really supported VMWare until we added support on 1.8... or 1.7 even
[22:56] <roaksoax-brb> can't recall of the top of my head :)
[22:57] <nagyz> it would be cool to experiment with juju there instead of physical nodes:-)
[22:57] <nagyz> (I know I know, I could use AWS or OS underneath as well)
[22:58] <nagyz> any quick way to get back the system IDs from maas CLI sorted by the system name...? :)
[22:58] <nagyz> tried to do it with | jq but haven't managed so far
[23:01] <Skaag> I'd just pipe it through cut + sort
[23:01] <Skaag> or maybe that's not very good since it would only give you the name
[23:02] <Skaag> oh it's a json output. sorry, my bad.
[23:03] <mup> Bug #1540453 opened: API doesn't indicate whether a node is deployable <landscape> <MAAS:Opinion> <MAAS 1.9:Opinion> <https://launchpad.net/bugs/1540453>
[23:03] <nagyz> | jq '.[] | {name:.hostname,id:.system_id}' | jq -s '. | sort_by(.name)'
[23:03] <nagyz> this works
[23:09] <roaksoax-brb> nagyz: you can use juju too i'd think
[23:10] <nagyz> roaksoax-brb, right it only talks to maas :-) so if maas provisioning works then I can use juju
[23:10] <nagyz> that's the current plan
[23:10] <nagyz> ok, thanks for the help, off to bed.
[23:10] <nagyz> I'll open some dns bugreports tomorrow ;-)
[23:12] <mup> Bug #1540453 changed: API doesn't indicate whether a node is deployable <landscape> <MAAS:Opinion> <MAAS 1.9:Opinion> <https://launchpad.net/bugs/1540453>
[23:12] <roaksoax-brb> hehe
[23:51] <dgrossman> can someone point me to installing centos images in maas 1.8.3?  I tried 'sudo maas admin boot-resources create name=centos/centos7 architecture=amd64/generic content@=centos7-amd64-root-tgz'  do I need to generate an api key before trying to do this?