=== scuttle`` is now known as scuttle|afk
=== thumper is now known as thumper-dogwalk
=== redir is now known as redir_afk
=== thumper-dogwalk is now known as thumper
=== benonsoftware is now known as Guest30663
=== \b is now known as benonsoftware
[08:20] <jamespage> gnuoy, https://review.openstack.org/#/c/319790/ if you please :-)
[09:02] <jamespage> gnuoy, beisner: we really need to start putting series in metadata
[09:02] <jamespage> means min version is 1.25.5 for folks not deploying via the charm store but I'm willing to faceup to that
[09:29] <leon324> hello!
[09:29] <leon324> I am having trouble here
[09:29] <neiljerram> Morning.
[09:29] <leon324> :)
[09:30] <neiljerram> With charms?
[09:30] <leon324> with juju installation
[09:30] <leon324> I have installed maas and I want to install juju on one node
[09:30] <neiljerram> Juju 1 or Juju 2?
[09:31] <leon324> 1.25
[09:31] <neiljerram> (By the way, I'm just another user - but I may be able to help.)
[09:31] <leon324> my server runs ubuntu 14
[09:31] <leon324> ok
[09:31] <leon324> i got this error always "but I always get his error "bootstrap instance started but did not change to Deployed state: instance""
[09:31] <neiljerram> OK, so what's the problem?
[09:31] <leon324> and I have found tons of references on google but I cannot find a solution
[09:32] <leon324> when i run "juju bootstrap"
[09:32] <leon324> I got failed deployment on maas
[09:32] <neiljerram> Right.
[09:32] <neiljerram> So that's probably a MAAS issue, not Juju.
[09:33] <leon324> no i dont think so
[09:33] <neiljerram> Can you use MAAS on its own to deploy Ubuntu Trusty onto one of your MAAS-managed nodes?
[09:33] <leon324> the nodes behave as they expect on other things
[09:33] <leon324> yes they are on ready state
[09:33] <leon324> its where they supposed to be
[09:34] <neiljerram> So if you go into the MAAS web UI, and deploy Ubuntu Trusty on one of the nodes, does that work?
[09:35] <leon324> i am not sure I understand you right
[09:36] <leon324> they have deployed Ubuntu Trusty because they have pass the commission state
[09:36] <neiljerram> Commission is not the same as deploy, I believe.
[09:36] <leon324> the nodes pxe boot found maas and have deployed on them ubuntu and now they are on ready state
[09:37] <neiljerram> 'Ready' means that MAAS knows about the hardware specs of the target node, but that there isn't any OS installed on it.
[09:37] <leon324> I think the nodes are ok I have done this before but I made a format and now I got stuck here ;/
[09:38] <leon324> yeah
[09:38] <neiljerram> When there is an OS installed, the state should be 'Deployed'
[09:38] <leon324> aaa
[09:38] <leon324> ok then
[09:39] <neiljerram> You need to click the Action button, select Deploy, select Ubuntu Trusty as the OS, then Go ... and see if that works.
[09:42] <neiljerram> jamespage, or other Juju experts, could I trouble you with some general questions, about charms for Trusty vs charms for Xenial...?
[09:42] <jamespage> neiljerram, hello
[09:42]  * jamespage reads backscroll
[09:43] <neiljerram> jamespage, no need for backscroll, this is a new question.
[09:43] <jamespage> oh ok
[09:43]  * jamespage stops reading 
[09:44] <neiljerram> Apart from the upstart to systemd transition, I believe there's not really any general reason for charms to differ between Trusty and Xenial - is that right?
[09:45] <neiljerram> And yet, (1) charm URLs explicitly encode the series, and (2) I think there are lots of charms that exist for Trusty that haven't yet been made available for Xenial.
[09:46] <neiljerram> So I wonder if I'm misunderstanding something.  It seems to be that it would be a better overall design for charms not to be series-specific by default.
[09:46] <leon324> where is this awesome Action button to install ubuntu on maas :D
[09:47] <neiljerram> leon324, if I remember correctly, it's at the top right of the page for a Node
[09:48] <neiljerram> *It seems to me ....
[09:49] <neiljerram> jamespage, Would appreciate your thoughts/comments on those trusty vs xenial points.
[09:50] <jamespage> neiljerram, you are quite right in that there is not a huge diff between trusty and xenial charms - all of the 26 core openstack charms support all series right back to 12.04 as well
[09:50] <jamespage> 1) yes charm URL's do encode series - however it is possible to embed the series supported by a charm in the metadata as of 1.25.5
[09:50] <jamespage> well 2.0 actually but 1.25.5 will not bork on them
[09:50] <jamespage> series:
[09:50] <jamespage>   - trusty
[09:50] <jamespage>   - xenial
[09:50] <jamespage> for example
[09:51] <jamespage> when a charm that declares this is published to the store using charm push/publish, the store will sort out all of the series oriented URL's for backwards compatibility with 1.25.5 etc..
[09:51] <neiljerram> Ah, nice.  And in the charm store, does the charm then get a series-independent URL?  Or does 'charm push' create two URLs, one for each series?
[09:52] <jamespage> 2) yes that's quite true - a number of charms are on trusty but not xenial as yet - its really up to the maintainers of the charms to sort that out
[09:52] <jamespage> neiljerram, I think the charmstore creates the URL's on the fly for different series, but there is also a series independent URL as well
[09:53] <jamespage> neiljerram, the openstack charms don't do the series in metadata just yet but will do soon
[09:53] <neiljerram> jamespage, Could you give me an example of a series-independent URL?
[09:55] <jamespage> neiljerram, https://jujucharms.com/u/james-page/aodh/9
[09:55] <neiljerram> jamespage, Thanks, this has been really helpful.
[09:56] <jamespage> neiljerram, np
[12:29] <magicaltrout> if you kid pulls the keys off your keyboard, you buy replacements, get them shipped from the US and they are the wrong type
[12:29] <magicaltrout> is it then acceptable just to throw the laptop in the bin and buy a new one?
[12:30] <stub> a new kid?
[12:31] <magicaltrout> lol
[12:31] <magicaltrout> both
[13:06] <jamespage> gnuoy, sparkiegeek does not like my changes to the unit tests on https://review.openstack.org/#/c/319790
[13:24] <jamespage> dosaboy, I still don't like the fact that rmq actively manages its /etc/hosts file with peer IP/host information, but it just saved my bacon fixing things up for Juju 2.0
[13:24] <lazyPower> jamespage - a lot of erlang/java apps need the hostname hacks :/
[13:25] <jamespage> lazyPower, indeed - but I don't think it unreasonable that Juju should provide a minimum viable environment for this type of thing
[13:25] <lazyPower> its unfortunate that we dont always get FQDN, resolveable hostnames, etc.  - seems like such an oversight on any given cloud, but its more prevalent than i care to admit.
[13:25] <jamespage> like the hostname of each unit should always be resolvable
[13:25] <lazyPower> right, there was talk about folding DNS into juju
[13:25] <jamespage> for example
[13:25] <jamespage> dosaboy, gnuoy: https://review.openstack.org/#/c/320450/
[13:25] <lazyPower> i would assume hostname would be part of that
[13:26] <jamespage> bdx, ^^ you'll need that one as well
[13:26] <jamespage> lazyPower, I really hope so
[13:26] <lazyPower> jamespage - ready for the real fun bits? GCE generates hostnames > 64 characters and tanks just about any java service thats not running a java-8 jre
[13:26] <lazyPower> \o/ yay
[13:26] <jamespage> lazyPower, lol
[13:26] <jamespage> lazyPower, wait - who's not running on java-8?
[13:27] <jamespage> ;)
[13:27] <jamespage> oh yeah - everyone...
[13:27] <lazyPower> anyone deploying java5-7?
[13:27] <lazyPower> which as you said, is everyone
[13:28] <stub> lazyPower, jamespage : I get the impression juju-core thinks /etc/hosts is the responsibility of cloud-init, and vice versa (Cassandra is bitten by this too, so add Java to the list)
[13:28] <jamespage> maybe I'll email list about this
[13:28] <jamespage> stub, point is that juju control's cloud-init right?
[13:28] <jamespage> stub, oh yeah the ol 127.0.1.1 java problem
[13:28] <jamespage> I remember that welll
[13:28] <tinwood> gnuoy, jamespage the new charms.openstack module is now (temporarily) at https://github.com/ajkavanagh/charms.openstack along with the barbican layered charm that uses it at: https://github.com/ajkavanagh/charm-barbican -- please take a look and see what you think when you get a moment?
[13:29] <stub> I would think juju, as it also needs to handle the ip address changing
[13:48] <gennadiy> hello everyone, time to time juju-gui is stuck and doesn't display new changes in env. some relation are missed some services too. how to restart it?
[13:51] <rick_h_> gennadiy: just reload the page
[13:51] <rick_h_> gennadiy: hatch or kadams54 might be able to help if it's more than that ^
[13:51] <hatch> Hello
[13:51] <hatch> gennadiy: hae you tried refreshing the page?
[13:52] <gennadiy> yes. i tried
[13:52] <gennadiy> can we restart process?
[13:52] <hatch> what version of Juju?
[13:52] <gennadiy> 2.0
[13:53] <hatch> hmm
[13:53] <gennadiy> also it doesn't display icons of local charms
[13:53] <hatch> that is a known issue
[13:54] <gennadiy> as i remember previously we have posibility to restart service
[13:54] <hatch> gennadiy: can you open the browser console to see if there are any errors? ctrl+shift+i and then refresh
[13:54] <hatch> gennadiy: also are you using the gui charm or the gui which ships with juju 2? `juju gui`
[13:54] <gennadiy> a lot of
[13:54] <gennadiy> charm
[13:55] <gennadiy> does juju 2 has own?
[13:55] <hatch> can you paste an example of what one of the errors are?
[13:55] <hatch> gennadiy: yes simply run `juju gui` from the CLI :)
[13:55] <gennadiy> combo?app/assets/javascripts/yui/datatype-date-format/datatype-date-format-min.js&app/views/utils-m…:40 Unknown delta type: actionInfodefaultHandler @ combo?app/assets/javascripts/yui/datatype-date-format/datatype-date-format-min.js&app/views/utils-m…:40(anonymous function) @ combo?app/assets/javascripts/yui/promise/promise-min.js&app/models/models-min.js&app/store/endpoint…:5onDelta @ combo?app/assets/javascripts/yui/promise/promise-min.js&app/models/
[13:55] <gennadiy> charms:1 GET https://user-admin:b9827e013d95a78059cb80be4c3471c1@10.9.8.246/juju-core/charms?url=local:trusty/ixia-load-module-1&file=icon.svg 500 (Internal Server Error)
[13:56] <gennadiy> seen the last - it's icon issue
[13:57] <hatch> ahh
[13:57] <hatch> hmm
[13:57] <hatch> gennadiy: can you try the version of the gui that ships with Juju? To see if it's working, I believe this might be a regression
[13:57] <hatch> I'm just investigating right now
[13:59] <hatch> gennadiy: I'm assuming that this issue happened after you either a) deployed a charm with an action or b) performed an action on an active service - can you confirm either of these?
[14:04] <gennadiy> i think we have charms with actions.
[14:05] <hatch> gennadiy: yeah, judging from that error message you do. :)
[14:06] <gennadiy> the same result with embedded juju gui
[14:06] <hatch> gennadiy: ok thanks, this is a regression and we'll have to get on working on a fix right away
[14:07] <hatch> gennadiy: would you be able to create an issue on our GitHub repository? https://github.com/juju/juju-gui/issues/new That way you will be notified as we work on it?
[14:07] <gennadiy> may i fix it locally?
[14:08] <gennadiy> i think i can edit js script on juju-gui server manually
[14:10] <hatch> gennadiy: I'm actually still investigating - are there any other console errors that aren't what you've already pasted?
[14:10] <gennadiy> no, only these
[14:15] <hatch> gennadiy: both of those errors should have been able to self-recover from so I'm looking for other places in which an issue may have been introduced
[14:15] <stub> marcoceppi: So how do I get from cs:~postgresql-charmers/postgresql to cs:postgresql now days?
[14:21] <marcoceppi> stub: it needs to be promulgated, which is a new process, is postgresql ready to be updated to this?
[14:21] <marcoceppi> stub: ie, does it upgrade cleanly, etc?
[14:22] <jamespage> gnuoy, revised - https://review.openstack.org/#/c/319790/2
[14:22] <jamespage> tinwood, looking
[14:24] <gnuoy> jamespage, happy to +2 post-smoketest
[14:24] <jamespage> gnuoy, okies
[14:25] <gnuoy> jamespage, well, Jenkins lint + unit is enough
[14:25] <jamespage> gnuoy, probably :-)
=== skay is now known as skay_
[14:29] <stub> marcoceppi: yes, this is the best version.
[14:30] <stub> marcoceppi: it has upgrade tests, is being used internally by several teams, and is what we are using to deploy production servers (the SSO uses this charm)
[14:31] <jamespage> tinwood, https://github.com/openstack-charmers/charms.openstack forked from your repository
[14:31] <marcoceppi> stub: cool, didn't doubt just wanted to double check
[14:31] <jamespage> tinwood, setup.py has some deadwood from whereever you copied it from :-)
[14:31] <marcoceppi> stub: so, going to pm
[14:32] <tinwood> thanks jamespage; re setup.py -- oh yes, so it does!  I'll fix that.
[14:32] <tinwood> That's one a wrote a while ago ...
[14:34] <jamespage> tinwood, https://github.com/openstack-charmers/charms.openstack/pull/1
[14:35] <jamespage> tinwood, I think that brings us inline with charms.reactive and oslo.*
[14:37] <tinwood> jamespage, yes, that looks right.  just to check my heads on right; that changes the import from 'import charms_openstack' -> 'import charms.openstack', or does it?
[14:37]  * tinwood is getting confused.
[14:38] <jamespage> tinwood, no pe
[14:38] <jamespage> nope rather
[14:38] <jamespage> tinwood, example: https://github.com/openstack/oslo.messaging
[14:38] <jamespage> import oslo_messaging
[14:38] <jamespage> module name is oslo.messaging
[14:40] <tinwood> jamespage, so the change only alters the name in pypi, and setup, pip, etc.
[14:40] <jamespage> tinwood, yes that's correct
[14:40] <tinwood> confusing as hell.  It explains why I've always kept them the same in the past.
[14:43] <sg> Hi, Can any one please tell me when config.changed.<option> of basic layer will be set true? because i'm not setting any config option using 'juju set' command but also this state is set as true and triggering the decorated function.
[14:44] <tinwood> jamespage, https://github.com/openstack-charmers/charms.openstack/pull/2 touché :)
[14:47] <sg> I have given some default values in config.yaml and i'm not changing that value using 'juju set' command
[14:59] <gennadiy> one more issue with juju - if it can't create machine it will not allow to remove service at all. i deployed service with wrong constraints value and now i can't delete it. " cannot assign unit "sipp/0" to machine: cannot assign unit "sipp/0" to new machine or container: cannot assign unit "sipp/0" to new machine: invalid constraint value: instance-type=m3.medium valid values are: [m1.tiny m1.small m1.medium m1.large m1.xlarge m1.t_tiny m1.t_small m1.demo]"
[15:02] <lazyPower> gennadiy : juju remove-machine --force  is an option
[15:02] <gennadiy> machine is removed
[15:02] <lazyPower> and with no "machines" backing a service it should be trivial to juju destroy-service foo
[15:04] <sg> when config.changed.<option> reactive state of basic layer will be set true? because I'm changing any of the default config values using 'juju set' command but also this state is set as true and triggering decorated function.
[15:05] <lazyPower> sg - i believe that state will be true on the first-run of the charm. I may be incorrect.  The backing code managing those states can be found here: https://github.com/juju-solutions/layer-basic/blob/master/lib/charms/layer/basic.py#L126
[15:05] <sg> I'm not understanding when exactly config.changed.<option> state will set as true
[15:08] <lazyPower> sg - so it appears to me that on first execution, those states will trigger true, then if the value is != '', it will toggle the .set state, and if the value has changed from a prior context run, it toggles the .changed state
[15:11] <cory_fu> sg: lazyPower is correct.  config.changed.<option> is always set during the first hook execution and thereafter only if the option changes from the previous value.  config.set.<option> is set as long as the value is non-empty and not false, even if that non-empty or true value is the default value.
[15:13] <lazyPower> cory_fu - why/how does this work? https://github.com/juju-solutions/layer-basic/blob/master/lib/charms/layer/basic.py#L144 it seems to me that it should be guarded by an if statement checking if the value is none/empty and if its already doing that, its not-obvious
[15:15] <cory_fu> lazyPower: config.get(opt) will return None if the value doesn't exist, or the value otherwise.  The value is then treated as a bool and if "truthy", the state will be set, otherwise it will be removed
[15:15] <lazyPower> ah ok
=== Oer is now known as OerHeks
[15:15] <lazyPower> i figured there was some magic going on there
[15:15] <cory_fu> bool(None) is False, bool('') is False, bool(False) is False obviously
[15:15] <cory_fu> bool(0) is False
[15:15] <lazyPower> so the toggle is a bit of a misnomer as its toggle_if_true()
[15:16] <cory_fu> Everything else is True
[15:16] <lazyPower> s/misnomer/potentially-misleading-me-because-i-dont-know-better/
[15:16] <cory_fu> If you leave off the second arg, then it does a toggle.
[15:16] <lazyPower> yeah
[15:16] <lazyPower> ok, cool!
[15:16] <lazyPower> the more you know
[15:17] <cory_fu> lazyPower: Actually, that's wrong.  The second arg to toggle_state is actually required
[15:18] <sg> cory_fu, Then if we provide default value for config.option and if we chnage that default value using 'juju set' command then only config.set.<option> state will be true right?
[15:20] <cory_fu> sg: config.changed.<option> will be set for a single hook execution, just after it's changed.  config.set.<option> will be set indefinitely, just as long as the value is True-ish
[15:21] <cory_fu> But if the default is True, and you change it to False, then config.set.<option> will *not* be set
[15:21] <cory_fu> I considered adding a config.default.<option> that would just tell you if it's non-default
[15:21] <lazyPower> blahdeblah   ^
[15:21] <cory_fu> Would that be useful?
[15:21] <lazyPower> blahdeblah - you'll want the last 15 minutes of scrollback, as this is directly proportional to your discovery the other night
[15:22] <cory_fu> lazyPower: proportional?
[15:22] <lazyPower> yeah, we were riffing over these states on sunday evening
[15:22] <lazyPower> i was 80% right
[15:22] <lazyPower> that last 20% though... i'd rather correct my oversights with evidence of the truth than leave it incorrect.
[15:22] <cory_fu> lazyPower: http://www.prdaily.com/Uploads/Public/i-do-not-think-it-means-what-you-think-it-means.jpg
[15:22] <cory_fu> ;)
[15:22] <tvansteenburgh> lol, knew that was coming
[15:23] <lazyPower> > corresponding in size or amount to something else. - mirriam webster tells me it means what i thought it meant
[15:23] <cory_fu> tvansteenburgh knows me so well.
[15:25] <sg> ok cory_fu, If I want to check the value other than default value I should use config.default.<option> state right?
[15:26] <cory_fu> Oh hey, that state is already there, even.  sg: Yes, it sounds like you want the config.default.<option> state
[15:30] <sg> I'm bit confused of these config states.
[15:30] <sg> cory_fu: yes, I want the function to trigger when default value changed to some other value and even that value changes.
[15:31] <jcastro> lazyPower: anyword on those fixes for that bundle for kibana?
[15:31] <lazyPower> jcastro - ah charms have been revv'd, cory_fu  revv'd the bundle yesterday i do believe
[15:31] <lazyPower> wrt the big d bundle
[15:32] <lazyPower> i still need ot rev the beats-core bundle, as i space that off until you just drew my attention to it
[15:34] <cory_fu> sg: So, config.default.<option> will be set as long as the value is the default value.  You can use @when_not('config.default.<option>') to trigger when the value is something other than the default.  But be aware that the state will be set / removed for *every* hook based on the value.  If you only want to trigger a handler once and only when the value is non-default, you can use something like this: http://pastebin.ubuntu.com/16657316/
[15:35] <cory_fu> lazyPower: I rev'ed the big data bundle, but not the belk stack bundle
[15:35] <cory_fu> jcastro: https://jujucharms.com/apache-processing-spark/ is up to date
[15:37] <cory_fu> kwmonroe: I updated the apache-bigtop-base PR with the corrected patch
[15:38] <kwmonroe> ack cory_fu - gracias
[15:43] <sg> ok thanks cory_fu and lazypower.
[15:44] <lazyPower> cory_fu https://github.com/juju-solutions/bundle-beats-core/pull/1
[15:45] <cory_fu> lazyPower: No pretty picture?  :(
[15:45] <lazyPower> oo 1 sec
[15:45] <lazyPower> i forgot all about that
[15:45] <cory_fu> :)
[15:45] <cory_fu> It actually can be useful, because it can catch a charm rev that doesn't exist (though not an out-of-date charm rev, unfortunately)
[15:46] <cory_fu> Plus it looks really neat.  :p
[15:46] <lazyPower> cory_fu - refresh the comments and *bam*
[15:47] <cory_fu> Hrm.  Your circles overlap
[15:47] <cory_fu> Is that intentional?
[15:47] <lazyPower> are you nit picking the svg?
[15:47] <lazyPower> really?
[15:47] <lazyPower> hang on i'll add anotehr 50 px to the annotations
[15:48] <cory_fu> This is how your bundle will look in the store.  Don't you want it to look nice?
[15:48] <lazyPower> I'm the reason we cant have nice things
[15:49] <cory_fu> :)
[15:49] <lazyPower> cory_fu give it another whirl?
[15:50] <cory_fu> Looks really nice
[15:50] <cory_fu> +1
[15:50] <lazyPower> ta
[15:50] <DavidRama> hello, is it possible to use juju + lxd with a bridge that is directly connected to my local lan (ie no private LAN + NAT) ?
[16:00] <cory_fu> DavidRama: I'm afraid I don't really know anything about lxd bridging.  Can you perhaps explain more about your use-case?
=== redir_afk is now known as redir
[16:38] <jamespage> gnuoy, thedac: could either of you take a look at https://review.openstack.org/#/q/topic:bug/1572575
[16:38] <mup> Bug #1572575: Charm looks for JUJU_ENV_UUID but that does not exist in juju 2 models <bug-squad> <canonical-bootstack> <juju-2.0-api> <landscape-client-charm:Triaged> <landscape-client (Juju Charms Collection):Triaged> <swift-proxy (Juju Charms Collection):Fix Committed by james-page>
[16:38] <mup> <swift-storage (Juju Charms Collection):Fix Committed by james-page> <https://launchpad.net/bugs/1572575>
[16:38] <jamespage> (the open ones)
[16:39] <thedac> jamespage: will do
[16:39] <jamespage> they both pass smoke and I don't really think a full recheck is worth the CPU time
[16:44] <thedac> jamespage: done
[16:45] <jamespage> thedac, ta
=== bruno is now known as Guest6887
[17:24] <stokachu> so im trying to update my dokuwiki layer and running into this issue: https://paste.ubuntu.com/16660726/
[17:25] <stokachu> using charm-tools 2.1.2
[17:25] <stokachu> do i still have to export all the LAYER_PATHS etc?
[17:26] <stokachu> lazyPower: ^?
[17:27] <lazyPower> stokachu - right, if your trying to build with a layer that doesn't exist in the registry, you'll need to ensure you have $LAYER_PATH and $INTERFACE_PATH set
[17:27] <stokachu> lazyPower: ok
[17:28] <stokachu> lazyPower: so i set them all and still same error
[17:29] <stokachu> heres the latest https://paste.ubuntu.com/16660929/
[17:31] <lazyPower> stokachu - looks like thats bubbling up from the installer tactic, aka pip install directives/ package install directives
[17:31] <lazyPower> link / paste to your layer.yaml?
[17:32] <stokachu> https://github.com/battlemidget/juju-charm-dokuwiki/blob/master/layer.yaml
[17:32] <stokachu> in the process of upgrading this layer
[17:32] <stokachu> well charm i mean
[17:32] <lazyPower> weird, none of the layers define extra packages than i can see
[17:33] <lazyPower> stokachu - i'm not certain, can you file a bug against charm-tools?
[17:33] <stokachu> sure
[18:08] <cory_fu> kjackal: You asked if we would have a bundle that included both Spark and Hadoop, in particular for the Bigtop charms.  I think we will; it'll probably be something like the current realtime-syslog-analytics bundle, though I think we were thinking about renaming that (kwmonroe?)
[18:11] <cory_fu> kwmonroe: Also, I assume we want to rename the apache-bigtop-spark charm to bigtop-spark to match the Hadoop charms?
[18:15] <kwmonroe> yeah cory_fu kjackal, for the spark bundle, we should consider whether we want spark workers or nodemangers.  i'm assuming workers with no yarn at all.. so maybe 'spark-processing-hdfs' for a reference bundle, or something that more closes matches whatever it is that bundle does.
[18:16] <cory_fu> Wouldn't something like bigtop-processing-spark-hdfs better match our current convention?
[18:16] <kwmonroe> our current convention is hadoop-processing
[18:16] <kwmonroe> http://jujucharms.com/hadoop-processing
[18:17] <cory_fu> Oh, right
[18:19] <kwmonroe> how about engine-pillar[-storage] where engine: {hadoop, spark, flink}, pillar: {ingestion, processing, visualization}, storage: {None (implied), cassandra, s3, etc}
[18:20] <kwmonroe> my shed is too red for this right now.  mull on it, we can vote later.
[18:20] <cory_fu> :)
[18:24] <hatch> how do I deploy a namespaced bundle from the CLI?
[18:26] <kwmonroe> hatch: pretty sure it's juju deploy cs:~<user>/bundle/<name>
[18:26] <hatch> ahhh
[18:26] <hatch> didn't try that format
[18:26] <hatch> that was the one
[18:26] <kwmonroe> cool
[18:26] <hatch> tried all the others I guess
[18:26] <hatch> haha
[18:27] <hatch> thanks!
[18:27] <kwmonroe> np
[18:45] <kwmonroe> cory_fu: new bigtoppers looking good with that updated patch.  lots of "2.6 GB of 2.1 GB virtual memory used", but not cry babies.
[18:51] <cory_fu> kwmonroe: Nice.
[18:54] <kwmonroe> cory_fu: todos are then to merge the base layer, build/push/publish the charms, update bundle with revnos, build/push/publish the bundle, and then fixup PR 108?
[18:55] <cory_fu> Sounds  right
[19:00] <kwmonroe> cory_fu: https://github.com/juju-solutions/layer-apache-bigtop-base/pull/10
[19:01] <cory_fu> You want me to click Merge?  :)
[19:02] <cory_fu> Done
[19:06] <cory_fu> kwmonroe: Oh, I need to create a JIRA for that patch, too
[19:07] <kwmonroe> yeah cory_fu, and you may want to split the patch.. one for datanode ip reg and one for nodemgr vmem.  up2you if you think they'll enforce a 1-fix-per-jira policy.
[19:08] <cory_fu> I think it would be good to split them
[19:08] <kwmonroe> i think it would be good for you to split them as well
[19:09] <cory_fu> kwmonroe: Can you walk me through how you created the patch JIRA?
[19:09] <kwmonroe> of course cory_fu!  it's your birthday
[19:09] <cory_fu> :)
[19:09] <kwmonroe> dbd HO?
[19:10] <cory_fu> Yeah man
[19:18] <jcastro> lazyPower: http://paste.ubuntu.com/16663827/
[19:18] <jcastro> so pretty
[19:18] <lazyPower> Yeahhhh buddy
[19:18] <lazyPower> That looks great. awesome work cory_fu and team
[19:19] <lazyPower> jcastro - and thats deployed on the lxd provider right?
[19:20] <jcastro> yeah
[19:20] <jcastro> I did a pagerank action on spark, 10.6 seconds is my score
[19:22] <lazyPower> not bad brobama
[19:23] <jamespage> thedac, if you have a moment - https://review.openstack.org/#/c/319779/
[20:04] <thedac> jamespage: I'll take look
[20:42] <mpjetta> anyone know if the openstack-charmers hang out somewhere on irc?
[20:42] <jcastro> in here
[20:42] <mpjetta> ahh ok, thanks
[20:42] <jcastro> though a few are on holiday, so the list might get you a faster response, depends
[20:42] <mpjetta> ty
[20:45] <magicaltrout> and time of day, more seem to be around earlier
[20:48] <magicaltrout> marcoceppi: when i messed up my lp username a while ago you said I could create an organisation and push charms to that, was that correct?
[20:48] <magicaltrout> or jcastro or someone who might know
[20:49] <jcastro> you should be able to yeah
[20:49] <jcastro> charms can live anywhere now
[20:50] <magicaltrout> yeah but charm publish will still need a namespace in LP somewhere even if they live in github or somewhere, I believe?
[20:52] <mpjetta> I’ve been trying to get https://jujucharms.com/u/openstack-charmers-next/openstack-base-xenial-mitaka/bundle/4 working for a few days now. I can bootstrap juju and get the openstack services UP and talking to eachother. However, I can’t seem to properly create the internal and ext_net networks. I see from the description of the charm that the ext_net should be on the maas’ nodes’ eth1 interface but don’t see the mappings or config to actually
[20:52] <mpjetta> that network on the NIC
[20:55] <lazyPower> magicaltrout - only if you wish your charms to be owned by a group in launchpad, vs your personal namespace
[20:55] <magicaltrout> yeah lazyPower thats pretty much the idea
[20:55] <lazyPower> oh i just read the supporting lines to that question/statement
[20:55] <lazyPower> yeah you're on point.
[20:55] <magicaltrout> that said i can't find how to create an org
[20:55] <magicaltrout> even google fails me :(
[20:55] <lazyPower> 1 sec i'll send you a link
[20:56] <lazyPower> magicaltrout https://launchpad.net/people/+newteam
[20:56] <magicaltrout> ta
[20:57] <lazyPower> np, its hidden on "http://launchpad.net" as "register a new team"
[20:57] <lazyPower> just fyi if you need to do this in the future
[20:58] <magicaltrout> thanks
[20:59] <magicaltrout> I need to start pushing some Apache stuff, so I wanted an org/team as a holder that was outside of my namespace to try and make it more inclusive
[20:59] <lazyPower> makes sense
[20:59] <magicaltrout> so we now have /apachefoundation for some charms we're working on
[21:25] <petevg> cory_fu, kjackal, kwmonroe: I'm thinking of adding a README.md to layer-apache-bigtop-base, noting that the layer will run Bigtop.install for you, and then you want to run Bigtop.render_site_yaml and Bigtop.trigger_puppet explicitly in your own layer, to make it do its magic.
[21:25] <petevg> Do we have any docs that I can base the rest of the README off of?
[21:26] <petevg> Or should I just drop in my current understanding, based on the code that I've read today, and push it for review so y'all can tell me all of the things that I got wrong?
[21:26] <magicaltrout> from an outsiders point of view, this is one of the better readmes https://github.com/juju-solutions/layer-hadoop-client/blob/master/README.md
[21:27] <petevg> magicaltrout: Cool. I will give that a read-through, and steal its good ideas :-)
[21:27] <cory_fu> +1 to magicaltrout's suggestion.
[21:33] <magicaltrout> lazyPower: charm push . cs:~apachefoundation/trusty/joshua-full
[21:34] <magicaltrout> ERROR cannot post archive: unauthorized: access denied for user
[21:34] <magicaltrout> got any clue?
[21:34] <magicaltrout> works when i push to my local namespace
[21:36] <magicaltrout> oh hold on
[21:36] <magicaltrout> good old google and aisrael https://github.com/juju/docs/issues/993
[21:37] <magicaltrout> hmm no difference
[21:38] <lazyPower> jrwren halp
[21:39] <lazyPower> oh wait
[21:39] <lazyPower> magicaltrout - try doing a charm whoami to refresh your groups and try again
[21:39] <lazyPower> i dont know why this would work, but stranger things have happened
[21:39] <lazyPower> mainly i want to verify you have apachefoundation in your user groups
[21:39] <magicaltrout> yeah doesn't make a difference https://github.com/juju/charmstore-client/issues/33 i've landed here
[21:39] <magicaltrout> so I'll dig up an update if there is one
[21:40] <magicaltrout> see if it makes a difference
[21:40] <cory_fu> aisrael: I'm not sure that issue is valid.  We have no trouble pushing to ~bigdata-charmers which is restricted
[21:40] <lazyPower> magicaltrout - that says log out / log in and it should be fixed
[21:40] <lazyPower> its due to SSO handing over the membership details, and it didnt exist at the time of initial login
[21:41] <magicaltrout> yeah its a lie
[21:41] <magicaltrout> logout does nowt
[21:41] <lazyPower> crap :/
[21:41] <lazyPower> herrings of redness abound
[21:41] <magicaltrout> hehe
[21:41] <magicaltrout> how does one go about upgrading charm tools
[21:41]  * magicaltrout heads over to his favourite search engine
[21:41] <magicaltrout> there's ppa's and stuff for this now, right?
[21:41] <lazyPower> i was told never to reveal teh secrets
[21:42] <lazyPower> everyone and anyone should be installing from archive per marcoceppi
[21:42] <magicaltrout> last time i did any major juju installation it was from trunk, but i'm on a fresh-ish xenial install and just apt-got it ages ago
[21:42] <lazyPower> but between you and i, if you fire up a virtualenv, you can rev charm-tools in that venv safely without polluting your environ.
[21:43] <lazyPower> you'll have to pip install ./ from the charm-tools tree... but we dont recommend that *notice*
[21:45] <magicaltrout> hmm
[21:46] <magicaltrout> well marcoceppi says in that gh issue that 2.1.2 has the fixes and james can see the group
[21:46] <magicaltrout> so something else is messed up as well
[21:46] <magicaltrout> where does charm tools cache its login and stuff?
[21:46] <magicaltrout> can I flush it?
[21:46] <lazyPower> i think thats in .go-cookies
[21:46] <lazyPower> its using a token-based auth mechanism
[21:46] <magicaltrout> oh hold on, there's a major/major logout
[21:46] <magicaltrout> not just a charm logout
[21:49] <magicaltrout> bleh I've logged out of everything and i'm still not in my own group
[21:49] <magicaltrout> even though i'm an owner
[22:02] <magicaltrout> okay, so here's another angle
[22:02] <magicaltrout> as a lowly user
[22:02] <magicaltrout> if I login to the jujucharmstore.com
[22:02] <magicaltrout> should it work?
[22:02] <magicaltrout> jrwren says in that ticket that charm tools gets the groups from the charm store
[22:03] <magicaltrout> "Sorry for the inconvenience, please pop back soon."
[22:15] <arosales> magicaltrout: what charm tool version are you on?
[22:15] <magicaltrout> arosales:
[22:15] <magicaltrout> bugg@tomsdevbox:~/charms/trusty/joshua-full$ charm version
[22:15] <magicaltrout> charm 2.1.1-0ubuntu1
[22:15] <magicaltrout> charm-tools 2.1.2
[22:15] <magicaltrout> latest afaik
[22:16] <arosales> yup, that looks like the latest and what I have on my machine
[22:16] <arosales> magicaltrout: and reading the backscroll sounds like you can't put to a group
[22:16] <arosales> s/put/push/
[22:17] <magicaltrout> yeah, but I also can't login to jujucharms.com (I don't know if users are supposed to or not)
[22:17] <magicaltrout> so I'm wondering if they are related
[22:17] <arosales> magicaltrout: you should be able to login to jujucharms.com
[22:17] <magicaltrout> oh in that case my account is screwed up somewhere
[22:18] <arosales> its via openid
[22:18] <magicaltrout> yeah, i changed my id
[22:18] <magicaltrout> i suspect jujucharms.com can't cope
[22:18] <magicaltrout> woop
[22:18] <arosales> magicaltrout: so https://jujucharms.com/login/ does not work for you?
[22:19] <magicaltrout> no it tells me to pop back soon
[22:19] <arosales> :-/
[22:19] <magicaltrout> the USSO login works
[22:19] <magicaltrout> is post auth
[22:19] <arosales> https://help.launchpad.net/YourAccount/OpenID?action=show&redirect=OpenID
[22:19] <magicaltrout> so I guess charm tools can't grep my groups because it will also get redirected under the hood
[22:19] <arosales> under "Can I change my OpenID"
[22:20] <arosales> magicaltrout: did you change our lp id recently?
[22:20] <magicaltrout> months ago
[22:20] <magicaltrout> probably 6
[22:20] <arosales> hmm well that should have only affected sites you were already logged into
[22:21] <magicaltrout> but i've only ever pushed stuff to my namespace and never logged into jujucharms.com
[22:21] <arosales> and sounds like you have tried to log in/out a couple of times
[22:22] <magicaltrout> yeah 2 different browsers, 2 servers with charm tools installed
[22:22] <magicaltrout> same result
[22:22] <arosales> given jujucharms.com/login does not work for you it feels like an OpenID issue
[22:23] <magicaltrout> well openid works on LP
[22:23] <magicaltrout> so I know it works in some domains
[22:23] <arosales> good data point
[22:25] <magicaltrout> actually arosales, full disclosure, a while ago some devs' hacked my account around on jujucharms.com because of my LP name change, so it may be that whilst the oauth stuff works on the push side to my namespace, its finding multiple users with the same ID or something
[22:26] <arosales> magicaltrout: possibly
[22:26] <arosales> magicaltrout: lets open an issue to track this
[22:26] <arosales> magicaltrout: can you collect the error you see when pushing
[22:26] <arosales> along with charm whoami
[22:26] <magicaltrout> sure, where do you want me to file it?
[22:27] <arosales> @ https://github.com/juju/charm-tools/issues
[22:27] <magicaltrout> ta
[22:28] <arosales> magicaltrout: if you add me to a ~apachefoundation I can try to replicate the problem
[22:28] <arosales> but I am guessing its on the auth/SSO side
[22:28] <arosales> magicaltrout: also be sure to mention you have done charm login/logout
[22:28] <arosales> and jujucharms.com/login also fails for you
[22:28] <magicaltrout> yup
[22:29] <magicaltrout> added, i'm sure you'll have more success than me
[22:29] <arosales> magicaltrout: and we should also ping in #canonical-sysadmin and see if they have any insights
[22:29] <arosales> magicaltrout: https://launchpad.net/~arosales528 isn't me
[22:29] <magicaltrout> oh well
[22:30] <magicaltrout> i shall remove that imposter
[22:30] <arosales> but https://launchpad.net/~arosales is  :-)
[22:30] <magicaltrout> how dare someone share a similar name
[22:30] <arosales> I know, right
[22:33] <magicaltrout> alright i submitted #211
[22:37] <arosales> magicaltrout: interesting whoami doesn't show apachefoundation for me atm
[22:37] <arosales> I wonder if I push  . . .
[22:38] <arosales> what to push though
[22:45] <arosales> magicaltrout: interesting . . .
[22:45] <arosales> $  charm push . cs:~apachefoundation/trusty/apache-boilerplate
[22:45] <arosales> ERROR cannot post archive: unauthorized: access denied for user "arosales"
[22:46] <magicaltrout> hmm
[22:46] <magicaltrout> and whoami doesn't show you in it?
[22:46]  * arosales will try login/logout since it was a new addition to the team
[22:46] <arosales> magicaltrout: correct whoami hasn't shown me to be in apachefoundation group yet
[22:49] <arosales> magicaltrout: still no luck on my side with pushing to that group, or seeing it my list of groups via whoami
[22:49] <magicaltrout> weird
[22:49] <arosales> magicaltrout: I don't see it in your whoami either
[22:49] <magicaltrout> nope
[22:50] <magicaltrout> all in all, i think i can safely say its not working :)
[22:50] <arosales> alas, yes :-/
[22:52] <magicaltrout> oh well, i'll leave the ticket lurking and see what someone says
[22:52] <magicaltrout> thanks for validating it though arosales
[22:53] <magicaltrout> its a bad day when a canonical employee can't do something on LP ;)
[22:54] <arosales> magicaltrout: I created https://launchpad.net/~ai-charmers
[22:55] <arosales> and I don't see that in my group list
[22:55] <arosales> so this may be an issue of groups being updated.
[22:55] <arosales> I'll update the issue with this
[22:55] <magicaltrout> ta
[22:55] <arosales> but its a good day when I see stuff like "cs:~apachefoundation/trusty/joshua-full" :-)
[22:56] <arosales> just super  frustrating you can't share it :-(
[22:57] <magicaltrout> hehe, well its no big rush, its not completely done, but i did want to push it to a development branch so I could demonstrate it to the guys on the project. That said, there's no huge rush, so I'll just sit it out.
[22:59] <magicaltrout> I'm suppoesd to be talking to Alejandra at the end of the week about the apache page as well
[22:59] <magicaltrout> which is good
[23:04] <arosales> magicaltrout: sorry about the issue, I did add a comment to https://github.com/juju/charm-tools/issues/211
[23:04] <magicaltrout> yeah its no problem arosales thanks for looking into it
[23:05] <arosales> magicaltrout: ya ale mentioned that today, be great to get a nice landing page for apache projects
[23:08] <magicaltrout> i'll file a ticket on GH jujucharms.com about my login as, even if the group suddenly appears, I should be able to login to the website
[23:08] <arosales> magicaltrout: correct, I didn't see that issue
[23:08] <arosales> I am able to login to jujucharms.com
[23:09] <magicaltrout> yeah, i'm sure that must be LP nameswitch/devs hacking the database for me/ related
[23:10] <arosales> but mainly we need to get folks to easily create an lp team and then start pushing to it
[23:11] <arosales> magicaltrout: we should see a reply on the list when folks in the UK come back online during normal business hours
[23:11] <arosales> not magicaltrout 24 hours :-)
[23:13] <magicaltrout> bleh. And on that note, I'm off for at least 5 hours :P
[23:14] <magicaltrout> thanks again arosales
[23:20] <arosales> good night magicaltrout