| 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:20 |
|---|---|---|
| marcoceppi | aisrael: yeah, that's been gone for a while | 00:23 |
| 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:24 |
| marcoceppi | then sudo update-alternatives --config juju | 00:25 |
| marcoceppi | aisrael: ^^ | 00:27 |
| aisrael | marcoceppi: Huh. I remember when juju-1 was changed. I thought I'd installed this vm after that, though | 00:29 |
| marcoceppi | aisrael: 1.25.6 was released | 00:36 |
| marcoceppi | which reset that, probably | 00:36 |
| aisrael | Aha, that'd be the culprit! | 00:36 |
| aisrael | marcoceppi: when you have a chance, could you kill any instances owned by aisrael? Seems I've hit my quota | 01:07 |
| 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:08 |
| * 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:09 |
| * 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:10 | |
| marcoceppi | I may have to start actualy reaping | 01:11 |
| marcoceppi | lots of activity, which is awesome | 01:11 |
| aisrael | Yeah, that's a good problem to have | 01:12 |
| 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:15 |
| aisrael | is it a hard resource cap set by amazon? | 01:17 |
| 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:18 |
| aisrael | This is working well enough for my mini charm school, so I'm off for the night. Have a good one! | 01:37 |
| 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:46 |
| 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:47 |
| 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:48 |
| marcoceppi | thumper: and those charms have bigger problems | 02:49 |
| thumper | :) | 02:49 |
| kjackal | Hello Juju World! | 07:41 |
| === frankban|afk is now known as frankban | ||
| jcastro | magicaltrout: around today? | 12:27 |
| Anita_ | Hi Matt | 13:43 |
| mbruzek | Hello | 13:43 |
| 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:44 |
| mbruzek | Anita_: OK I am up to speed. | 13:47 |
| mbruzek | Anita_: What is your question? | 13:47 |
| Anita_ | The third charm of ibm-wxs i.e ibm-wxs-client can be deployed in two topologies | 13:48 |
| 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:49 |
| Anita_ | in the metadata. yaml, subordinate charm will be having either true or false. | 13:50 |
| 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:51 |
| Anita_ | ibm-wxs-was-client is a subordinate charm. | 13:52 |
| Anita_ | Is this approach correct? | 13:52 |
| 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? | 13:58 |
| 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:00 |
| 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:01 |
| mbruzek | Anita_: OK I see you answered my quest in the previous statement | 14:02 |
| 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:03 |
| 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:05 |
| 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:06 |
| 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:07 |
| Anita_ | can you please let us know? | 14:08 |
| 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:09 |
| 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:11 |
| 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:13 |
| Anita_ | In case of both options, user's options are to be taken? | 14:15 |
| mbruzek | Anita_: I don't understand the question. Can you rephrase? | 14:16 |
| 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:19 |
| 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:24 |
| Anita_ | Hmm Option 1 will be a better Option. | 14:26 |
| Anita_ | In case of Option 1 I have a query. | 14:27 |
| 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:30 |
| 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:35 |
| 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:38 |
| Anita_ | Is this approach correct? | 14:39 |
| 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:48 |
| mbruzek | Anita_: That looks correct. For the connection to ibm-was-nd-dm you should create a relation that exchanges that information. | 14:49 |
| 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:51 |
| 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:54 |
| 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 | 14:58 |
| Anita_ | mbruzek_:Ok | 15:00 |
| Anita_ | mbruzek_:The latest design doc sent was having changes of split charms for wxs client. Will revert to the earlier design. | 15:02 |
| 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:03 |
| Anita_ | mbruzek_: Will let you know if i will have any problem while implementing. | 15:04 |
| Anita_ | mbuzek_:Thanks | 15:04 |
| 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` | 16:23 |
| === frankban is now known as frankban|afk | ||
| beisner | marcoceppi, <3 the requirements of requirements dance: https://github.com/juju/charm-tools/issues/246 thoughts? | 17:10 |
| mayurisapre | hi all.. i can have subordinate charm with global scope right? | 17:11 |
| marcoceppi | beisner: wtf | 17:11 |
| marcoceppi | mayurisapre: it will need a scope: container to define where it deploys to, but scope: global is implicit for all othe rrelations | 17:12 |
| 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:15 |
| 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:18 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| bwallis | so it's not a massive problem for me | 17:33 |
| 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:35 |
| 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:36 |
| 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:37 |
| bwallis | @marcoceppi: works! thanks! | 17:39 |
| marcoceppi | bwallis: cheers! | 17:48 |
| 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:53 |
| coreycb | cholcombe, if not then the charm would have to configure things I suppose | 17:54 |
| 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/ | 17:55 |
| 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:00 |
| magicaltrout | jcastro: you rang? | 18:59 |
| magicaltrout | i am around jcastro i just can't read the screen :) | 19:15 |
| === natefinch is now known as natefinch-afk | ||
| === beisner is now known as beisner-biab | ||
| === beisner-biab is now known as beisner | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!