[01:49] <designated> blake_r, got a 401 response during juju bootstrap, both the node being commissioned and the maas node have the correct time settings in bios.  /var/log/maas/maas.log show the following: OAuthUnauthorized: 'Expired timestamp: given 1401305369 and now 1401326866 has a greater difference than threshold 300'
[01:50] <designated> i found an old bug that discusses this issue but it was supposedly fixed, plus both nodes should be syncing with ubuntu's NTP server.
[02:03] <designated> argg...cannot sync with ntp.ubuntu.com.  don't know what's going on there.
[04:01] <designated> apparently the bootstrap node is being configured with a timezone of UTC which is causing oauth failure.  How do I change it from UTC?
[09:33] <blake_r> designated: were you able to get ntp.ubuntu.com to work?
[12:39] <allenap> jtv: Fancy a quick non-MAAS review? https://code.launchpad.net/~allenap/rabbitfixture/rabbitmq-3.3-and-later/+merge/221368
[12:52] <jtv> allenap: approved
[12:53] <allenap> jtv: Thanks!
[15:43] <designated> blake_r, I did get ntp.ubuntu.com to work.  the problem that I was having was maas had a timezone of MDT but was booting nodes with UTC so there was a 6 hour time difference, causing OAUTH to fail.  I altered the preseed to set time to MDT, that resolved the issue.
[15:44] <blake_r> designated: cool, glad you go it to work
[15:47] <designated> blake_r, building new preseeds this morning to handle NIC mapping inconsistencies and proper disk partitioning for each node.  I'm assuming a juju charm will have the ability to do NIC bonding but no one in the juju channel was talking last night :)  otherwise I may have to use curtin to bond nics.
[15:54] <blake_r> designated: well curtin can do it
[15:54] <blake_r> designated: just "curtin in-target ...."
[15:54] <blake_r> designated: hopefully that will give you the ability you want
[16:27] <designated> blake_r, first i have to figure out WTH happened with udev in 14.04.  They changed the default behavior to use firmware/bios index numbers for onboard nics in the naming scheme but pci nicsget named according to a completely different method.  you wind up with something like emX for your onboard NICS and ethX for your PCI nics, only add-on hardware winds up in the 70-persistent-net.rules file.  back to same problem of inconsistencies acros
[16:27] <designated> s multiple servers.  According to http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ this is supposed to resolve the problems we were seeing but it seems overly complicated for no apparent reason.
[16:28] <designated> gonna digest this documentation to figure out the best way to proceed.
[16:29] <designated> they addressed the problems associated with inconsistencies for a single server, but this doesn't make it anymore predictable if I have 100s of servers that need to be consistent.
[16:38] <blake_r> designated: i am surprised you are having so many inconsistencies with nic naming, the should normally come up in the same order
[16:42] <designated> blake_r, check this out
[16:42] <designated> 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
[16:42] <designated>     link/ether 00:8c:fa:0d:4e:38 brd ff:ff:ff:ff:ff:ff
[16:42] <designated> 3: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
[16:42] <designated>     link/ether 00:a0:d1:ed:77:e4 brd ff:ff:ff:ff:ff:ff
[16:42] <designated> 4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
[16:42] <designated>     link/ether 00:8c:fa:0d:4e:39 brd ff:ff:ff:ff:ff:ff
[16:42] <designated> 5: em2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
[16:42] <designated>     link/ether 00:a0:d1:ed:77:e5 brd ff:ff:ff:ff:ff:ff
[16:42] <designated> went from eth0 to eth2...where is eth1?  on another server, it was completely different.
[16:44] <designated> I think I'm just going to disregard the changes and write out my own persistent-net.rules file to override all of this nonsense :)
[16:52] <blake_r> designated: yeah that is wierd
[19:48] <designated> blake_r, I'm reading http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/curtin/utopic/view/head:/doc/topics/overview.rst but it's not entirely clear where these commands would go.  it looks like they would go here: /etc/maas/preseeds/curtin_userdata, but the syntax is different.  /etc/maas/preseeds/curtin only contains "{{preseed_data}}", not sure exactly what that is a reference to, unless it's the preseed file but I thought curti
[19:48] <designated> n didn't use preseeds.  is there a link to more comprehensive curtin documentation?
[20:04] <AskUbuntu> How can build relation between Rabbitmq-Server (as buffer for request interface) for my owm locla charm( process the requests) | http://askubuntu.com/q/474097
[20:07] <blake_r> designated: they do go in curtin_userdata
[20:07] <blake_r> designated: http://astokes.org/customizing-fastpath-curtin-installations/
[20:28] <designated> blake_r, thanks
[20:55] <designated> in maas I have the default distro for commissioning and deployment set to trusty, but when i deploy a juju charm, it installs precise...
[20:56] <designated> i wonder if that has something to do with the charm
[21:01] <roadmr> designated: not sure if juju's documentation is up to date but: "The default series for MAAS will automatically be set to 'precise'. You can override this setting by adding the optional configuration: default-series: trusty"
[21:03] <designated> roadmr_afk, yeah i just figured out juju set-env "default-series=trusty" will fix it, but then not all charms exists in the trusty charm store :/
[21:04] <designated> yay :)
[22:30] <AskUbuntu> Ubuntu MAAS Setup - Newbie - adding nodes | http://askubuntu.com/q/474140
[22:51] <designated> blake_r, do you know if variables and conditional statements in a preseed will work?
[22:51] <designated> something similar to the following:
[22:51] <designated> SETTIMEZONE=TRUE
[22:51] <designated> TIMEZONE="US/MOUNTAIN"
[22:51] <designated> {{if SETTIMEZONE}}
[22:51] <designated> d-i	time/zone string $TIMEZONE
[22:51] <designated> {{endif}}