[16:30] <vasey> 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?
[16:48] <rick_h> vasey: hmm, so maas has the ram information or maas doesn't have the information?
[16:49] <rick_h> 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] <rick_h> vasey: but just dropping off the ram constraint should be ok?
[17:06] <vasey> rick_h: maas doesn't have the ram information, it thinks it's 0.0GB
[17:07] <vasey> 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] <rick_h> vasey: can you recommission the node to pick up the memory info?
[17:11] <vasey> i tried, it doesn't help :(
[17:12] <rick_h> 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] <rick_h> vasey: it should override/skip any memory/default constraints
[17:13] <vasey> oh i'll try that! thanks
[17:13] <rick_h> 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] <rick_h> vasey: I wonder why maas is coming up empty
[17:15] <vasey> https://pastebin.com/54gTvTz8 here's the output when i try that
[17:15] <vasey> looks like it still wants the memory constraint to be in effect
[17:24] <rick_h> bah humbug...hmm
[17:24] <rick_h> vasey: can you file a bug here with your commands/etc you've tried out? https://launchpad.net/juju
[17:28] <vasey> will do!
[17:32] <vasey> done
[17:32] <rick_h> 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] <vasey> both of those mem constraints don't work unfortunately
[17:33] <vasey> i'll send you the debug in a sec
[17:37] <vasey> rick_h: https://pastebin.com/YSGrp4tZ
[17:37] <rick_h> vasey: hmm, so it seems it just doesn't listen to them at all then
[17:38] <rick_h> 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] <rick_h> 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] <vasey> rick_h: how do you do the manual provider route?
[18:02] <rick_h> 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] <vasey> thanks
[19:11] <Budgie^Smore> o/ juju world
[21:32] <kwmonroe> verterok: how/where did you deploy spark when it resulted in http://paste.ubuntu.com/24494765/?
[21:42] <verterok> kwmonroe: hi
[21:43] <verterok> kwmonroe: in canonical DC
[21:44] <verterok> kwmonroe: using a mojo spec, but nothing fancy, just spark + nrpe
[21:46] <verterok> kwmonroe: let me try with a clean mojo workspace
[21:47] <kwmonroe> 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] <verterok> kwmonroe: maybe it's failing because of the restrictions we have in our DC?
[21:49] <verterok> kwmonroe: gimme a couple, the deploy is running
[21:51] <verterok> kwmonroe: same error: spark/0*  error     idle   0        10.50.84.52            hook failed: "install"
[21:54] <kwmonroe> 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.