[00:57] <axw> wallyworld: would you kindly create me a feature branch for azure?
[00:57] <wallyworld> sure
[00:59] <wallyworld> axw: done
[00:59] <axw> wallyworld: thanks
[01:28] <thumper> wallyworld: just once...
[01:28] <thumper> wallyworld: haha RWC 2015 to the All Blacks!!!
[01:28]  * thumper is done now
[01:28] <wallyworld> sigh
[01:28] <wallyworld> i even hopped up at 2am to watch :-(
[01:28] <thumper> Got the family up early to watch it in a pub in Queenstown
[01:29] <thumper> getting the girls up a 4:30am was interesting
[01:29] <wallyworld> worth it though
[01:29] <thumper> yeah, pub was packed, even one guy with a wallabies jersey on
[01:29] <wallyworld> poor bastard
[01:29] <thumper> yeah, I thought he was pretty game
[01:29] <wallyworld> especially if we had won
[01:30] <thumper> heh
[01:30] <thumper> TBH though, I did think that the All Blacks were the better team on the day
[01:30] <anastasiamac> thumper: wasnt it yesterday? did u celebrate this whole time?
[01:30] <thumper> the frustrating times
[01:31] <thumper> are when you feel your team played better but gets pipped at the post
[01:31] <thumper> anastasiamac: it was Sunday morning
[01:31] <thumper> anastasiamac: but I was away for a wedding over the weekend, and was driving home yesterday
[01:32] <anastasiamac> thumper: i watched haka - that's as far as I go :D
[01:32] <anastasiamac> oh and richie mccaw
[01:32] <thumper> anastasiamac: :)
[01:50] <wallyworld> thumper: do you have an eta on removing mult env feature flag in master?
[01:51] <wallyworld> or shoudl i say, mrging in the feature branch?
[01:51] <thumper> wallyworld: wat?
[01:51] <thumper> feature branch was merged for 1.25
[01:51] <thumper> flag being removed for 1.26
[01:53] <wallyworld> thumper: yeah, sorry, what you said above is what i meant
[01:54] <wallyworld> eta for flag removal from master?
[01:54] <thumper> soon
[01:54] <thumper> perhaps this week
[01:54] <thumper> I'm actively working on it
[01:55] <wallyworld> yay, ok
[01:55] <wallyworld> i'll take advantage of that for cross mdel stuff
[01:56]  * thumper nods
[01:56]  * thumper is heading away from internet
[01:57] <thumper> I have to take Maia to jui jitsu, taking laptop and working from the gym while she does her thing
[01:57] <thumper> soon
[02:57] <natefinch> wallyworld: do you know what hotel we're staying at in oakland/
[03:04] <anastasiamac> natefinch: is it not Marriott Oakland City Center?
[03:04] <anastasiamac> cmars: ping?
[03:08] <natefinch> anastasiamac: I don't know.  Did it say that somewhere?
[03:09] <anastasiamac> it's on the spreadsheet, hotel tab
[03:09] <natefinch> anastasiamac: arg... tabs in the spreadsheet.  Honestly, who uses a spreadsheet to disseminate long-form information :/
[03:09] <anastasiamac> :D
[03:09] <anastasiamac> natefinch: i hear ur pain \o/
[03:10] <natefinch> anastasiamac: I must have looked at that spreadsheet three times and never saw the tabs :/
[03:10] <davechen1y> spreadsheets are for making lists of things, duh
[03:11] <davechen1y> word documents are for distributing screenshots
[03:11] <natefinch> *shudder*
[03:11] <anastasiamac> :P
[03:12] <natefinch> trying to figure out if I should just fly into SFO and take a cab, rather than trying to get to oakland airport, which takes 2 hours extra and an extra layover
[03:14] <natefinch> looks like it's 15 minutes from Oakland airport and 30 from SFO
[03:14] <anastasiamac> it depends - do u like flying?
[03:14] <anastasiamac> u r very lucky to have a choice :D
[03:16] <anastasiamac> i'd imagine flying to Oakland will also be a smaller plane than to SFO (m not gr8 fun of small planes)
[03:16] <wallyworld> natefinch: marriott
[03:16] <wallyworld> 1001 broadway
[03:18] <natefinch> wallyworld: thanks.  realized I was being dumb and missed the hotels tab on the spreadsheet.  Someday I'll remember that's there.
[03:19] <wallyworld> yeah, easy to do
[03:24] <cherylj> axw: ping?
[03:24] <axw> cherylj: pong
[03:25] <cherylj> hey axw :)  I'm looking at bug 1512399 and it looks like the error they're getting is a TLS error
[03:25] <mup> Bug #1512399: ERROR environment destruction failed: destroying storage: listing volumes: Get https://x.x.x.x:8776/v2/<UUID>/volumes/detail: local error: record overflow <amulet> <openstack> <uosci> <juju-core:Triaged> <https://launchpad.net/bugs/1512399>
[03:25] <cherylj> and I'm wondering if it's a config error?  or if you've seen that in your testing?
[03:27] <axw> cherylj: I have not seen that. we have a separate API for Cinder, so it's most likely we're not configuring the client for it the same way we do the other clients
[03:28] <cherylj> axw: ok, thanks!  I'll keep looking
[04:20] <davechen1y> running the juju/state tets
[04:21] <davechen1y> i can see mongo using 1/2 a core
[04:21] <davechen1y> that seems excessive
[04:21] <davechen1y> can anyone confirm ?
[04:22] <davechen1y> select(9, [7 8], NULL, NULL, {0, 10000}) = 0 (Timeout)
[04:22] <davechen1y> billions and billions of these
[04:23] <natefinch> davechen1y: yeah, usually 40-50% of a core for me most of the time, except when it jumps to the occasionaly 180%
[04:23] <mup> Bug #1512566 changed: Panic in deployerSuite unittests while attempting to connect to mongo <ci> <test-failure> <unit-tests> <juju-core:New> <https://launchpad.net/bugs/1512566>
[04:25] <davechen1y> i wonder if mongo 3.0 will be better
[04:26] <natefinch> not sure if a faster car will make towing the giant boulder behind us much easier
[04:26] <mup> Bug #1512566 opened: Panic in deployerSuite unittests while attempting to connect to mongo <ci> <test-failure> <unit-tests> <juju-core:New> <https://launchpad.net/bugs/1512566>
[04:27] <natefinch> ....or some other analogy saying our tests suck
[04:30] <davechen1y> any "database" that consumes 50% cpu with a single client
[04:30] <davechen1y> owns the market on suckage
[04:34] <davechen1y> oh fucking golf cla
[04:34] <davechen1y> now mongo used up all my /tmp
[04:34] <davechen1y> all 8gb
[04:41] <mup> Bug #1512566 opened: Panic in deployerSuite unittests while attempting to connect to mongo <ci> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1512566>
[04:41] <mup> Bug #1512569 opened: UniterSuite.TestRebootNowKillsHook fails with: uniter still alive <ci> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1512569>
[04:44] <mup> Bug #1512569 changed: UniterSuite.TestRebootNowKillsHook fails with: uniter still alive <ci> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1512569>
[04:47] <mup> Bug #1512569 opened: UniterSuite.TestRebootNowKillsHook fails with: uniter still alive <ci> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1512569>
[09:07] <fwereade_> axw, http://reviews.vapour.ws/r/3045/ may be relevant to your interests
[09:08] <fwereade_> anyone else, http://reviews.vapour.ws/r/3032/ is a few days old and could use a review (and should be trivial)
[09:14] <voidspace> fwereade_: looking at the second
[09:14] <fwereade_> voidspace, ta
[09:15] <voidspace> waiting for an environment to bootstrap anyway
[09:18] <axw> fwereade_: my brain is a bit fried, will take a look tomorrow. skimming through it looks good. NewWorker in config bothers me, but will have to ruminate
[09:19] <fwereade_> axw, yeah, that's the main thing I'm ambivalent about
[09:19] <fwereade_> axw, I can't think of a good reason not to do it, though :-/
[09:19] <fwereade_> axw, (NewFacde less bothersome?)
[09:20] <fwereade_> axw, (I feel they're as bad as one another)
[09:20] <fwereade_> axw, anyway don't think about it now :)
[09:20] <axw> fwereade_: a little :)  NewFacade bothers me less because you're configuring an external resource
[09:20] <axw> fwereade_: whereas the worker is an internal detail
[09:20] <axw> fwereade_: I guess neither would bother me if the manifold were in a different package
[09:21] <fwereade_> axw, yeah, I've been feeling some of them pulling that way as well
[09:21] <fwereade_> axw, and I don't think a given worker type will necessarily always want the same manifold
[09:22] <fwereade_> axw, but for now, it seems least wrong to put them with the workers
[09:22] <fwereade_> will think more on it
[09:29] <voidspace> fwereade_: LGTM bar one typo
[09:33] <fwereade_> voidspace, cheers
[10:22] <fwereade_> http://reviews.vapour.ws/r/3045/diff/#
[11:49] <voidspace> frobware: looks like I an upgrade from 1.22.8 to 1.24 tip with upload-tools
[11:49] <voidspace> which is good news
[11:49] <frobware> voidspace, yep
[12:19] <dimitern> my NUCs et al have just arrived!
[12:28] <perrito666> morning
[12:29] <perrito666> dimitern: I envy you a lot right now
[12:29] <dimitern> perrito666, :) don't - considering the amount of work we need to do in the next 3 weeks on those NUCs
[12:51] <rick_h__> go go gadget dimitern
[12:51] <dimitern> rick_h__, :) indeed
[12:51] <dimitern> rick_h__, nice ODS talk btw!
[12:51] <rick_h__> dimitern: thanks
[13:03] <jam> rick_h__: are you around for the meetup ?
[13:03] <dimitern> frobware, oh sorry, omw
[13:05] <rick_h__> jam: yes sorry
[13:09] <voidspace> dimitern: is the maas meeting on today?
[13:18] <dimitern> voidspace, yep
[13:30] <voidspace> dimitern: thanks
[13:58] <voidspace> frobware: I was wrong by the way - 1.22.8 to 1.24 tip fails. It just fails without error message.
[14:07] <cmars> why is master still blocked? is CI running on it yet?
[14:19] <mup> Bug #1512718 opened: Leader election fails with "leadership failure: leadership manager stopped" <landscape> <juju-core:New> <https://launchpad.net/bugs/1512718>
[14:20] <natefinch> ericsnow: did we update the version of reviewboard we're using?  Seems like it handles file moves a lot better than it did just a week or so ago.
[14:38] <frobware> cherylj, ping - does your vMAAS setup have a static IP range set for the cluster controller / interface?
[14:45] <ericsnow> natefinch: nope :)
[14:48] <natefinch> ericsnow: weird, I swear the last time I looked at your renaming review, it was all screwed up because reviewboard just showed renames as deletes and adds, but now it looks fine.  Maybe I'm just crazy.
[14:49] <perrito666> natefinch: rb is a sentient being and tries to make you doubt your sanity
[14:49] <natefinch> perrito666: I can believe it
[14:49] <perrito666> off course you can, it is true
[15:07] <cherylj> frobware: I have it set up to use a particular virtual network I created
[15:07] <perrito666> does anyone know exactly what is responsible for ~ expansion? I am trying to do an exec.Command with ~ on a path and it is not being expanded
[15:08] <voidspace> perrito666: it's the shell that does it not the os
[15:09] <perrito666> voidspace: mm, I presume that for this to work the process I should be running with exec.Command its bash
[15:09] <voidspace> perrito666: that would work, but beware of windows
[15:09] <voidspace> perrito666: or you can do the expansion yourself
[15:10] <perrito666> I could totally wear a shirt with that "beware of windows"
[15:10] <perrito666> voidspace: true
[15:10] <voidspace> :-)
[15:18] <rogpeppe> trivial change to environs/config, so that I don't need to do an error string comparison... anyone want an easy review? http://reviews.vapour.ws/r/3047/
[15:39] <cmars> why is master still blocked? is CI running on it yet?
[15:40] <cmars> sinzui, mgz_ ^^
[15:41] <sinzui> cmars: ci hasn't tested a pass yet. I believe master will be retested in a few hours.
[15:41] <cmars> sinzui, ok, thanks
[15:52] <frobware> cherylj, do you have time for a quick HO?
[15:52] <cherylj> frobware: I have 8 minutes :)  is that enough time?
[15:52] <frobware> yep
[15:53] <frobware> cherylj, https://plus.google.com/hangouts/_/canonical.com/juju-sapphire
[15:53] <cherylj> I'm there
[16:43] <mup> Bug #1512782 opened: wget cert issues causing failure to create containers <cloud-installer> <juju-core:Triaged> <https://launchpad.net/bugs/1512782>
[16:46] <mup> Bug #1512782 changed: wget cert issues causing failure to create containers <cloud-installer> <juju-core:Triaged> <https://launchpad.net/bugs/1512782>
[17:01] <mup> Bug #1512782 opened: wget cert issues causing failure to create containers <cloud-installer> <juju-core:Triaged> <https://launchpad.net/bugs/1512782>
[17:15] <rogpeppe> mgz_: any chance we might get a CI run on master today?
[17:16] <mgz_> rogpeppe: it'll happen shortly
[17:16] <rogpeppe> mgz_: cool
[17:16] <natefinch> and then the stampede to get stuff landed before it breaks again
[17:17] <rogpeppe> mgz_: istm that 24 hours to unblock after critical bugfix gets landed is probably too long
[17:17] <natefinch> ^ +1
[17:18] <rogpeppe> for our feature branch it was more like 7 days.
[17:19] <natefinch> mgz_: is it a resources problem?  i.e. do we not have an environment dedicated to running CI on master?
[17:19] <mgz_> natefinch: every ci run is against a bunch of environments
[17:20] <natefinch> mgz_: sorry, overloaded term.  Do we not have dedicated hardware for CI runs on master?
[17:20] <natefinch> mgz_: maybe a better way to phrase it is - it sounds like CI on master can be blocked by other CI runs.  Is there a way we can make that not so?
[17:20] <mgz_> well, we're still talking about a whole bunch of machines in different cloud provuders
[17:21] <mgz_> so, two things
[17:21] <mgz_> we're getting new hardware for maas Soon hopefully, which is a major bottleneck
[17:21] <natefinch> good
[17:22] <mgz_> also abentley has been getting parallel streams working over the past few weeks, which means we can run more than one revision in across clouds
[17:25] <mgz_> anyway, the reson this was slow is that the rev was tested and failed (for unrelated env issues, machine ran out of root disk),
[17:26] <mgz_> so needed someone to wake up and get it run again, any aussie could have done that
[17:26] <natefinch> obviously we need to hire an aussie for the QA team
[17:36] <katco> mgz_: hey you all had started writing ci tests for the rackspace provider, correct?
[17:36] <mgz_> katco: there's not really tests to write
[17:37] <mgz_> we just need rackspace creds we can use, and then we can use the existing provider tests
[17:37] <katco> mgz_: ah great! is anything blocking you on getting those creds?
[17:37] <mgz_> well, I have a non-functional personal account,
[17:38] <mgz_> ideally we'd have a system of getting creds as a company, but that's never really happened in the past
[17:38] <katco> mgz_: i'll ping alexisb to see what we need to do
[17:43] <katco> mgz_: i also need to bug someone about what it would take to get CI testing the LXD provider
[19:25] <mup> Bug # changed: 1302118, 1392814, 1464304, 1485784
[19:25] <mup> Bug #1512847 opened: Unit suffix incremented after fresh post-destroy-service deploy <juju-core:New> <https://launchpad.net/bugs/1512847>
[19:33] <thumper> haha
[19:33] <thumper> bug 1512847 now complaining about our "correct" behaviour
[19:33] <mup> Bug #1512847: Unit suffix incremented after fresh post-destroy-service deploy <juju-core:New> <https://launchpad.net/bugs/1512847>
[19:34]  * thumper wonders what the original bug number was that outlined the behaviour....
[19:38] <mup> Bug #1512847 changed: Unit suffix incremented after fresh post-destroy-service deploy <juju-core:New> <https://launchpad.net/bugs/1512847>
[19:38] <mup> Bug # opened: 1302118, 1392814, 1464304, 1485784
[19:44] <mup> Bug # changed: 1302118, 1357045, 1392814, 1464304, 1485784, 1494476, 1498982, 1500703, 1500721, 1500769, 1500803, 1501173, 1501559, 1501637, 1501642, 1501710, 1505648
[19:44] <mup> Bug #1512847 opened: Unit suffix incremented after fresh post-destroy-service deploy <juju-core:New> <https://launchpad.net/bugs/1512847>
[19:53] <mup> Bug # opened: 1357045, 1494476, 1498982, 1500703, 1500721, 1500769, 1500803, 1501173, 1501559, 1501637, 1501642, 1501710, 1505648
[19:56] <mup> Bug # changed: 1357045, 1494476, 1498982, 1500703, 1500721, 1500769, 1500803, 1501173, 1501559, 1501637, 1501642, 1501710, 1505648
[20:24] <thumper> sinzui: master is still blocked?
[20:24] <thumper> it is the same bug as yesterday...
[20:25] <sinzui> yes, thumper master is being retested now
[20:25] <thumper> why has it taken over 24 hours? just curious
[20:38] <davecheney> thumper: https://github.com/golang/go/issues/13137
[20:38] <davecheney> upstream issue for the ssh blocker that prevents me moving the ssh code to juju/utils
[20:39] <davecheney> thumper: i also tried adding dependencies.tsv to juju/utils to pin the ssh version
[20:39] <davecheney> by our build bot doesn't understand that
[20:40] <natefinch> thumper: I asked the same question earlier, sounds like the build machine ran out of disk space, so needed manual intervention
[21:01] <thumper> ah
[21:12]  * natefinch needs to write a bot that'll watch master's CI status and auto-$$merge$$ his PR when master unblocks.
[21:17] <mup> Bug #1512875 opened: juju 1.25.0 using MAAS 1.9-beta2 juju incorrectly reports the private address <addressability> <maas-provider> <networking> <juju-core:New> <https://launchpad.net/bugs/1512875>
[21:26] <mup> Bug #1512875 changed: juju 1.25.0 using MAAS 1.9-beta2 juju incorrectly reports the private address <addressability> <maas-provider> <networking> <juju-core:New> <https://launchpad.net/bugs/1512875>
[21:28] <sinzui> wallyworld: can you review http://reviews.vapour.ws/r/3050/
[21:28] <wallyworld> sure
[21:29] <wallyworld> another difficult one
[21:29] <mup> Bug #1512875 opened: juju 1.25.0 using MAAS 1.9-beta2 juju incorrectly reports the private address <addressability> <maas-provider> <networking> <juju-core:New> <https://launchpad.net/bugs/1512875>
[21:32] <mup> Bug #1512847 changed: Unit suffix incremented after fresh post-destroy-service deploy <juju-core:Invalid> <https://launchpad.net/bugs/1512847>
[21:56] <mup> Bug #1367962 changed: HTML entities accidentally escaped <docs> <juju-core:Fix Released by cjohnston> <https://launchpad.net/bugs/1367962>
[22:26] <mup> Bug # changed: 1439375, 1456851, 1476918, 1486254, 1492095, 1497241, 1500283, 1502202, 1506353, 1509097, 1509292
[22:29] <mup> Bug # opened: 1439375, 1456851, 1476918, 1486254, 1492095, 1497241, 1500283, 1502202, 1506353, 1509097, 1509292
[22:38] <mup> Bug # changed: 1439375, 1456851, 1476918, 1486254, 1492095, 1497241, 1500283, 1502202, 1506353, 1509097, 1509292
[22:39] <anastasiamac> cmars: ping :D
[23:14] <mup> Bug #1511717 changed: Incompatible cookie format change <blocker> <ci> <compatibility> <regression> <juju-core:Fix Released by cmars> <juju-core 1.25:In Progress by cmars> <juju-core 1.26:Fix Committed by cmars> <https://launchpad.net/bugs/1511717>
[23:17] <mup> Bug #1511717 opened: Incompatible cookie format change <blocker> <ci> <compatibility> <regression> <juju-core:Fix Released by cmars> <juju-core 1.25:In Progress by cmars> <juju-core 1.26:Fix Committed by cmars> <https://launchpad.net/bugs/1511717>
[23:23] <mup> Bug #1511717 changed: Incompatible cookie format change <blocker> <ci> <compatibility> <regression> <juju-core:Fix Released by cmars> <juju-core 1.25:In Progress by cmars> <juju-core 1.26:Fix Committed by cmars> <https://launchpad.net/bugs/1511717>
[23:25] <perrito666> anastasiamac: send me the song name
[23:26] <davecheney> thumper: upstream told us to go stuffed on the ssh problem
[23:26] <davecheney> thumper: where did the go 1.5 discussion go after we talked yesterday ?
[23:27] <anastasiamac> perrito666: tyvm for reminder :D i will as soon as my DJ gets back to me
[23:30] <thumper> davecheney: sorry, dropped the ball on that email, will do it now
[23:34] <davecheney> thumper: thanks
[23:34] <davecheney> what's going on with the build
[23:34] <davecheney> is it unblocked uet ?
[23:34] <davecheney> oh goody it is
[23:34] <thumper> waigani: I've just created a feature branch "controller-rename"
[23:34] <thumper> which I'll retarget my landings against
[23:34] <waigani> thumper: that's a good idea
[23:35] <thumper> I have a feeling we may break some CI tests :)
[23:35] <thumper> so best to get it in a feature branch IMO
[23:35] <thumper> especially taking off the feature flag
[23:35] <waigani> that will help me land this destroy*System* work too
[23:35] <waigani> as I can just finish off the logic and then merge in the controller stuff
[23:36] <thumper> waigani: also means we can do final checks to make sure we catch all the system names
[23:36] <waigani> right
[23:36] <thumper> waigani: probably best to see if we can get your stuff landed first
[23:36]  * thumper hopes
[23:36] <waigani> okay
[23:36] <waigani> on it :)
[23:37] <davecheney> sinzui: ping
[23:37] <davecheney> sinzui: i have a problem trying to land https://github.com/juju/utils/pull/167
[23:37] <mgz_> davecheney: did you read my comment?
[23:37] <davecheney> the build bot doesn't seem to respect dependencies.txt
[23:38] <davecheney> mgz_: thanks for replying
[23:38] <davecheney> i added a dependencies.tsv to pin the crypto repo to a specific revision
[23:38] <davecheney> but the bot doesn't appear to use it
[23:38] <mgz_> davecheney: you need to add *all* the dependencies
[23:38] <davecheney> ok
[23:38] <davecheney> but how does the bot know ?
[23:38] <mgz_> I can make the bot get the deps with godeps
[23:38] <davecheney> i can add all the deps to that PR
[23:39] <davecheney> can you switch the bot to using godeps please ?
[23:39] <mgz_> but it's either go get *or* godeps, we can't mix and match
[23:39] <davecheney> understood
[23:39] <davecheney> i'll ammend the PR to have a complete set of dependencies
[23:39] <mgz_> so, I can switch the bot, and the branch will still fail for now
[23:39] <mgz_> k
[23:39] <davecheney> give me a few mins
[23:39] <davecheney> won't take long
[23:40] <mgz_> this is baiscally, in the config of the github-merge-juju-utils job (access is in the consoles.txt file in cloud-city),
[23:41] <mgz_> s/--go-get-all/--tsv-path $PROJECT_PATH/dependencies.tsv/
[23:42] <davecheney> mkay
[23:42] <mgz_> anyway, retry when ready
[23:43] <davecheney> mgz_: thanks, i'll be able to fix this on my own if I find deps I haven't pinned
[23:52] <cmars> master be all like: https://i.giphy.com/11Ss9q3F4zf5VC.gif
[23:52] <cmars> anastasiamac, pong
[23:53] <anastasiamac> cmars: send u an email but if u want to HO, can do too :D
[23:54] <cmars> anastasiamac, right, blueprint. i'll try to update it soon
[23:54] <anastasiamac> cmars: \o/
[23:56] <anastasiamac> cmars: love the pic btw :D indeed feels like when it unblocks :P


