[00:11] <cmart> has anyone tried deploying the Ubuntu 16.04 LTS image since it last updated today? I'm having errors during cloud_init, fails commissioning. on a set of hosts that I just deployed successfully last week.
[00:12] <cmart> I get a Python traceback and "failed to start initial cloud-init job" on the console, unsure how to troubleshoot.
[00:17] <cmart> is there a way to roll back an image to a version from a few days ago?
[00:31] <cmart> It looks like you're storing some old versions here: http://images.maas.io/ephemeral-v2/daily/xenial/amd64/ Is there a way to tell MAAS to grab one of those?
[09:53] <mup> Bug #1632638 opened: [2.1 UI] Include table sorting for device discovery <ui> <ux> <MAAS:Triaged> <https://launchpad.net/bugs/1632638>
[09:53] <mup> Bug #1632642 opened: [2.1] Device discovery click on row functionality <MAAS:New> <https://launchpad.net/bugs/1632642>
[11:38] <mup> Bug #1632642 changed: [2.1 UI] Device discovery click on row functionality <ui> <MAAS:Opinion> <https://launchpad.net/bugs/1632642>
[11:50] <mup> Bug #1632642 opened: [2.1 UI] Device discovery click on row functionality <ui> <MAAS:Opinion> <https://launchpad.net/bugs/1632642>
[11:59] <mup> Bug #1632642 changed: [2.1 UI] Device discovery click on row functionality <ui> <MAAS:Opinion> <https://launchpad.net/bugs/1632642>
[12:54] <baldpope> stokachu, ping
[12:54] <stokachu> baldpope: o/
[12:54] <baldpope> had a question in response to bug 1632092
[12:55] <baldpope> andrew's question (I believe to you) was asking where is the config done, but I had a follow-up question from yesterday's conversation about the net config
[12:56] <baldpope> i was checking out the juju demo pages and (what appears to be) a charm creator - pretty slick btw
[12:56] <stokachu> baldpope: ah the juju gui
[12:57] <baldpope> up to this point, i had assumed that the combination of conjure/juju understood the infrastructure it was being deployed to automagically
[12:57] <baldpope> stokachu, yea - that's some cool shit
[12:57] <baldpope> so anyway - then it dawned on me - with all the different nics, out there, it's possible that I should be prepping the installation scripts with some specifics about my environment
[12:58] <baldpope> so to finally get to the question - instead of just running the conjure-up openstack - is there some prep work I should have completed to tell about the target environment?
[12:58] <stokachu> so with juju you can set constraints to deploy certain applications to specific systems in maas
[12:59] <stokachu> which you would set in the bundle itself and use conjure-up that way
[13:00] <baldpope> but the application constraints are more about (asking) which applications will be installed, the components, but not necessarily (again asking) about the nics, bonding, vlans, etc?
[13:00] <stokachu> baldpope: correct
[13:01] <stokachu> in a normal scenario we ask people to make sure all machines have at least 2nics and 2hdds for a successful openstack deployment
[13:01] <stokachu> via maas
[13:01] <baldpope> ok, so a 'stock' openstack charm/spell installation is probably fine but then where do I set bonding and the desired vlans, etc
[13:01] <baldpope> right, and each of my nodes are 6 nics and 8 hdd
[13:02] <stokachu> baldpope: so the charm would expose some options for you to setup bonding
[13:02] <baldpope> and ignoring the conversation we had last week about nfs/iscsi root, I'd like each node to share the disks to the stack for storage, and each node to be a compute node (if htat's possible)
[13:02] <baldpope> stokachu, and the charm can be run either before or after base installation?
[13:03] <stokachu> both, the config changes should apply without failure at any point of the deployment
[13:03] <baldpope> hm
[13:04] <stokachu> baldpope: maas also gives you some flexibility on defines your networks
[13:04] <baldpope> ok.. i'm not whining (it's going to sound like it...) ... then why does the conjure-up openstack seem to fail deployment every time I've attempted to deploy, if the base charm/spell should work without any customization to the nics
[13:05] <stokachu> baldpope: for openstack novalxd we have control over that environment so it can deploy successfully without any configuration
[13:05] <baldpope> ok
[13:05] <stokachu> baldpope: with maas you still need to perform some configuration via the charm options within conjure-up
[13:05] <baldpope> ok, then I think that's the part I've been missing
[13:08] <baldpope> during the conjure-up, it deploys to 1 host first, from conversation with either you or roaksoax , I recall being advised that most people run that in a VM?
[13:08] <baldpope> does that host also need dual nics and dual drive?
[13:09] <baldpope> mine currently does not
[13:09] <stokachu> baldpope: you dont need dual nics/hdds for the controller node
[13:09] <baldpope> and not knowing how to size it, i simply doled out 4gb ram and 32gb disk
[13:09] <stokachu> yea that should be plenty
[13:09] <baldpope> k
[13:09] <stokachu> conjure-up has --bootstrap-to that you can set to make sure that vm host is used for the controller node
[13:10] <stokachu> only applies to a maas deployment
[13:10] <baldpope> cool, I noticed that when conjure-up is running, it must sort node names, so I have mine correctly numbers blade0 through blade5
[13:10] <baldpope> with 0 being the vm
[13:10] <baldpope> but I like the cli option better - no guess work
[13:11] <stokachu> yea i wouldnt rely on that sorting im not sure if that's intentional or not
[13:11] <baldpope> heh
[13:11] <stokachu> that would probably be a juju question
[13:11] <stokachu> i thought juju just randomly picked an avaialble machine for the controller node
[13:11] <baldpope> fair enough - i'll use the cli option going forward
[13:12] <baldpope> i've done it a couple of times now and it always seemed to grab the lowest numbered one - assuming you set them up intentionally through maas instead of doing the auto discover with random host names
[13:12] <stokachu> that would be interesting to find out
[13:12] <stokachu> i should ask juju guys about it
[13:13] <baldpope> i could be wrong - maybe (as you said) could be unintentional side effect
[13:13] <stokachu> im asking now ill let you know what they say
[13:14] <baldpope> cool
[13:23] <baldpope> feature request for maas - can we get the mac address added to the display in maas under the node interface listings - it would help identify which nics are which
[13:24] <baldpope> it says name/mac - but only name is listed
[13:24] <baldpope> ah fuck,..
[13:24]  * baldpope sigh
[13:24] <baldpope> nevermind
[13:28] <stokachu> :D
[13:31] <brendand> baldpope, but it could be more obvious, honestly
[13:37] <baldpope> thanks, appreciate it
[13:40] <baldpope> actually, my issue was i had the browser window relatively small, and MAC was partially covered
[13:40] <baldpope> when I expanded the window I realized (finally) the link
[13:55] <baldpope> stokachu, possible reason why it's failing, eno1 is listed as the first nic, but it is not the nic that is plugged in
[13:55] <stokachu> did you set bridge-mappings to a list of interfaces to try?
[13:55] <baldpope> eno1, along with ens3f1, ens3f2, and ens3f3 are the add-on card
[13:55] <baldpope> stokachu, not yea, back and forth with work work
[13:56] <stokachu> baldpope: gotcha, try to put them all in the bridge-mappings list
[13:56] <stokachu> see if it'll pick up the plugged in one
[13:56] <baldpope> stokachu, would I want to bond them together in maas first?
[13:56] <stokachu> sure you can do that
[13:56] <baldpope> k
[13:56] <stokachu> you'd want to do it for all machines
[13:56] <stokachu> because you won't know which one gets picked for neutron-gateway
[13:57] <baldpope> yea, I had planned to configure each in maas the same way
[13:57] <stokachu> cool yea that should be it then
[14:53] <batkins61> I can't find maas-image-builder in either maas-maintainers/stable or maas/stable, as described in the docs.  How do I get an RHEL custom image to install?
[14:56] <brendand> batkins61, yeah that changed
[14:56] <brendand> ltrager, ^
[14:56] <ltrager> batkins61: you need RHEL not CentOS?
[14:59] <roaksoax> batkins61: maas-image-builder is no longer available provided it only gave support for CentOS and we now provide centos automatically
[15:00] <brendand> roaksoax, docs claim it supports RHEL as well
[15:00] <batkins61> roaksoax the web page says RHEL7 too.
[15:01] <batkins61> roaksoax 1.7+
[15:01] <batkins61> https://maas.ubuntu.com/docs/os-support.html
[15:02] <batkins61> Red Hat logo is also on the main page "Zero-touch deployment of Windows, Ubuntu, CentOS, RHEL and SUSE".    Is there docs on how to access that in 1.9 or 2.0?
[15:04] <blake_r> batkins61: maas.io in the pricing section
[15:04] <roaksoax> batkins61: that documentation is OLD and it is in the process of being removed
[15:04] <blake_r> batkins61: with Ubuntu Advantange you get access to All operating systems
[15:04] <roaksoax> batkins61: if you want support for RHEL7, at the moment, you'd need to contact Canonical and get Ubuntu Advantage for MAAS as blake_r just mentioned
[15:08] <batkins61> roaksoax blake_r Thanks, that clarifies things
[15:22] <baldpope> stokachu, ok, just finished wiring up the bonded nics - you mentioned bridge-mappings earlier - where am I supposed to configure that? in conjure, juju, ?
[15:24] <stokachu> baldpope: yea you can do it in conjure-up
[15:24] <stokachu> when you see the list of applications press the [configure] button next to neutron-gateway
[15:24] <stokachu> there you can enter your mappings
[15:24] <baldpope> also created the bonded nic in maas
[15:24] <baldpope> ok, will do that now
[15:39]  * baldpope sigh
[15:39] <baldpope> stokachu, have to pick it up in a bit - dev issue going to take my time for a little bit
[15:43] <stokachu> ok
[16:06] <mup> Bug #1631934 changed: [2.1] Option to not have MTU values on the bridged interface <MAAS:Invalid> <https://launchpad.net/bugs/1631934>
[16:06] <mup> Bug #1632759 opened: Support for images needs to be clarified <MAAS:New> <https://launchpad.net/bugs/1632759>
[16:06] <mup> Bug #1632763 opened: [2.1] Device discovery IP Assignment label incorrect <MAAS:Incomplete> <https://launchpad.net/bugs/1632763>
[16:13] <Prabakaran> Hello Team, Getting timeout issue while commissioning the node in MAAS 1.9, Logs are pasted in here  http://pastebin.ubuntu.com/23301741/ could somebody help me on this?
[16:15] <Prabakaran> Is there any document or video ref to create a Vrish network which uses DHCP /DNS configuration in maas?
[16:35] <roaksoax> Prabakaran: no there's not. you just need a virsh network that doesn't have DHCP managed by the virsh network
[16:38] <brendand> Prabakaran, either use virt-manager -> Edit -> Connection details, or look up virsh net-create
[16:39] <brendand> Prabakaran, you can do like:
[16:39] <brendand> virsh net-dumpxml default > maas.xml
[16:39] <brendand> remove the <dhcp> section
[16:40] <brendand> virsh net-create maas maas.xml
[16:40] <brendand> or rather
[16:40] <brendand> virsh net-create maas.xml (and edit <name> in maas.xml as well)
[16:45] <Prabakaran> brendand:  in the maas console i have edited etho interface management to DHCP + DNS and configured IP, Dynamic ips and Static ip.. Should i reset it also?
[17:54] <mup> Bug #1632763 changed: [2.1] Device discovery IP Assignment label incorrect <MAAS:Won't Fix> <https://launchpad.net/bugs/1632763>
[18:09] <mup> Bug #1632804 opened: ROUNDTTT in configure_networking is effectively ignored <MAAS:New> <initramfs-tools (Ubuntu):New> <https://launchpad.net/bugs/1632804>
[18:15] <mup> Bug #1632804 changed: ROUNDTTT in configure_networking is effectively ignored <MAAS:New> <initramfs-tools (Ubuntu):New> <https://launchpad.net/bugs/1632804>
[18:24] <mup> Bug #1632804 opened: ROUNDTTT in configure_networking is effectively ignored <MAAS:New> <initramfs-tools (Ubuntu):New> <https://launchpad.net/bugs/1632804>
[18:24] <mup> Bug #1632808 opened: configure_networking exits without any ipv6 routes <maas-ipv6> <MAAS:New> <initramfs-tools (Ubuntu):New> <https://launchpad.net/bugs/1632808>
[18:45] <mup> Bug #1632815 opened: Node failed to be released, because of the following error: 'NoneType' object has no attribute 'addErrback' <MAAS:New> <https://launchpad.net/bugs/1632815>
[20:49] <mup> Bug #1632853 opened: [2.1] Observed neighbours should be avoided when assigning IP addresses <MAAS:Triaged by mpontillo> <https://launchpad.net/bugs/1632853>
[20:58] <baldpope> stokachu, neutron-gateway/bridge-mappings
[20:58] <baldpope> set to bond0.$vlan ?
[21:07] <mup> Bug #1632853 changed: [2.1] Observed neighbours should be avoided when assigning IP addresses <MAAS:Triaged by mpontillo> <https://launchpad.net/bugs/1632853>
[21:10] <mup> Bug #1632853 opened: [2.1] Observed neighbours should be avoided when assigning IP addresses <MAAS:Triaged by mpontillo> <https://launchpad.net/bugs/1632853>
[21:40] <mup> Bug #1632862 opened: [2.1. Yakkety] "Map subnet" action doesn't work <MAAS:Triaged> <https://launchpad.net/bugs/1632862>
[21:43] <mup> Bug #1632862 changed: [2.1. Yakkety] "Map subnet" action doesn't work <MAAS:Triaged> <https://launchpad.net/bugs/1632862>
[21:49] <mup> Bug #1632862 opened: [2.1. Yakkety] "Map subnet" action doesn't work <MAAS:Triaged> <https://launchpad.net/bugs/1632862>