[08:03] Good morning Juju world! === frankban|afk is now known as frankban [09:55] Hello, guys! Do you know if I'm able to release a charm on charm store without uploading any resources ? My use case is that I have a charm that uses resources, but I don't want to upload them to charm store due to EULA. Still I want users to get the resources and deploy the charm specifying them at deploy. [09:57] Users will get the resources separately as described in the README, thus we don't get into trouble because we redistribute software. [10:16] ionutbalutoiu: Hi, yes you can do that [10:17] ionutbalutoiu: this is practicaly how all charms written prior to juju 2.0 work [10:17] let me grab you an example [10:17] ibalutoiu@samba:~/work/juju/charms/windows/azure-service-fabric$ charm release cs:~cloudbaseit/azure-service-fabric-8 [10:17] ERROR cannot release charm or bundle: bad request: charm published with incorrect resources: resources are missing from publish request: asf-zip-package, dotnet-installer [10:18] This is what I get when trying to release a charm that has resources defined but not uploaded. Remember, I mean 'release/publish' not push to the charm store. [10:19] ionutbalutoiu: Ah I see now what you are saying [10:19] ionutbalutoiu: you want to use the resources mechanism but not upload a binary [10:19] yep [10:19] ionutbalutoiu: yes we do have exmple for that too [10:19] as I want users to specify them at deploy. [10:20] ionutbalutoiu: the idea is that you upload a dummy empty file as a resource [10:20] ionutbalutoiu: let me grab an example :) [10:21] kjackal, yea. I thought about that too. But hoped that there might be a switch of something which I didn't find in the help to publish without resources. [10:22] ionutbalutoiu: I am not aware of any such switch [10:22] unfortunately the example I had in mind is not that helpfull [10:23] kjackal, people will now go the charm page and they can download the resources, a file will pop up for the download, but instead will be a fake file. [10:24] kjackal, that would do the work for now. But still imo it would've been better if resources remained grayed as it is now: https://jujucharms.com/u/cloudbaseit/azure-service-fabric/8 even after the publish. [10:25] Use case it is that sometimes EULA doesn't permit redistributing the software. So people using my resources have to go the original website, accept eula there, and provide the resource for my charm manually at deploy time. [10:25] I see your point. True, exposing the resources like this some times might be wrong. There might be resources there essoteric to th internal operation of the charm [10:26] Yep [10:29] Good point, would you want to send an email with your use-case on the list? Best case schenario there might be a way around this already, worst case the teams responsible for this would hear you. [10:29] Yep. Please do send. That would be awesome. [10:30] What should I tell them? Who are you? What is your affiliation & email? [10:30] I'm Ionut Balutoiu, Cloud Engineer at Cloudbase Solutions. The guys writing Juju charms for Windows. :) [10:31] Thanks [10:31] np [10:31] kjackal, For now, question is: When I upload an empty file as resource so I can publish the charm, if someone manually specifies the resource at deploy as I want them to, will the resource specified by the user get uploaded to state machine and not the default empty file from charm store, right? [10:33] Yes. You can even get the size of the resource you got from the store so that you detect that this is not the right file and display the right message [10:33] Cool [10:34] kjackal, and btw, ibalutoiu@cloudbasesolutions.com is my e-mail. You asked for this one also, sorry. [10:35] thanks I will put you in cc in case you want to add-up anything [10:41] Thank-you [10:45] There's also another topic that I have question for, if you still have some time or anyone else. Context, you have 4 peer units, you remove one unit, only in relation departed you still have access to relation data, I need relation data info, so I want to do my business logic here. [10:45] How do I find out which is the unit leaving and the ones staying ? As far as I noticed, relation departed triggers on all of them like this: once on the units remaining in the peer relation and N number of times on the unit leaving (where N is the number of units remaining). [10:51] ionutbalutoiu: Email sent [10:51] kjackal, received, thanks. [10:51] ionutbalutoiu: here is how we query for the nodes in spark: https://github.com/juju-solutions/interface-spark-quorum/blob/master/peers.py [10:52] we iterate over the conversations [10:53] Yes. I understand, but is there a way to figure out which is the unit leaving? [10:53] That would give you a list of all the peer units, right ? The one leaving and the others. I would like to know which is the one leaving. [10:54] ionutbalutoiu: A unit cannot tell if it is the one being torn down, or if it is $REMOTE_UNIT that is being torn down. [10:54] I'm sure there is an open bug on this... looking [10:55] stub, I just got into this use base when writing my last charm. Sometimes is if useful to know if you're leaving or not. [10:55] use case* [10:55] Yes. I have some data loss issues it causes. [10:56] If a Cassandra unit is leaving the cluster, it needs to decomission itself cleanly. If a different unit is leaving the cluster, it doesn't care. [10:56] Its tied up in https://bugs.launchpad.net/juju-core/+bug/1417874, but a separate bug report may help [10:56] Bug #1417874: [RFE] Impossible to cleanly remove a unit from a relation

