[16:30] hey folks, i'm trying to bootstrap my juju controller on MAAS, and it's giving me an error bc it can't find a machine that matches its constraints; one of my machines isn't seeing any RAM when it commissions, is why, but when i try to force a memory constraint to be 0.0 it doesn't work. any ideas? === stormmore is now known as Budgie^Smore [16:48] vasey: hmm, so maas has the ram information or maas doesn't have the information? [16:49] vasey: the thing would be to drop the constraint then if it's not going to be able to match. A machine with 0 ram doesn't really mean anything unfortunately. We can file a bug that it should treat it as an empty constraint [16:49] vasey: but just dropping off the ram constraint should be ok? [17:06] rick_h: maas doesn't have the ram information, it thinks it's 0.0GB [17:07] when i try to add a ram constraint it doesn't override the 3584 MB constraint that's default for the maas bootstrap command [17:09] vasey: can you recommission the node to pick up the memory info? [17:11] i tried, it doesn't help :( [17:12] vasey: hmm, I wonder if we can work around it. Can you add a tag to the machine in MAAS and then use the tags constraint to pick that machine? [17:13] vasey: it should override/skip any memory/default constraints [17:13] oh i'll try that! thanks [17:13] vasey: yea sorry. I'm not sure how to replicate it to test it since MAAS picks up the memory in my setup [17:14] vasey: I wonder why maas is coming up empty [17:15] https://pastebin.com/54gTvTz8 here's the output when i try that [17:15] looks like it still wants the memory constraint to be in effect [17:24] bah humbug...hmm [17:24] vasey: can you file a bug here with your commands/etc you've tried out? https://launchpad.net/juju [17:28] will do! [17:32] done [17:32] vasey: ty, sorry I can't think of another way around it atm. So if you say mem= or mem=0.0 it won't work either? can you pastebin the --debug output there? [17:33] both of those mem constraints don't work unfortunately [17:33] i'll send you the debug in a sec [17:37] rick_h: https://pastebin.com/YSGrp4tZ [17:37] vasey: hmm, so it seems it just doesn't listen to them at all then [17:38] vasey: k, sorry for the trouble. I'd love to get the info into maas and while we could work around this after bootstrap with direct placement, we can't do that on bootstrap. :/ [17:38] vasey: I guess you could try the the manual provider route but that's obviously not the smooth UX we're shooting for [18:01] rick_h: how do you do the manual provider route? [18:02] vasey: so you'd need to turn on the machines through maas and bootstrap to it over ssh. https://jujucharms.com/docs/stable/clouds-manual walks you through it [18:02] thanks [19:11] o/ juju world [21:32] verterok: how/where did you deploy spark when it resulted in http://paste.ubuntu.com/24494765/? [21:42] kwmonroe: hi [21:43] kwmonroe: in canonical DC [21:44] kwmonroe: using a mojo spec, but nothing fancy, just spark + nrpe [21:46] kwmonroe: let me try with a clean mojo workspace [21:47] hmm, it's weird verterok, spark-34 tested clean last week across the clouds (and hasn't changed since): http://bigtop.charm.qa/cwr_bundle_spark_processing/63/report.html [21:49] kwmonroe: maybe it's failing because of the restrictions we have in our DC? [21:49] kwmonroe: gimme a couple, the deploy is running [21:51] kwmonroe: same error: spark/0* error idle 0 10.50.84.52 hook failed: "install" [21:54] verterok: yeah, i'm going to guess it's a restricted network thing.. and a good enough reason to hold the un-prom for apache-* until we can fix the current stuff.