[00:20] <aisrael> Any recent packaging change with Juju 2 in xenial? I just updated to beta 15 and now the (symlink?) from /usr/bin/juju to /usr/bin/juju-2.0 is gone
[00:23] <marcoceppi> aisrael: yeah, that's been gone for a while
[00:24] <marcoceppi> aisrael: you can do the following to add it back
[00:24] <marcoceppi> aisrael: it's actually juju1 that breaks it up
[00:24] <marcoceppi> sudo update-alternatives --install /usr/bin/juju juju /usr/bin/juju-2.0 30
[00:25] <marcoceppi> then sudo update-alternatives --config juju
[00:27] <marcoceppi> aisrael: ^^
[00:29] <aisrael> marcoceppi: Huh. I remember when juju-1 was changed. I thought I'd installed this vm after that, though
[00:36] <marcoceppi> aisrael: 1.25.6 was released
[00:36] <marcoceppi> which reset that, probably
[00:36] <aisrael> Aha, that'd be the culprit!
[01:07] <aisrael> marcoceppi: when you have a chance, could you kill any instances owned by aisrael? Seems I've hit my quota
[01:08] <marcoceppi> aisrael: ehhhhh, it's not easy to find instances by you
[01:08] <marcoceppi> aisrael: what region
[01:08] <aisrael> oh. us-east-1. That's the issue, isn't it?
[01:08] <marcoceppi> aisrael: not nessisarily
[01:09]  * marcoceppi helps
[01:09] <marcoceppi> aisrael: seems there's a 20 instance cap on us-east-1
[01:09] <marcoceppi> which is not right
[01:10]  * marcoceppi contacts amazon _again_
[01:10] <aisrael> marcoceppi: Weird. us-west-2 is working, fwiw
[01:10] <marcoceppi> yeah
[01:10]  * marcoceppi frees up more resources
[01:11] <marcoceppi> I may have to start actualy reaping
[01:11] <marcoceppi> lots of activity, which is awesome
[01:12] <aisrael> Yeah, that's a good problem to have
[01:15] <marcoceppi> us-east-1 might be boned, everything there is legit, us-west-2 seems to have way more capacitt, despite having a butt load of instances running
[01:17] <aisrael> is it a hard resource cap set by amazon?
[01:18] <marcoceppi> yeah, it's typicall 20 instances per region
[01:18] <marcoceppi> I've contacted them like 12 times about increasing
[01:18] <marcoceppi> us-west-2 got an increase
[01:18] <marcoceppi> but none else did for whatever reason
[01:37] <aisrael> This is working well enough for my mini charm school, so I'm off for the night. Have a good one!
[02:46] <thumper> marcoceppi: still hanging around?
[02:46] <thumper> or lazyPower
[02:46] <marcoceppi> thumper: I am
[02:46] <thumper> sweet
[02:46] <thumper> for the python library that (most) charms use
[02:46] <thumper> when you call hook tools
[02:47] <thumper> are you explicit about format?
[02:47] <thumper> and if so, which?
[02:47] <marcoceppi> yes, json
[02:47] <thumper> awesome
[02:47] <thumper> I'm just about to land a change that changes the default from smart to yaml, and remove smart
[02:47] <thumper> which will make zero difference if you say "json"
[02:48] <thumper> existing behaviour will be kept if you use the feature flag "smart-formatters"
[02:48] <thumper> but I'm thinking most charms use the charm tools code
[02:48] <marcoceppi> thumper: http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/core/hookenv.py#L330
[02:48] <marcoceppi> thumper: odds are there will be like 2 charms this affect
[02:49] <marcoceppi> thumper: and those charms have bigger problems
[02:49] <thumper> :)
[07:41] <kjackal> Hello Juju World!
=== frankban|afk is now known as frankban
[12:27] <jcastro> magicaltrout: around today?
[13:43] <Anita_> Hi Matt
[13:43] <mbruzek> Hello
[13:44] <Anita_> This is regarding IBM-WXS design doc
[13:44] <Anita_> Did you get a chance to go through the mail?
[13:44] <mbruzek> Not yet this morning I just got in.
[13:44] <mbruzek> Let me read it
[13:44] <Anita_> Ok
[13:47] <mbruzek> Anita_: OK I am up to speed.
[13:47] <mbruzek> Anita_: What is your question?
[13:48] <Anita_> The third charm of ibm-wxs i.e ibm-wxs-client can be deployed in two topologies
[13:49] <Anita_> one is standard and another is mixed. In case of standard topology, ibm-wxs-client is a standalone/normal charm. in case of mixed topology, ibm-wxs-client is subordinate charm
[13:50] <Anita_> in the metadata. yaml, subordinate charm will be having either true or false.
[13:51] <Anita_> So thought of splitting ibm-wxs-charm as two charm. for standard : ibm-wxs-client ( not a subordinate one) and for Mixed topology charm ibm-wxs-was-client
[13:52] <Anita_> ibm-wxs-was-client is a subordinate charm.
[13:52] <Anita_> Is this approach correct?
[13:58] <mbruzek> Anita_: You would have to name the subordinate charm something different than the "regular" charm. At that point you will have a different layer for the two, but what you are telling me is the IBM WXS application software would be the same between those two charms?
[14:00] <Anita_> In both topologies, wxs client charm function is same. In case of standard, wxs-client can be used through command-line. Where as in case of Mixed, users are allowed to use Websphere Console UI to use wxs-client
[14:01] <Anita_> IBM WXS Software packages are different for different topologies
[14:01] <mbruzek> Anita_: What is the reason that the charm needs to be a subordinate in the first place? does the WXS software need to run on the WAS server? Or are there simply configuration differences between the two scenarios?
[14:02] <mbruzek> Anita_: OK I see you answered my quest in the previous statement
[14:03] <Anita_> In case of sub-ordinate charm, WAS ND will deployed. The installation path will be exposed by WAS ND. Under the same installation path, WXS Client needs to be installed
[14:05] <mbruzek> Anita_: The approach you have outlined seems OK then. It seems like more work for you (the author) to have 2 charms and potentially more confusing for the user to know which ibm-wxs charm they want to deploy and how to correctly relate them in the situation they want.
[14:06] <mbruzek> Anita_: The README for each charm would have to describe the situation where this charm would be used, and how it is different than the closely related one.
[14:06] <Anita_> is there any other method to specify in the metadata.yaml to have both subordinate and non-subordinate charm, depending on user's topology option?
[14:07] <mbruzek> Anita_: No not that I know of.  I brainstormed about this a little bit after reading your email. I came up with 2 possible options.
[14:08] <Anita_> can you please let us know?
[14:09] <mbruzek> Option 1) You make the charm a subordinate only, and relate it to ibm-was-nd (code would have to detect if nd was installed and install appropriately), and in the case where it is client only relate the subordinate to a ubuntu charm, which is the most simple non-subordinate charm.
[14:11] <mbruzek> Option 2) Re-evaluate the requirement of subordinate. Make the ibm-wxs-client a non-subordinate and see if you can pass all the software/information over relations, so the ibm-wxs-client -> ibm-was-nd does everything it needs to the ibm-was-nd charm, with the absence of the relation it simply sets up as a stand alone line.
[14:13] <mbruzek> Anita_: However if the path is clearer to make a subordinate and non-subordinate charm that is also a valid option. But the README on both charms would have to be very clear about what situation to use the different charms.
[14:15] <Anita_> In case of both options, user's options are to be taken?
[14:16] <mbruzek> Anita_: I don't understand the question. Can you rephrase?
[14:19] <Anita_> Option 1) I understood, But Option 2) I could not get. In case of Option 2) - If its a non-subordinate charm and user selects "Standard Topology", it will be normal charm. But if user selects Mixed Topology, ibm-was-nd will pass the informations to ibm-wxs-client and then ibm-wxs-client will proceed?
[14:19] <Anita_> But in case of Mixed topology, ibm-wxs-client needs was-nd to be installed on the same machine.
[14:24] <mbruzek> Anita_: Right. In the case of Option 2) the ibm-wxs-client would not be a subordinate and you transfer the software to the ibm-was-nd server. It *can* be done but may be very complicated
[14:26] <Anita_> Hmm Option 1 will be a better Option.
[14:27] <Anita_> In case of Option 1 I have a query.
[14:30] <Anita_> Option 1- subordinate charm. If user selects standard topology, then user will be having a simple ubuntu charm and add-relation with ibm-wxs-charm. If user selects Mixed Topology, user has to deploy ibm-was-nd-dm charm and ibm-wxs-client charm and have to do add-relation between ibm-was-nd-dm and ibm-wxs-client. Am I correct?
[14:35] <mbruzek> Anita_: Yes that is correct. The code would have to detect if was-nd was installed on the host system, and that code should not be too hard.
[14:38] <Anita_> Ok. Actually currently I have implemented partially ibm-wxs-client on WAS-ND. after add-relation between ibm-wxs-client and was-nd-dm, was-nd-dm is exposing the installation path, user name, password and profileName. Those informations are being used by ibm-wxs-client to install WXS Client.
[14:39] <Anita_> Is this approach correct?
[14:48] <Anita_> ibm-wxs-client needs to be installed under the same installation path of was-nd-dm. installation path, user name, password and profileName are configurable for was-nd-dm charm
[14:49] <mbruzek> Anita_: That looks correct. For the connection to ibm-was-nd-dm you should create a relation that exchanges that information.
[14:51] <Anita_> While relation will be departed, wxs needs to be uninstalled from was-nd-dm. But once relation departed, wxs client will not have those above informations. So is it better to store those informations in a file and use those for uninstallation?
[14:54] <Anita_> Actually Installation path and profile name can be extracted from was utility files. But admin and password needs to stop the running process and uninstall wxs client
[14:58] <mbruzek> Anita_: Breaking a relation has two parts. *-relation-departed and *-relation-broken you should be able to get the values from the relation in the first one *-relation-departed, if not the ibm-wxs-client should know the value from the last *-relation-changed event and can store that in a key value store that is provided
[15:00] <Anita_> mbruzek_:Ok
[15:02] <Anita_> mbruzek_:The latest design doc sent was having changes of split charms for wxs client. Will revert to the earlier design.
[15:03] <mbruzek> Anita_: OK good luck and if you encounter implementation problems let me know.
[15:03] <Anita_> mbuzek_:Thanks a Lot for clarifying all the doubts and for your time.
[15:03] <mbruzek> you are welcome, have a good night.
[15:04] <Anita_> mbruzek_: Will let you know if i will have any problem while implementing.
[15:04] <Anita_> mbuzek_:Thanks
[16:23] <bleepbloop> Any ideas why trying to import a file that was exported from juju would throw a `unmarshal errors: line 1: cannot unmarshal !!str `xenial` into charm.legacyBundleData`
=== frankban is now known as frankban|afk
[17:10] <beisner> marcoceppi, <3 the requirements of requirements dance:  https://github.com/juju/charm-tools/issues/246    thoughts?
[17:11] <mayurisapre> hi all.. i can have subordinate charm with global scope right?
[17:11] <marcoceppi> beisner: wtf
[17:12] <marcoceppi> mayurisapre: it will need a scope: container to define where it deploys to, but scope: global is implicit for all othe rrelations
[17:15] <mayurisapre> so what i want is .. subordinate charm should access to some processes in principle charm.. at the same time i dont want my subordinate charm to be deployed on each unit of principle charm..
[17:15] <mayurisapre> what is the way to achieve this?
[17:18] <marcoceppi> mayurisapre: you can't have both, if you need access to a process on the running machine, but don't want the charm on that machine there's no way to rectify those two properties
[17:18] <marcoceppi> mayurisapre: could you elaborate your usecase more?
[17:28] <bwallis> sorry I couldn't find documentation on this anywhere, but is there any way to place the juju controller inside the default model?
[17:29] <bwallis> it used to happen by default in older releases
[17:29] <marcoceppi> bwallis: any reason why you'd want to?
[17:29] <marcoceppi> bwallis: well, the controller was the only model
[17:29] <bwallis> yea, it burns a machine
[17:29] <bwallis> i don't have any low powered compute, and don't want to run it virtual
[17:29] <marcoceppi> bwallis: if you want to put stuff with the controller, you can `juju switch admin`
[17:29] <bwallis> i tried that, but it seems the juju-gui doesn't place nicely
[17:29] <bwallis> play*
[17:29] <marcoceppi> since admin is the model where the controller lives
[17:30] <marcoceppi> bwallis: juju-gui comes out of the box now
[17:30] <bwallis> with the controller model
[17:30] <marcoceppi> bwallis: `juju gui`
[17:30] <bwallis> let me try bootstrap again
[17:30] <marcoceppi> (everyone kept deploying --to 0, so we decided to do it for you)
[17:30] <bwallis> yea :)
[17:30] <bwallis> that part is OK, it just doesn't seem to work well with the controller model
[17:30] <bwallis> or maybe my juju gui was just broken
[17:31] <bwallis> i'm bootstrapping right now, so will try again
[17:31] <marcoceppi> bwallis: well the juju-gui charm is no longer needed for 2.0
[17:31] <marcoceppi> which is why it was probably breaking
[17:31] <bwallis> so, don't deploy it then? because yea i did last time
[17:31] <bwallis> i can see in the logs it is installing, almost finished
[17:31] <bwallis> so i'll give it a whirl
[17:32] <marcoceppi> bwallis: just type `juju gui --show-credentials`
[17:32] <bwallis> yea, when i connected to the GUI last time, no models were available at all
[17:32] <bwallis> the usual model drop down was missing
[17:32] <bwallis> i don't actually use the GUI for anything anyway, but want to show it off during a demo
[17:33] <bwallis> so it's not a massive problem for me
[17:35] <marcoceppi> bwallis: yeah, there was sometime around beta12-14 that the gui broke becaues of API changes
[17:35] <bwallis> yea, I think it was beta13 I was on
[17:35] <marcoceppi> bwallis: those should all be fixed now so long as you're on beta15
[17:36] <bwallis> so bootstrap is finished, it says it installed the GUI, but I can't see any processes using tcp 80 or 443
[17:36] <bwallis> on the controller
[17:36] <bwallis> this is was maas rc4 and juju beta15
[17:37] <bwallis> with*
[17:37] <marcoceppi> bwallis: just type `juju gui --show-credentials`
[17:37] <marcoceppi> gui runs on a different port
[17:37] <marcoceppi> it's built onto the API server
[17:37] <bwallis> oooooh
[17:37] <bwallis> you're absolutely right, port 17070
[17:37] <bwallis> let me try
[17:39] <bwallis> @marcoceppi: works! thanks!
[17:48] <marcoceppi> bwallis: cheers!
[17:53] <cholcombe> coreycb, so i ran debconf-get-selections on openattic.  I see a bunch of stuff in there. Do all debconf questions have default answers?
[17:53] <coreycb> cholcombe, I'm not really sure
[17:53] <cholcombe> ok
[17:54] <coreycb> cholcombe, if not then the charm would have to configure things I suppose
[17:55] <coreycb> cholcombe, where's the package located?
[17:55] <cholcombe> coreycb, http://download.openattic.org/
[17:55] <cholcombe> better yet: http://apt.openattic.org/pool/main/o/openattic/
[18:00] <coreycb> cholcombe, the debian source is at: https://bitbucket.org/openattic/openattic/src/d9caeb7619363c9126a77a2f4e206ad33d351014/debian/?at=development
[18:00] <coreycb> cholcombe, you could grep through that and find the debconf questions
[18:00] <cholcombe> coreycb, :)
[18:00] <coreycb> maybe there's defaults
[18:59] <magicaltrout> jcastro: you rang?
[19:15] <magicaltrout> i am around jcastro i just can't read the screen :)
=== natefinch is now known as natefinch-afk
=== beisner is now known as beisner-biab
=== beisner-biab is now known as beisner