[00:11] 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] I get a Python traceback and "failed to start initial cloud-init job" on the console, unsure how to troubleshoot. [00:17] is there a way to roll back an image to a version from a few days ago? [00:31] 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? === frankban|afk is now known as frankban [09:53] Bug #1632638 opened: [2.1 UI] Include table sorting for device discovery [09:53] Bug #1632642 opened: [2.1] Device discovery click on row functionality [11:38] Bug #1632642 changed: [2.1 UI] Device discovery click on row functionality [11:50] Bug #1632642 opened: [2.1 UI] Device discovery click on row functionality [11:59] Bug #1632642 changed: [2.1 UI] Device discovery click on row functionality [12:54] stokachu, ping [12:54] baldpope: o/ [12:54] had a question in response to bug 1632092 [12:55] 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] i was checking out the juju demo pages and (what appears to be) a charm creator - pretty slick btw [12:56] baldpope: ah the juju gui [12:57] up to this point, i had assumed that the combination of conjure/juju understood the infrastructure it was being deployed to automagically [12:57] stokachu, yea - that's some cool shit [12:57] 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] 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] so with juju you can set constraints to deploy certain applications to specific systems in maas [12:59] which you would set in the bundle itself and use conjure-up that way [13:00] 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] baldpope: correct [13:01] 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] via maas [13:01] 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] right, and each of my nodes are 6 nics and 8 hdd [13:02] baldpope: so the charm would expose some options for you to setup bonding [13:02] 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] stokachu, and the charm can be run either before or after base installation? [13:03] both, the config changes should apply without failure at any point of the deployment [13:03] hm [13:04] baldpope: maas also gives you some flexibility on defines your networks [13:04] 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] baldpope: for openstack novalxd we have control over that environment so it can deploy successfully without any configuration [13:05] ok [13:05] baldpope: with maas you still need to perform some configuration via the charm options within conjure-up [13:05] ok, then I think that's the part I've been missing [13:08] 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] does that host also need dual nics and dual drive? [13:09] mine currently does not [13:09] baldpope: you dont need dual nics/hdds for the controller node [13:09] and not knowing how to size it, i simply doled out 4gb ram and 32gb disk [13:09] yea that should be plenty [13:09] k [13:09] conjure-up has --bootstrap-to that you can set to make sure that vm host is used for the controller node [13:10] only applies to a maas deployment [13:10] 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] with 0 being the vm [13:10] but I like the cli option better - no guess work [13:11] yea i wouldnt rely on that sorting im not sure if that's intentional or not [13:11] heh [13:11] that would probably be a juju question [13:11] i thought juju just randomly picked an avaialble machine for the controller node [13:11] fair enough - i'll use the cli option going forward [13:12] 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] that would be interesting to find out [13:12] i should ask juju guys about it [13:13] i could be wrong - maybe (as you said) could be unintentional side effect [13:13] im asking now ill let you know what they say [13:14] cool [13:23] 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] it says name/mac - but only name is listed [13:24] ah fuck,.. [13:24] * baldpope sigh [13:24] nevermind [13:28] :D [13:31] baldpope, but it could be more obvious, honestly [13:37] thanks, appreciate it [13:40] actually, my issue was i had the browser window relatively small, and MAC was partially covered [13:40] when I expanded the window I realized (finally) the link [13:55] 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] did you set bridge-mappings to a list of interfaces to try? [13:55] eno1, along with ens3f1, ens3f2, and ens3f3 are the add-on card [13:55] stokachu, not yea, back and forth with work work [13:56] baldpope: gotcha, try to put them all in the bridge-mappings list [13:56] see if it'll pick up the plugged in one [13:56] stokachu, would I want to bond them together in maas first? [13:56] sure you can do that [13:56] k [13:56] you'd want to do it for all machines [13:56] because you won't know which one gets picked for neutron-gateway [13:57] yea, I had planned to configure each in maas the same way [13:57] cool yea that should be it then [14:53] 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] batkins61, yeah that changed [14:56] ltrager, ^ [14:56] batkins61: you need RHEL not CentOS? [14:59] batkins61: maas-image-builder is no longer available provided it only gave support for CentOS and we now provide centos automatically [15:00] roaksoax, docs claim it supports RHEL as well [15:00] roaksoax the web page says RHEL7 too. [15:01] roaksoax 1.7+ [15:01] https://maas.ubuntu.com/docs/os-support.html [15:02] 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] batkins61: maas.io in the pricing section [15:04] batkins61: that documentation is OLD and it is in the process of being removed [15:04] batkins61: with Ubuntu Advantange you get access to All operating systems [15:04] 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] roaksoax blake_r Thanks, that clarifies things [15:22] 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] baldpope: yea you can do it in conjure-up [15:24] when you see the list of applications press the [configure] button next to neutron-gateway [15:24] there you can enter your mappings [15:24] also created the bonded nic in maas [15:24] ok, will do that now [15:39] * baldpope sigh [15:39] stokachu, have to pick it up in a bit - dev issue going to take my time for a little bit [15:43] ok [16:06] Bug #1631934 changed: [2.1] Option to not have MTU values on the bridged interface [16:06] Bug #1632759 opened: Support for images needs to be clarified [16:06] Bug #1632763 opened: [2.1] Device discovery IP Assignment label incorrect [16:13] 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] Is there any document or video ref to create a Vrish network which uses DHCP /DNS configuration in maas? [16:35] Prabakaran: no there's not. you just need a virsh network that doesn't have DHCP managed by the virsh network [16:38] Prabakaran, either use virt-manager -> Edit -> Connection details, or look up virsh net-create [16:39] Prabakaran, you can do like: [16:39] virsh net-dumpxml default > maas.xml [16:39] remove the section [16:40] virsh net-create maas maas.xml [16:40] or rather [16:40] virsh net-create maas.xml (and edit in maas.xml as well) [16:45] 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? === frankban is now known as frankban|afk [17:54] Bug #1632763 changed: [2.1] Device discovery IP Assignment label incorrect [18:09] Bug #1632804 opened: ROUNDTTT in configure_networking is effectively ignored

[18:15] Bug #1632804 changed: ROUNDTTT in configure_networking is effectively ignored

[18:24] Bug #1632804 opened: ROUNDTTT in configure_networking is effectively ignored

[18:24] Bug #1632808 opened: configure_networking exits without any ipv6 routes

[18:45] Bug #1632815 opened: Node failed to be released, because of the following error: 'NoneType' object has no attribute 'addErrback' [20:49] Bug #1632853 opened: [2.1] Observed neighbours should be avoided when assigning IP addresses [20:58] stokachu, neutron-gateway/bridge-mappings [20:58] set to bond0.$vlan ? [21:07] Bug #1632853 changed: [2.1] Observed neighbours should be avoided when assigning IP addresses [21:10] Bug #1632853 opened: [2.1] Observed neighbours should be avoided when assigning IP addresses === valeech_ is now known as valeech [21:40] Bug #1632862 opened: [2.1. Yakkety] "Map subnet" action doesn't work [21:43] Bug #1632862 changed: [2.1. Yakkety] "Map subnet" action doesn't work [21:49] Bug #1632862 opened: [2.1. Yakkety] "Map subnet" action doesn't work