[00:37] <mup> Bug #1635097 changed: Can't assign SSH-Keys to user via maas-cli <MAAS:Invalid> <https://launchpad.net/bugs/1635097>
[00:49] <mup> Bug #1635097 opened: Can't assign SSH-Keys to user via maas-cli <MAAS:Invalid> <https://launchpad.net/bugs/1635097>
[00:55] <mup> Bug #1635097 changed: Can't assign SSH-Keys to user via maas-cli <MAAS:Invalid> <https://launchpad.net/bugs/1635097>
[03:11] <mup> Bug #1635493 opened: A wishlist to be able to destroy root filesystem after release <MAAS:New> <https://launchpad.net/bugs/1635493>
[07:08] <gaurangt> hi.. I've deployed MAAS in virtual environment and testing a charm.. but it is failing to use the storage disk which is already attached to the VM (though commissioning detected the disks properly).
[07:09] <gaurangt> I saw an error Error: /dev/sda: unrecognised disk label Error: /dev/sdb: unrecognised disk label
[07:09] <gaurangt> Any help would be really appreciated.
[08:51] <mup> Bug #1635560 opened: MAAS2: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 277: ordinal not in range(128) <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1635560>
[08:58] <gaurangt> anyone tried KVM + MAAS + Juju ?
[09:00] <mup> Bug #1635560 changed: MAAS2: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 277: ordinal not in range(128) <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1635560>
[09:03] <mup> Bug #1635560 opened: MAAS2: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 277: ordinal not in range(128) <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1635560>
[15:23] <mup> Bug #1635653 opened: Maas xenial dailies no longer able to deploy <MAAS:New> <maas-images:New> <https://launchpad.net/bugs/1635653>
[15:54] <Braven> hello all
[15:55] <Braven> I need help with setting up MAAS DNS setting for dhcp.
[16:39] <nturner> Are 2.1 updates going to be pushed to ppa:maas/stable?
[16:46] <brendand> nturner, it's in lp:maas/next
[16:46] <brendand> nturner, we could push it to stable as well i suppose
[16:57] <nturner> brendand: if one wanted to track 2.1 (vs. rolling on to 2.2alpha or whatever comes next), what's the best way?
[16:58] <nturner> also, is the fix for https://bugs.launchpad.net/maas/+bug/1632395 in maas/next?
[17:02] <brendand> nturner, maas/next is best. that will always be the latest development release
[17:02] <brendand> nturner, maas/stable is what's stable for that os version
[17:03] <nturner> brendand: so there's no way to track 2.1-stable on xenial?
[17:03] <brendand> nturner, the way to get 2.1 on xenial atm is to use next
[17:04] <nturner> tracking the dev version is great, but it could be nice to have one deployment that's tracking a stable release
[17:04] <brendand> nturner, and the bug is fixed in there
[17:04] <nturner> 2.1 seems pretty solid right now, but during the alpha phase, there was some breakage
[17:04] <nturner> presumably that will happen again during the next dev cycle
[17:05] <brendand> nturner, indeed
[17:05] <nturner> so if i want to maintain a deployment that tracks 2.1, I should upgrade to yakkety and track maas/stable it sounds
[17:05] <nturner> like.
[17:09] <brendand> nturner, well stable is defined as 'what's stable for that os'
[17:09] <brendand> eventually 2.1 will be backported to xenial, but for now it's only considered stable on yakkety
[17:09] <brendand> and it's not in that ppa yet
[17:09] <brendand> i say os, i mean release
[17:11] <brendand> so yeah, for now if you want a deployment using 2.1 that is stable your only choice is to just use yakkety straight up
[17:12] <brendand> no ppa
[17:15] <nturner> brendand: ok, that's cool
[17:18] <suchvenu> Hi
[17:19] <suchvenu> I am trying to deploy Openstack charm from the store : https://jujucharms.com/openstack-base/
[17:20] <suchvenu> I have a KVM and MAAS is configured in one guest from that box. Juju is installed and could deploy a sample charm as well.
[17:20] <suchvenu> However when i deploy Openstack charm from store I get "Failed deployment" as the status
[17:21] <suchvenu> The MAAS log ahows as :
[17:21] <suchvenu> Oct 20 15:38:32 maascontroller maas.node: [INFO] vm3: Status transition from DEPLOYING to FAILED_DEPLOYMENT Oct 20 15:38:32 maascontroller maas.node: [ERROR] vm3: Marking node failed: Node operation 'Deploying' timed out after 0:40:00. Oct 20 15:38:37 maascontroller maas.node: [INFO] vm4: Status transition from DEPLOYING to FAILED_DEPLOYMENT
[17:22] <suchvenu> Any idea on this error ? Will increasing the timeout fix the issue ?
[18:09] <swjen> hi! does any know why machines wont show up in MAAS after PXE boot? I am running MAAS 2.0 on bare metal and trying to "enlist" another bare metal machine. both are on the same vlan.
[18:30] <deej> Hey all, I'm running into an issue with MaaS 1.9 where nodes are getting an IP set up properly in DNS, but then getting a totally different IP via DHCP
[18:30] <deej> And I'm not sure where that DHCP IP is coming from or how to get rid of it, it only seems to happen occasionally
[18:30] <deej> Has anyone seen that before and/or can point me in the direction of how to get that extraneous IP out of the node definition?
[20:13] <pmatulis> what exactly does the 'abort' node action do again?
[20:15] <deej> pmatulis: Aborts a ongoing action, i.e. commissioning/deploying
[20:16] <pmatulis> deej, does it apply to any action?
[20:16] <deej> I assume so
[20:16] <deej> I actually don't know for sure
[20:17] <pmatulis> deej, ok
[22:04] <mup> Bug #1635735 opened: MaaS 1.9 not deleting discovered addresses from commissioning <MAAS:New> <https://launchpad.net/bugs/1635735>