[13:50] ionutbalutoiu, kjackal : I opened up https://github.com/juju/charmstore-client/issues/103 on optional resources. I realized this problem is going to hit all the charms we have in development using snaps. [13:50] thanks stub [13:52] thank-you stub [14:02] hi, I was using 'waiting' for things like waiting for a database relation, but after reading https://jujucharms.com/docs/stable/reference-status I should use 'blocking' for things like that, yes or no? [14:03] skay: yes, if your application doesn't function without a database then blocked is best [14:03] skay: it indicates that the user needs to pay attention here [14:03] skay: waiting is only temp and does not alarm the user [14:11] rick_h: thanks [14:11] (I'm also building up to some questions about reactive states) [14:16] ok, reactive states question. the docs don't show @hooks mixed with reactive state decorators. am I allowed to mix them? [14:17] if I can't mix them, then I'd just have conditionals inside my hook [14:28] Whoops, ranting on bug reports. Must be dinner time. [14:29] stub: :) [14:31] * stub wanders off to find a baby to eat [15:27] Hi guys [16:10] Heyo Spaulding (belated) [16:13] question, I'm not sure I should keep my install hook. I have a function that does some installation stuff @when_not('snap.installed.yadda') [16:13] so, I could just get rid of my install hook and use a reactive function instead. do I understand correctly? [16:20] skay: sounds about right === urulama is now known as urulama|off [16:21] cool [16:22] skay: to clarify, you're removing like @hook('install'), yeah? [16:22] marcoceppi: yes. because it doesn't seem necessary anymore [16:23] skay: totally, you almost never need to use @hook [16:23] the relation-joined/changed/departed hooks still get used a lot? [16:25] skay: oh, sure, but in the charm layers (not the interfaces) [16:30] marcoceppi: is there a state that gets set when a resource is attached? [16:30] marcoceppi: I didn't find it but maybe I overlooked it [16:30] skay: not at the moment, that's triggered in the @hook('upgrade-charm') [16:31] or, if provided during deploy, then it'll just be available [16:31] currently I'm just checking resource_get before deciding to install the snap [16:31] and in the upgrade-charm hook I check to see if the resource has actually changed [16:32] skay: yeah, resource_get will either get latest, or return current path [16:32] I'm doing that, and then checking any_file_changed([resource_file]) before calling snap.install [16:33] you or someone may have explained that the any_file_changed was good for checking for that [17:05] skay: it wasn't I, but it's actually a pretty good idea. I think we'll work to adding a resource.changed state into the base layer, but it'll need a bit more time to mature to figure out what that would look like form a usability perspective === frankban is now known as frankban|afk [17:38] are we no longer allowed to use the juju-info relation? [17:38] i'm seeing: ERROR charm "preserve" using a reserved relation name: "juju-info" [17:38] for 2.0.1 juju [17:39] oh nvm i had juju-info in the wrong place :) [17:39] hah [17:54] when I try to destroy-model it doesn't work because it cannot connect to API [17:54] what do I need to kick? === redir is now known as redir_travel [18:56] help, how did I kill juju this time [19:04] skay_: ? what's up? [19:05] skay_: use kill-controller if the controller is down and it should tear everything down bypassing the api server? [19:05] aha, I'll try that [19:06] the api server is not responding [19:06] yea, it should try, and then fail, and then go straight to the cloud provider to remove the machines using the provider's apis === hml_ is now known as hml [20:41] bcsaller, cory_fu: hadoop-processing working! (modulo the reset issue, at least) https://github.com/juju-solutions/matrix/pull/34 [21:14] bcsaller: any objections to me merging cory_fu's updated color handling? https://github.com/juju-solutions/matrix/pull/32 [21:16] petevg: sounds good [21:28] bcsaller: merged cory_fu's branch. Rebased and pushed an update for https://github.com/juju-solutions/matrix/pull/34 [21:29] petevg: Just added a minor comment / question to your PR [21:30] cory_fu: answered your question :-) [21:31] cory_fu: basically, lots of empty parens made me sad, and made me worry about bugs. [21:32] Yeah, fair enough. I think the no-parens vs empty-parens thing with Python decorators is kind of dumb. [21:33] petevg: I made @only_once work either way in charms.reactive: https://github.com/juju-solutions/charms.reactive/blob/master/charms/reactive/decorators.py#L217 [21:33] cory_fu: yeah. Admittedly, they are two separate beasts. Add the parens, and you either need another level of wrapper function, or another method in the class. The implementation would get really messy if you had to figure which one the user meant ... [21:33] But to do that with your decorator would be more of a hassel [21:33] *hassle [21:33] cory_fu: fancy :-) But yeah, too late on a Friday to figure out how to do that with the monster that I've built ... [21:34] petevg: Yeah, it's not worth worrying about [21:34] Cool. [21:39] petevg: Actually, now that I think about it, I don't really like the potential for errors with tag name typos, either. What about something like this: http://pastebin.ubuntu.com/23569587/ [21:40] cory_fu: if anyone wants to add actions and tags, they'll need to add a bunch of arguments to the tagged_action decorator. The idea with the tags was that outside actions could add to them, without messing with core. [21:41] petevg: What would such tags be useful for if they're not understood by the plan generator? [21:42] cory_fu: They might not be. But you're still looking at adding an arg in two places (plan, action) rather than three, plus checking to make sure that nobody has messed things up by making assumptions about positional arguments. [21:43] cory_fu: I guess another approach could be to make a list of constants in tags.py. That saves typos (or at least, surfaces them quickly). === scuttlemonkey is now known as scuttle|afk [22:08] cory_fu: updated my PR with the constants thing. If you want to argue strongly for just doing args, feel free. I think that the constants will be neater in the long run, though. [22:08] bcsaller ^ [22:09] cory_fu, kwmonroe: do we have the sauce for the hadoop-spark bundle checked in anywhere? [22:10] petevg: https://github.com/juju-solutions/bigtop/tree/feature/hadoop-spark-bundle/bigtop-deploy/juju/hadoop-spark [22:11] kwmonroe: got it. Is that close to being checked into master, by any chance? [22:12] no petevg, i haven't created a pr to link to https://issues.apache.org/jira/browse/BIGTOP-2561 yet [22:12] i mean, i could if you need it. it's not hard. i just haven't done it yet. [22:13] kwmonroe: I was going to brag about how we were in Apache bigtop in D.C., but then the bundle isn't actually in trunk. I can point the the source on the store, though, and then look at the apache repo once I get to the layer ... [22:20] cory_fu: heh. I had misspelled "subordinate" in my docstring. Thank you for pushing to less typo bugs :-) [22:27] hello [22:38] petevg: if you're still around, care to gander at this? https://github.com/apache/bigtop/pull/166 [22:39] no worries if you can't get to it tonight petevg. i can def get it merged before Monday. [22:39] kwmonroe: looking ... [22:40] kwmonroe: +1 thank you :-) [22:49] thar she blows petevg: https://github.com/apache/bigtop/tree/master/bigtop-deploy/juju have a good time in DC! [22:50] kwmonroe: yay! You rock. Thank you :-) [23:05] I'm creating a charm for NGINX, is there someone that can help me/review what I've done so far? [23:10] lucacome: unfortunately, it's already EOD for a lot of people that hang out here (i've got 1 foot out the door myself), but there is an nginx layer that may be helpful to consume/tweak: https://github.com/battlemidget/juju-layer-nginx [23:11] lucacome: to keep your issues from being lost in irc ether, i'd suggest firing off an email to the list (juju@lists.ubuntu.com) if you have specific charming questions or want to have some eyeballs on your work so far. [23:12] kwmonroe, yes I started from that implementat [23:12] *implementation