[00:07] <mup> Bug #1558324 opened: [2.0-trunk] Error on request (45) space.delete: AttributeError: 'Subnet' object has no attribute '_vlan_cache' <MAAS:Triaged by lamont> <https://launchpad.net/bugs/1558324>
[00:16] <mup> Bug #1558324 changed: [2.0-trunk] Error on request (45) space.delete: AttributeError: 'Subnet' object has no attribute '_vlan_cache' <MAAS:Triaged by lamont> <https://launchpad.net/bugs/1558324>
[00:22] <mup> Bug #1558324 opened: [2.0-trunk] Error on request (45) space.delete: AttributeError: 'Subnet' object has no attribute '_vlan_cache' <MAAS:Triaged by lamont> <https://launchpad.net/bugs/1558324>
[00:24] <jwitko> hey roaksoax, quick question, I created a second interface on my controller with a separate subnet also set to do dhcp and dns.
[00:25] <jwitko> however when I rekick the blades, they come up with the interface but no IP or anything assigned
[00:25] <jwitko> any ideas what went wrong?
[01:16] <fritchie> is it possible to log into a maas commissioned node via the console to troubleshoot?
[01:37] <jwitko> fritchie, yes.  the first interface comes up without issue and SSH is available
[01:38] <jwitko> the second comes up and /etc/network/interfaces just shows the mtu setting and nothing else under the secondary interface
[01:51] <jwitko> yea, I just tried it again
[01:51] <jwitko> double checked ranges and everything.  no interface config at all for p2p2
[01:53] <fritchie> can a maas node act as a default gateway for the dhcp network?
[02:06] <jwitko> i'd prefer it used its standard default gateway, which I've set in the web UI
[02:09] <fritchie> what is dhcp is being used on an isolated vlan with no router?
[02:49] <jwitko> yes that is correct
[02:49] <jwitko> except I cant figure out how to vlan tag in maas
[02:49] <jwitko> so they are untagged to maas
[05:05] <mup> Bug #1558383 opened: [2.0a2] dhcp set to false causes ERROR in logs <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1558383>
[05:08] <mup> Bug #1558383 changed: [2.0a2] dhcp set to false causes ERROR in logs <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1558383>
[05:17] <mup> Bug #1558383 opened: [2.0a2] dhcp set to false causes ERROR in logs <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1558383>
[06:42] <jam> or davecheney ^^
[06:42] <jam> meh, wrong channel
[09:14] <mup> Bug #1558188 changed: during import images boostrap fails with gomaasapi: got error back from server: 400 BAD REQUEST ({"distro_series": ["'trusty' is not a valid distro_series.
[09:14] <mup> It should be one of: '', 'windows/win2012hvr2', 'ubuntu/precise'..."]}) <oil> <MAAS:Triaged> <MAAS 1.9:Triaged> <https://launchpad.net/bugs/1558188>
[10:30] <voidspace> roaksoax: ping
[10:42] <alexlist> Hi... I am trying to deploy CentOS 7 using the latest stable MAAS 1.9. I am following https://maas.ubuntu.com/docs1.9/os-support.html and have found an image at http://maas.ubuntu.com/images/ephemeral-v2/daily/centos70/amd64/20141129_01/. CentOS 7 shows up under "Generated Images" but I cannot select that for deployment. What am I missing?
[11:23] <alexlist> OK, I have switched the boot resources URL to "daily" and see the images. However, when I click "deploy", they are not listed.
[12:33] <nitin_> whois nitin
[12:49] <roaksoax> alexlist: did you import them? you have to import the images
[13:03] <timello> folks, gm, how does one would backup nodes, cluster, images, etc, configuration for further use?
[13:09] <timello> I see https://code.launchpad.net/~maas-maintainers/maas/backup, but it looks old.
[15:07] <dragnell87> Hello everyone
[15:08] <dragnell87> Has anyone try maas with vcloud director from VmWare for power management ?
[15:13] <dragnell87> any case precedent on this matter ? where access to real hypervisor does not exist and the only thing you have access is to the VMs and the allocation of resources
[15:45] <mup> Bug #1558635 opened: Trying to assign an IP address statically to a device results in builtins.AttributeError: 'NoneType' object has no attribute 'link_subnet' <MAAS:New> <https://launchpad.net/bugs/1558635>
[15:48] <mup> Bug #1558640 opened: [2.0a2] Lease notifier not working in LXD container because of apparmor <MAAS:Triaged> <https://launchpad.net/bugs/1558640>
[15:54] <mup> Bug #1558640 changed: [2.0a2] Lease notifier not working in LXD container because of apparmor <MAAS:Triaged> <https://launchpad.net/bugs/1558640>
[16:06] <mup> Bug #1558640 opened: [2.0a2] Lease notifier not working in LXD container because of apparmor <MAAS:Triaged> <https://launchpad.net/bugs/1558640>
[16:09] <mup> Bug #1558640 changed: [2.0a2] Lease notifier not working in LXD container because of apparmor <MAAS:Triaged> <https://launchpad.net/bugs/1558640>
[16:12] <voidspace> roaksoax-afk: you misunderstood this bug https://bugs.launchpad.net/maas/+bug/1557451
[16:12] <voidspace> roaksoax-afk: please see my latest comment
[16:12] <voidspace> roaksoax-afk: you may still think it's only medium priority
[16:12] <voidspace> roaksoax-afk: but currently we need to make 2 api calls to work out what version of maas we're running against
[16:12] <voidspace> roaksoax-afk: first hit api/1.0 and if that fails try api/2.0
[16:13] <voidspace> roaksoax-afk: because there's no version independent way to find that out
[16:15] <mup> Bug #1558640 opened: [2.0a2] Lease notifier not working in LXD container because of apparmor <MAAS:Triaged> <https://launchpad.net/bugs/1558640>
[17:15] <roaksoax-afk> voidspace: my understanding is that a user tells jusjut http://<maas-ip>/MAAS
[17:15] <roaksoax-afk> voidspace: then juju automatically adds the /api/1.0 right?
[17:15] <roaksoax-afk> voidspace: my point being was that juju would check /api/1.0 if it returns nill or error, it would assume /api/2.0
[17:15] <roaksoax-afk> voidspace: which basically, would be similar to just doing a version check
[17:17] <voidspace> roaksoax-afk: right, but that's two calls just to get the version
[17:17] <voidspace> roaksoax-afk: I'm asking for a version independent endpoint to get that information in one call
[17:18] <voidspace> roaksoax-afk: anyway, we understand each other - so cool
[17:20] <roaksoax-afk> voidspace: to me it is the same. if you check for version first, and then you try to login, then that's two calls. You could simply first try 1.0 firs,t and if that doesn't work, you try 2.0
[17:20] <roaksoax-afk> voidspace: either way you look at it, it is 2 calls
[17:22] <jwitko> Hey guys, when uninstalling MAAS it asks if I want to keep the database.  Does this database simply contain node information or does it also contain the setup of the MAAS controller?
[17:23] <roaksoax-afk> voidspace: note that I';m only highliting the fact that either way you look at it, you will always have to make 2 requests
[17:23] <roaksoax-afk> voidspace: 1. check for vesion. 2. make requets to api version
[17:23] <roaksoax-afk> or
[17:24] <roaksoax-afk> 1. make request to 1 version 2. make request to another version
[17:24] <roaksoax-afk> voidspace: that being said, it is medium as we are working on other critical issues at the moment, and that wont be addressed immediately
[17:24] <roaksoax-afk> voidspace: i'd guess next week
[17:25] <voidspace> roaksoax-afk: well, not really - we're not going to check for version on *every* api call
[17:25] <voidspace> roaksoax-afk: we'll do it once and cache it!
[17:25] <voidspace> roaksoax-afk: so the question is how many calls we need to do to make that initial determination
[17:26] <voidspace> and currently that's two :-)
[17:26] <voidspace> roaksoax-afk: but I appreciate you guys have a lot on your plate
[17:26] <roaksoax-afk> voidspace: actully, juju is the one who adds /api/2.0
[17:26] <roaksoax-afk> voidspace: actully, juju is the one who adds /api/1.0
[17:26] <roaksoax-afk> voidspace: not the user
[17:27] <roaksoax-afk> voidspace: so when you tell the user /MAAS, juju adds /api/1.0
[17:27] <voidspace> roaksoax-afk: yes
[17:27] <voidspace> the user doesn't tell us the api version
[17:27] <roaksoax-afk> voidspace: so, now if you add /MAAS, juju will 1. check version. 2. make api call to /api/1.0 or 2.0
[17:27] <roaksoax-afk> voidspace: my perspective. 1. try /api/1.0 or 1. try /api/1.0 or 2. /api/2.0
[17:28] <roaksoax-afk> voidspace: checking for version will always, always always yield one extra call
[17:28] <roaksoax-afk> but hey
[17:28] <roaksoax-afk> that's your code :)
[17:28] <voidspace> roaksoax-afk: yes, but we make *many* api calls
[17:28] <voidspace> roaksoax-afk: so we want to check for version once at the start and cache that
[17:28] <roaksoax-afk> voidspace: yes, but juju would have to store the version right ?
[17:28] <roaksoax-afk> voidspace: exactly, either way you do, yields the same result
[17:29] <voidspace> no
[17:29] <roaksoax-afk> voidspace: 1. you check for version, 2. you cache it. 3. all remainder api calls go to cached version
[17:29] <voidspace> we need to know version there are two possibilities
[17:29] <roaksoax-afk> voidspace: 1. you try /api/1.0 2. it works, you cache it. 3. all remainder api calls go to cached version
[17:29] <voidspace> 1) there is a version independent api to find it - one call (not currently true)
[17:29] <voidspace> 2) try 1.0 then 2.0 - two calls
[17:29] <voidspace> then we make the actual api calls we need
[17:29] <voidspace> so not the same
[17:29] <voidspace> gotta go
[17:29] <roaksoax-afk> voidspace: it is the same:
[17:29] <roaksoax-afk> 1. try 1.0, it didn't work
[17:30] <roaksoax-afk> 2. then assume 2.0, making actual api call
[17:30] <voidspace> roaksoax-afk: hah, well fair enough
[17:30] <roaksoax-afk> voidspace: as in: try to login with 1.0 first, it is not avialable. 2. try to login to 2.0 :)
[17:30] <voidspace> we could just try 1.0 and it succeeds or we're on 2.0 - fair enough
[17:30] <voidspace> or 3.0 ;-)
[17:55] <jwitko> Hey guys, when uninstalling MAAS it asks if I want to keep the database.  Does this database simply contain node information or does it also contain the setup of the MAAS controller?
[18:45] <mup> Bug # changed: 1546475, 1549206, 1549208, 1549230, 1550540
[19:15] <mup> Bug #1558747 opened: [1.9.1] Deployment for IBM S822LC  8335-GTA fails to boot local disk following  curtin install <oil> <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1558747>
[19:45] <mup> Bug #1558755 opened: [2.0a2] Deploying machine with primary rack dead fails <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1558755>
[20:03] <mpontillo> jwitko: I would say most MAAS configuration is in the database, but there is a little bit in /etc as well
[20:04] <mpontillo> jwitko: what configuration would you like to preserve?
[20:18] <mup> Bug #1558752 opened: [1.9.1] Failure to get DHCP address during curtin install of IBM S822LC  8335-GTA   <oil> <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1558752>
[20:40] <jwitko> mpontillo, i just blasted it away,  but thanks
[20:40] <jwitko> Did MAAS get rid of the "Network" menu at the top ?
[20:40] <jwitko> was that replaced with Cluster ?
[20:43] <mpontillo> jwitko: in 1.9 I think that was replaced with the Fabrics tab, in 2.0 it'll be "Networks" (but be very different)
[20:43] <mpontillo> jwitko: all network configuration available in the UI is under the clusters tab though
[20:43] <jwitko> ty
[20:49] <jwitko> hey mpontillo, quick question -  is there any way to easily add a list of macs into maas?
[20:49] <jwitko> is the +Add new MAC button for multiple MACs on one machine?  or will that add them as separate servers
[20:50] <mpontillo> jwitko: that's for a single machine. if you want to add things in bulk, I'd use the API. I can get you an example in a sec
[20:53] <mpontillo> jwitko: if you haven't used the API client before, first use the "maas login" command, for example "maas login admin http://your-maas-ip:5240/MAAS/ <token>", where <token> is the key from your user preferences page
[20:54] <mpontillo> jwitko: here are some example commands I use to add a few NUCs and a libvirt-based hypervisor: https://paste.ubuntu.com/15410283/
[20:55] <mpontillo> (those examples assume you are using the "admin" profile with the MAAS CLI.)
[20:57] <mpontillo> jwitko: also, I have a couple scripts to generate those commands from a YAML file, if that's useful to you. see https://code.launchpad.net/~mpontillo/+junk/maas-qa-utils
[20:59] <stormmore> this I like
[20:59] <stormmore> nope
[21:25] <mup> Bug #1558785 opened: [2.0a2] Detected deadlocks in postgres should be handled list a serialization failure <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1558785>
[21:44] <jwitko> hey mpontillo that really helped thank you
[21:44] <jwitko> the servers have all installed and booted.
[21:45] <jwitko> couple of follow up questions though
[21:45] <mpontillo> np jwitko, good luck (and let us know if you have feedback)
[21:45] <jwitko> 1)  The secondary interface is not coming up with any sort of configuration except the mtu setting
[21:45] <mpontillo> jwitko: sure, though I need to go afk for awhile, so replies might be slow
[21:45] <jwitko> 2) Is there any way to set static IPs to nodes ?
[21:46] <mpontillo> jwitko: you should be able to change the interface settings (including static IPs) on the node details page; if there are items you cannot change related to networking, please check if you can set them via the command line API
[21:46]  * mpontillo -> afk
[21:50] <jwitko> mpontillo, it says "auto assign" so I'm guessing I need to turn off DHCP and DNS on the interfaces and turn them into unmanaged?
[21:50] <jwitko> How will PXE boot requests get DHCP leases then :?
[21:53] <mpontillo> jwitko: we add a static mapping in the dhcp server (assuming we manage dhcp for that network)
[21:54] <jwitko> Sorry?
[21:54] <mpontillo> jwitko: making the network unmanaged isn't required (nor would that be recommended)
[21:54] <jwitko> by assuming we manage dhcp, do you mean assuming there is an alternative dhcpd providing service ?
[21:54] <jwitko> oh
[21:55] <mpontillo> jwitko: well, you can use your own DHCP server, but that is not recommended
[21:55] <jwitko> ok, I see i had to power the machines off before reconfiguring their network
[21:56] <jwitko> mpontillo, so back to the interface that does not get configured
[21:56] <jwitko> when I get to set the static IP address, it works fine for the first interface
[21:56] <jwitko> but the fabric-2 interface shows no subnets to choose from
[21:57] <jwitko> however there is a vlan tagged subnet that shows up under "Subnets" tab
[21:57] <mpontillo> jwitko: I assume that's not a subnet managed by MAAS? You can use the API to add VLANs and subnets to that fabric
[21:57] <jwitko> if i take "eth1" and set it to "fabric-1", the VLAN menu does not allow for a drop-down
[21:58] <jwitko> mpontillo, it should have been auto configured from maas install?
[21:58] <jwitko> it shows under fabric-1 in the subnets tab, I see the untagged section with no information and then the vlan tagged one with all the correct info
[21:58] <jwitko> however on the node network section it does not allow me to select the VLAN tagged subnet
[21:59] <jwitko> it should be a subnet managed by maas?
[22:03] <jwitko> sorry, i had to add the additional interface on the node drill down
[22:25] <mpontillo> jwitko: hmm ok, when you commission the node it should run the DHCP client and discover all interfaces available, if it can. but it doesn't check tagged VLANs
[22:26] <mpontillo> that would make commissioning take quite awhile, since it would need to check 4094 possibilities ;-)
[22:27] <jwitko> mpontillo, is there a way to configure the nodes to deploy with a bridged interface set up?
[22:28] <jwitko> instead of having my eth1 and my vlan tagged eth1.600,  could I create eth1, br1, br1.600 ?
[22:28] <m3talsmith> Are there any service providers using MAAS yet?
[22:28] <mpontillo> jwitko: MAAS does not yet support bridges; we are thinking about doing that for MAAS 2.1. the 1.x philosophy is that bridges are solidly juju's territory
[22:28] <jwitko> got it.  thanks