=== menn0 is now known as menn0-afk === natefinch-afk is now known as natefinch [02:36] how do i set the http/https proxy in juju 2.0 ? === menn0-afk is now known as menn0 === zz_CyberJacob is now known as CyberJacob === rogpeppe is now known as rogpeppe1 === frankban|afk is now known as frankban [12:22] bjf: juju set-model-config http_proxy= https_proxy= [12:22] https://jujucharms.com/docs/master/models-config [13:17] miken - I cannot speak authoritatively, but it appears that either its missing its own network config, or something is already bound to the ip/port its trying to bind to [13:38] stokachu, yeah, thanks, found it [14:34] Hello Team , We are developing a new charm for IBM Installation Manager on Z platform. As already an IM charm exist in charm store as ibm-im, What would be the charm name for IM on Z? [14:34] shruthima: does the Z charm need to do things a lot differently such that it can't be made to work on Z? [14:35] shruthima: ideally, we'd have the single ibm-im charm and if it was deployed on Z would do the right things to work there, if on power do those things, etc. So the end user can't use it incorrectly and there's no confusion between "which similarly named thing do I use?" [14:37] minor changes but similarly we have 3 more products we have do on Z which requires more changes , so we want to know what name can be given to Z platform charms if charm exist already [14:38] shruthima: you can add a -z to the name or the like. I'd just like to encourage that things work as widely as possible without potentially causing confusion to users. [14:38] is ibm-im-z can be fine ? [15:00] Actually rick_h_ we talked about this at the meeting with the IBM developers [15:00] That seems counter intuitive to have a charm per platform [15:01] i would think your original suggestion was more correct rick_h_, where there is a lsb_release check at the very beginning, and you can adjust based on states from there [15:01] rick_h_: The ecosystems team talked about this at length and think that they can add z-support on the series boundary but need to support all platforms in a new charm. [15:01] @when('z-series'); @when_not('ibm-im.installed') -- #perform z-series steps @when('ppc64le'); @when_not('ibm-im.installed') -- # perform ppc steps [15:02] mbruzek: lazyPower k, I'll leave you all to work it out with folks. [15:02] shruthima: to avoid juju user confusion the charm should have the same name. [15:02] thanks rick_h_ <3 [15:04] ok thanku mbruzek ,lazypower and rick_h_ === natefinch is now known as natefinch-afk === natefinch-afk is now known as natefinch [16:36] hi mbruzek/ kwmonroe , Good Morning.. I have pushed ibm spectrum symphony to charm store under cs:~ibmcharmers stream but it is not reflecting under charm store. Could you please check and advise on this? [16:37] what revision number? [16:37] cs:~ibmcharmers/ibm-spectrum-symphony-storage-0 [16:37] this is supported on both trusty and xenial [16:43] icey: ping [16:44] Prabakaran: did you publish the revision? [16:45] yes i did [16:45] i remember [16:45] Prabakaran: and granted everyone permissions? [16:46] yes i did [17:02] Just like to share the difficulties of using Google Cloud. It seems to like to change the external IPs from underneath the user and without the IPs to the controller machine your bonked until you go and update them. [17:02] Only way I found this was using the --debug flag on `juju list-models` [17:02] And checking that the IPs match the local configuration controllers.yaml [17:04] I've noticed juju automatically tags each machine with metadata specific to juju, so can't it just auto-negotiate the IP change by using the tags to find the controller? [17:05] fuzsz: interesting, can you file a bug on that please? [17:06] Sure. But the github repo doesn't seem to have bugs anymore? [17:07] I've also found a workaround. Google App Engine allows setting a static ip address to a machine. [17:07] fuzsz: right, https://bugs.launchpad.net/juju-core is the bugs [17:08] Any reason why launchpad can't sync with GitHub API to allow for bugs on the juju repository? Just an opinion; I'm not a fan of launchpad. [17:11] thanks rick_h_ .. i tried giving charm grant ... i am able to see my charms now [17:21] Hello Team, I have 3 charms let’s say A, B and X. Out of which A, B are principle charms and X is a subordinate charm. Here X is a subordinate charm to charm A. So I will be adding relation between A and X like [17:21] Juju deploy add-relation A X [17:21] In this scenario if X wants perform some operation on charm B [17:21] how would I relate these charms? Whether I need to add relation like [17:22] 1, juju add-relation A B 2, Juju add-relation X B ( Subordinate charm may sit into principle charm B, if so , I don’t want this to happen) Could someone explain me this scenario in detail? [17:33] hi cory_fu [17:33] can you please help me on the question? [17:33] Prabakaran: Hello [17:33] Hello Team, I have 3 charms let’s say A, B and X. Out of which A, B are principle charms and X is a subordinate charm. Here X is a subordinate charm to charm A. So I will be adding relation between A and X like [17:34] Juju deploy add-relation A X [17:34] In this scenario if X wants perform some operation on charm B [17:34] how would I relate these charms? Whether I need to add relation like [17:34] 1, juju add-relation A B 2, Juju add-relation X B ( Subordinate charm may sit into principle charm B, if so , I don’t want this to happen) Could someone explain me this scenario in detail? [17:35] Prabakaran: Ok, sure. It's basically what you suspected; you add a relation from X to B, and it should be a normal relation (i.e., not scope: conntainer) and then it will work just fine [17:36] can u give me some hint on metadata.yaml file on these? [17:37] Prabakaran: As an example, you can look at https://jujucharms.com/apache-hadoop-plugin/ It is subordinate (the hadoop-plugin relation) and has non-subordinate relations as well (namenode, resourcemanager) [17:37] The metadata.yaml file, of course, is at https://api.jujucharms.com/charmstore/v5/apache-hadoop-plugin/archive/metadata.yaml [17:41] k i will refer this.. I tried all these i was getting some issue.. I suspect it is becused of the provide /requires in the metadata.yaml file only. can u help me with the requires/provides section of metadata.yaml on this scenario for A, B and X. [17:42] hi === Arjun is now known as Guest30800 [17:44] Prabakaran: Ah, yes. provides / requires for subordinates is confusing. The principle charm should provide the scope:container relation and the subordinate should require the scope:container relation. For the non-subordinate relation (between B and X), which side provides and which requires doesn't matter as much, so should just be whatever makes the most sense. If X is using some functionality that B gives, then B would provide and X would [17:44] require. But X could also provide something for B to require if that makes more sense for your specific use-case. [17:46] k let me send u pastebin link can u correct if i am wrong in this scenario? [17:46] In the case of the apache-hadoop-plugin, the NameNode, for example, provides DFS services to the plugin, so on the plugin all the relations are requires, but it could be that the subordinate relation was requires (has to be) and the other relations could be provides [17:46] Sure === redelmann_ is now known as redelmann [17:55] hi cory_fu , below are the metadata.yaml files can you please correct me if I am wrong? I will correct it now only. Here I am using mysql-charm and mysql-root interface. X – Subordinate Charm - http://pastebin.ubuntu.com/23062310/ A – Principle Charm - http://pastebin.ubuntu.com/23062312/ B (mysql) - Principle Charm - http://pastebin.ubuntu.com/23062316/ [17:56] correct me on the metadata.yaml file of X charm and A charm [17:56] Prabakaran: Ok, just remove "scope: container" from the mysql block in the X (i.e., delete line 14) [17:57] That should be all you need to do [18:00] k cory_fu .. i did changes.. i am deployin now i wil let you know how it goes [18:00] Ok [18:02] charmers: I seem to be at an impasse with my reactive consul/consul-agent charms, I'm so close I feel .... would someone mind taking a look at consul/consul-agent for me? [18:02] bdx: Sure thing [18:03] bdx: link? [18:03] cory_fu: https://github.com/jamesbeedy/layer-consul-base, https://github.com/jamesbeedy/charm-consul-agent, https://github.com/jamesbeedy/charm-consul [18:04] cory_fu: http://paste.ubuntu.com/23062337/ [18:05] cory_fu: what appears to be happening, is my 'consul.connected' state doesn't seem to be getting recognized by the vault charm -> https://api.jujucharms.com/charmstore/v5/~chris.macnaughton/trusty/vault-0/archive/reactive/vault.py [18:06] such that vault never writes out the config.hcl .... I've been messing around with the consul-agent container relation .... taking it in and out of container scope, but I don't think thats what my problem is [18:10] the built charms are at https://jujucharms.com/u/jamesbeedy/consul/0, https://jujucharms.com/u/jamesbeedy/consul-agent/4, https://jujucharms.com/u/jamesbeedy/vault/4 [18:13] bdx: The interface layer that's registered for consul-agent on interfaces.juju.solutions is https://github.com/ChrisMacNaughton/juju-interface-consul and that has an empty provides.py [18:15] I don't know if that's causing your problem (shouldn't, unless you're rebuilding the vault charm), but it's certainly an issue [18:15] oh ... I am rebuilding the vault charm [18:15] oooo [18:15] cory_fu: I am able to add relation it is working fine but i am not able to perform any operation on the mysql database by Subordinate charm X [18:15] Then that's your issue [18:15] cory_fu: you are the man! [18:15] bdx: :) [18:16] Prabakaran: What do you mean by "perform an operation"? Do you mean using the relation interface, or do you mean that mysql itself is giving you errors? Can I see a copy of the errors? [18:16] cory_fu: I wonder why that ended up getting commented out lol? [18:16] icey:^? [18:17] bdx: No idea. Definitely looks wrong [18:17] good grief [18:17] i will be running database quries on mysql charm using subordinate charms [18:18] Prabakaran: Ok, so the queries are failing? That sounds like an issue with the reactive code, not the relations [18:19] it is working on principle charm mode [18:20] i will give u my sample code... it is very simple and it wil not take much time .. can u please check and tel me is there any issue .. i can correct it now only [18:20] Sure [18:22] Any ideas why on juju 2.0 beta12 after rebooting my state machines I am getting `health ping failed: connection is shut down` and no output from juju status? [18:22] Prabakaran: Are you trying to access the same database from both the principle and the subordinate? I think each relation to the mysql charm gives you a separate database, username, password, etc. You might need to use the mysql-shared interface instead. Or, if you really want the subordinate to act on behalf of the principle, then the DB info can be explicitly passed from the principle to the subordinate over their shared (scope:container) [18:22] relation [18:24] bleepbloop: It sounds like the juju services aren't coming back up, but I have not heard of that being an issue. [18:25] bleepbloop: Beta 15 is out now, so you could possibly try that. Otherwise, you might be better off asking in #juju-dev [18:25] Unless one of the core devs is on here and can chime in [18:26] @cory_fu: Okay, thanks. I was considering upgrading to juju beta 15 but I was a bit concerned about doing it when things were broken [18:27] I'll ask in juju-dev and see if they have a comment [18:39] cory_fu: I am performing database operation on subordinate charm side only. below are the code files can you please correct me if I am wrong? I will correct it now only. Here I am using mysql-charm and mysql-root interface. [18:39] Subordinate Charm https://code.launchpad.net/~prabacha/charms/trusty/sampledatabase/trunk Principle Charm - https://code.launchpad.net/~prabacha/charms/trusty/sampleprin/trunk Mysql database principle charm: https://code.launchpad.net/~prabacha/charms/trusty/mysql/trunk [18:41] Prabakaran: If you are only performing database operations in the subordinate, why does the principle need a relation to mysql at all? [18:42] correct [18:42] i think i can remove that part [18:43] i can add relation between mysql and sampledatabase (subordinate) charm [18:43] if so, any changes in the metadata.yaml file === zerick_ is now known as zerick [18:46] Let me give u what are the juju commands i ran.. [18:46] Prabakaran: Just remove the mysql block from the requires section [18:50] Juju deploy mysql [18:50] juju deploy sampledatabase [18:50] juju deploy sampleprin [18:50] juju add-relation sampledatabase sampleprin (As per the code It should show status as “waiting for mysql relation”) [18:50] juju add-relation mysql sampledatabase [18:50] these are the deployment command i ran [18:51] here mysql and sampleprin are principle charms [18:51] and sampledatabase is a subordinate [18:53] Post deployment sampledatabase subordinate charm doesnt perform any database operation on mysql charm cory_fu [18:54] cory_fu: do you want me to remove the mysql block from the requires section? [18:55] Prabakaran: It shouldn't really matter, but it just confuses things if the principle isn't going to interact with mysql anyway [18:56] I don't see anything that looks wrong with the subordinate charm code, though. I'm deploying it now [18:58] k let me know if it goes fine for you [18:58] cory_fu: [19:06] Prabakaran: Ok, I got the ACCESS DENIED error when it tries to do the GRANT. [19:06] Prabakaran: Did you modify the mysql charm? Why do you have a copy of it in LP instead of deploying it from the store? [19:06] you deploy mysql charm from the link [19:06] ya [19:07] this is related to mysql-root interface.. i have give pull request for the same that is y keeping local copy instead [19:08] I see. Re-testing with your branch now [19:08] k sure [19:12] Prabakaran: Ok, with your mysql branch it works. What is the problem, then? [19:13] is it working fine? [19:13] cory_fu: i am referring my LP links [19:13] Prabakaran: Yes, they deployed fine and the relations were ok. I didn't get any charm errors [19:14] And the code in the charms looks fine [19:14] k r u following any orders of running deployment commands [19:14] can you paste all the command that u ran [19:14] during deployments [19:15] juju commands [19:15] cory_fu: [19:17] Prabakaran: http://pastebin.ubuntu.com/ [19:18] cory_fu: link is empty [19:18] Prabakaran: ha. Sorry about that. http://pastebin.ubuntu.com/23062540/ [19:19] which version of juju that you are using? [19:19] cory_fu: [19:19] 1.25 [19:20] 1.25 [19:20] i am using 2.0 [19:20] Ok, let me try it in that [19:21] i am tried in 2.0-beta15-xenial-ppc64el [19:21] cory_fu: exactly [19:37] cory_fu: It is time for me to sleep ... can you please let me know the status on juju 2.0 deployment ? If it goes fine send me the all details with deployment command to this email prabacha@in.ibm.com. [19:37] Prabakaran: Ok, just finished deploying on 2.0-beta15 and it worked fine. I don't have access to Power machines, though. [19:38] :) [19:38] Prabakaran: The deployment commands were basically the same: http://pastebin.ubuntu.com/23062578/ [19:38] thank you so much cory_fu i wil also try the same [19:38] Ok. Have a good night! [19:39] thanks againg cory_fu for your patience [19:39] No problem [20:23] lazyPower: Thanks for the reply... actually it was just https://bugs.launchpad.net/bugs/1613489 [20:23] Bug #1613489: juju service names limited to 66 characters === mup_ is now known as mup [20:48] Is there a way to attach a resource from a URL so that I don't have to download it locally only to re-upload it to the controller? [20:48] It's a rather large file on S3 and I'm deploying to AWS [20:50] cory_fu: not that I know of, but doing the attach from an ec2 instance should make that reasonably fast. [20:50] How can I add-unit of a service from another running charm of a service? [20:50] If I have a relation between these 2 services [20:52] jrwren: Hrm. But that would require setting up and configuring Juju 2 on the instance. Though I suppose that shouldn't be too hard with charmbox [20:53] mayurisapre: Applications can't add or remove units on their own. You'd have to grant them access to the Juju API by giving them the auth token, and that's not recommended [20:53] cory_fu: copy .local/share/juju to a new ec2 instance? [20:54] jrwren: Isn't there a share command to send credentials? [20:54] cory_fu: not in 2.0 beta14, but things are moving quickly. maybe it does now. [20:54] Hrm. I thought that was something that had been around for a while [20:58] jrwren: I'm thinking of add-user and register. Doesn't that provide access pretty easily? === natefinch is now known as natefinch-afk [21:07] is there a guide to what is supposed to or allowed to be in the layers.yaml file? [21:07] s/layers/layer/g === wolverin_ is now known as wolverineav [21:10] cholcombe: The basic layer README covers pretty much everything, I think: https://github.com/juju-solutions/layer-basic/blob/master/README.md [21:10] cory_fu, thanks :) [21:11] Hrm, no, I'm wrong. It's missing some [21:11] This has more: https://github.com/juju/charm-tools/blob/master/doc/source/build.md#layeryaml [21:11] We need to consolidate that [21:12] Looks like that was started, but needs a bit more work: https://jujucharms.com/docs/devel/reference-layer-yaml [21:14] cory_fu, i see. yeah charm build was telling me to add a repo field to my layer.yaml but i didn't know what it wanted in that field [21:15] cholcombe: The message telling you to add it should give you an example. It just wants the link to the repo for the layer, so that `charm pull-source` knows what to fetch. [21:16] cory_fu, all i saw was this: build: Please add a `repo` key to your layer.yaml, with a url from which your layer can be cloned. [21:16] so repo: url: blah [21:17] cholcombe: Hrm. Was your layer not a bzr or git repository, or perhaps it hadn't been pushed yet? [21:17] yeah it was a git repo that i hadn't pushed yet [21:17] Ah, I see [21:17] Well, anyway, it's not required, just strongly suggested, thus why it's yellow [21:18] i added it :) [21:53] cory_fu, question about the apt layer if you've used it. i added 2 sources to the layer.yaml options: apt: packages: install_sources. It only seems to set the first one and skips the second [21:53] i can paste my layer.yaml [22:03] cholcombe: install_sources is actually a config option, since it might be changed by the user at deploy time [22:05] cholcombe: It's documented pretty well in the README, I think: https://git.launchpad.net/layer-apt/tree/README.md [22:06] lazyPower: i've double booked you again =/ [22:06] ffs [22:06] magicaltrout - i'm off tomorrow and was coming in for the meeting anyway [22:06] So, you'd want to override the default for install_sources in config.yaml, but set the apt: packages: in layer.yaml [22:06] lets cancel and reschedule [22:06] cory_fu, i'll mess around with it some more [22:06] fair enough i was gonna suggest later in the day [22:06] but that works [22:06] magicaltrout - hows friday? you busy mid-day friday? [22:06] cory_fu, i see [22:06] (mid-day utc) [22:07] friday is good, can you do 3pm BST or is that too early? [22:07] * lazyPower googles 3pm BST [22:08] you bet, thats 9am for me [22:09] cool shoot for then, the west coasters are still fetching coffee at that time [22:09] magicaltrout - moved, thanks for following up :) [22:09] we'll eventually make this happen [22:09] like all things :P [22:09] yeah sorry about that, this is what happens when you book meetings with a blind m an [22:09] well, i'm glad you're recovering well, i see you've adapted to the TTD workflow pretty well [22:10] s/pretty well/quickly/ [22:10] hehe [22:10] we'll see, got worse today when they took the contacts out, but then is supposed to imrpove quicker from now on [22:11] so by friday i might actually be able to see a screen ;) [22:11] i have my JPL slack zoomed at 180% currently to read it ;)