| blahdeblah | Charmers: a little birdy told me that there is currently no charm upgrade story from a non-reactive to a reactive charm; can anyone confirm or deny? And if confirm, give a bit of background - i.e. is this fixable? | 03:13 |
|---|---|---|
| jrwren | blahdeblah: its not true. charm-upgrade could always work, however, charms would have to be written to do so. very few charms have transitioned from non-reactive to reactive. | 03:15 |
| jrwren | Yes, this is absolutely fixable. | 03:15 |
| blahdeblah | jrwren: So I think I'll be wanting to do that in the quasi-near future; got any more details about what is required? | 03:19 |
| blahdeblah | beisner: ^ FYI - re discussion about NTP charm | 03:20 |
| jrwren | blahdeblah: i'm not the best to ask, but remember it is just scripts which execute. Test and make sure things don't break and upgrades will work fine. | 03:23 |
| blahdeblah | jrwren: hmm - OK; know of anyone else who has dealt with the issue in more depth? | 03:29 |
| jrwren | blahdeblah: lazyPower marcoceppi and some others who appear offline | 03:30 |
| blahdeblah | jrwren: Cool - thanks | 03:30 |
| jrwren | blahdeblah: for example, iirc many openstack charms are transitioning to reactive | 03:31 |
| === frankban|afk is now known as frankban | ||
| kjackal | Hello Juju World! | 08:51 |
| babbageclunk | hi kjackal! | 08:56 |
| jackweirdy | I know it's a mountain of a feature, but is it realistically possible in the long term to use docker instead of lxc for the local provider? It would give you local provider support for mac and windows for free | 09:00 |
| beisner | hi blahdeblah, jrwren - possible, but not at all simple. https://github.com/juju-solutions/charms.reactive/issues/77 | 11:53 |
| beisner | jrwren, we have no classic openstack charms rewritten in reactive for this reason. new charms, definitely reactive :-) | 11:55 |
| jrwren | beisner: ah! I was confused by the new ones. Thanks for the correction. | 12:34 |
| lazyPower | jrwren - i forget the specifics of what its not doing, however i know cory_fu has been looking into this | 12:37 |
| stokachu | anyone run into this: | 12:38 |
| stokachu | https://www.irccloud.com/pastebin/MYC9neDg/ | 12:38 |
| stokachu | beta 14 attempting to destroy a beta13 controller | 12:38 |
| lazyPower | stokachu - well thats a fun bug :) | 12:38 |
| lazyPower | looks like something certainly did get an upgrade that beta13 isn't responding to | 12:38 |
| stokachu | :D | 12:38 |
| stokachu | yea | 12:38 |
| rick_h_ | stokachu: lazyPower betas don't get upgrades | 12:39 |
| stokachu | i can't even force destroy it with kill-controller | 12:39 |
| stokachu | rick_h_: i know upgrades aren't supported which is why im attempting to destroy the controller and start fresh | 12:39 |
| lazyPower | rick_h_ - we need to adjust your keyword scoring mechanism | 12:39 |
| stokachu | rick_h_: at least we should be able to do that between version | 12:39 |
| lazyPower | stokachu - i can get you a revision of charmbox thats beta-13 if you need a temporary hand | 12:39 |
| lazyPower | s/hand/downgrade/ | 12:39 |
| stokachu | so i was able to manually terminate the controller in aws | 12:40 |
| stokachu | and now it's attempting to destroy through provider :\ | 12:40 |
| stokachu | lazyPower: thanks though | 12:40 |
| lazyPower | stokachu - welcome to the pain of having stale machine data in your config | 12:41 |
| stokachu | lazyPower: ugh, yea lemme get that charmbox rev so i can try to destroy that way | 12:42 |
| stokachu | rick_h_: are you saying that if i install beta14 and attempt to bring down a beta13 environment in order to be compatible with beta14 that this is expected? | 12:42 |
| rick_h_ | stokachu: yes, this is why we say 2.0 isn't prod ready. each beta is an island | 12:42 |
| rick_h_ | stokachu: we're not expected to support long running controllers until we hit RC | 12:43 |
| stokachu | well that's fun | 12:43 |
| rick_h_ | stokachu: yea :( | 12:43 |
| lazyPower | stokachu docker pull jujusolutions/charmbox:devel@sha256:fe61e24d903890502048a18783dc84c6e6d970efa32c1d97cffd22cf7af9fc92 | 12:44 |
| stokachu | hah installing docker to destroy a juju controller | 12:45 |
| * lazyPower rubs his hands together evilly | 12:45 | |
| lazyPower | yessss, let the hate flow through you | 12:45 |
| rick_h_ | stokachu: normally we suggest just shutting down using the cloud tools | 12:45 |
| rick_h_ | stokachu: with juju unregister | 12:45 |
| lazyPower | rick_h_ - what is this juju unregister you speak of? | 12:45 |
| stokachu | rick_h_: ah much easier than installing docker | 12:46 |
| rick_h_ | lazyPower: say you get a controller because of a juju share + juju register | 12:46 |
| lazyPower | :O | 12:46 |
| rick_h_ | lazyPower: you need a way to get rid of that controller from your juju controllers output | 12:46 |
| lazyPower | Details: | 12:46 |
| lazyPower | Removes local connection information for the specified controller. This command does not destroy the controller. In order to regain access to an unregistered controller, it will need to be added again using the juju register command. | 12:46 |
| rick_h_ | lazyPower: and unregister does that | 12:46 |
| lazyPower | time to mail the list! | 12:46 |
| stokachu | so i killed the instance in aws and did a juju unregister | 12:46 |
| stokachu | that should be all i need? | 12:46 |
| rick_h_ | stokachu: yea | 12:46 |
| stokachu | ok cool | 12:46 |
| rick_h_ | stokachu: unless you used storage/networking bits in which case you need to clean up the cloud bits used for that | 12:47 |
| stokachu | nah nothing fancy | 12:47 |
| rick_h_ | stokachu: yea, just being clear in case folks are watching :) | 12:47 |
| lazyPower | and list=pinged | 12:50 |
| lazyPower | stokachu - i'll get you to install docker one way or another ;) | 12:50 |
| stokachu | :D | 12:50 |
| === petevg_vacation is now known as petevg | ||
| === D4RKS1D3_OUT is now known as D4RKS1D3 | ||
| * D4RKS1D3 Hi to everyone | 13:11 | |
| lazyPower | o/ D4RKS1D3 | 13:20 |
| D4RKS1D3 | Hi lazyPower :) | 13:20 |
| D4RKS1D3 | Someone knows if is posible configure a service with two network interfaces? | 14:01 |
| lazyPower | D4RKS1D3 - depends on the charm and how its coded to handle networking. Most charms just leverage public-address/private-address according to how the charm author intended | 14:02 |
| lazyPower | some charms have extra-network-bindings | 14:02 |
| D4RKS1D3 | But if I create a new charm, juju has de capabilitie to put more than one nic | 14:03 |
| D4RKS1D3 | And this capabilitie is available in 1.25.3 or 2.0? | 14:05 |
| lazyPower | D4RKS1D3 - seems like we need to get more docs around the feature - but here's a bug to track https://github.com/juju/docs/issues/1163 | 14:18 |
| lazyPower | D4RKS1D3 - and network spaces surfaced preliminary in 1.25, its being expanded in 2.0. | 14:19 |
| === scuttle|afk is now known as scuttlemonkey | ||
| zeestrat | rick_h_: Are you looking at supporting upgrades for the RC's or only 2.0 proper? | 14:40 |
| rick_h_ | zeestrat: once we hit RC you should be able to upgrade a deployment from RC to RC and to 2.0 GA | 14:41 |
| zeestrat | rick_h_: Cool. Do you have a set amount of beta's and RC's that are you planning to go through? I see beta15 and rc1 in the timeline on LP. | 14:56 |
| rick_h_ | zeestrat: we're waiting to make a couple of backward incompatible changes before going to RC | 14:56 |
| rick_h_ | zeestrat: so not set | 14:56 |
| rick_h_ | zeestrat: it's more we try to do weekly betas with what's in | 14:56 |
| rick_h_ | zeestrat: and once we get the work items we know will cause issues for folks landed those betas with that work should be toward the end of our beta line | 14:57 |
| === natefinch is now known as natefinch-afk | ||
| zeestrat | rick_h_: Gotcha. So we're probably looking at Q4 for some of the later RC's and hopefully the GA? | 15:10 |
| rick_h_ | zeestrat: we're really hoping the next 8 weeks for sure | 15:13 |
| zeestrat | rick_h_: Good to know. Thanks :) | 15:17 |
| Spads | hi | 15:20 |
| Spads | a while ago someone here helped me with a command that dumped debug state for reactive relation stuff | 15:20 |
| Spads | while in debug-hooks | 15:20 |
| lazyPower | Spads - sounds like charms.reactive get_states | 15:20 |
| Spads | I run this from the shell? | 15:21 |
| lazyPower | in the hook context during debug-hooks, yep | 15:21 |
| Spads | cool thanks, confirmed it says the right thing... so now why is my code notr unning! | 15:21 |
| * Spads debugs | 15:22 | |
| lazyPower | Spads - welcome to the story of my life :) | 15:28 |
| lazyPower | Spads - whats even scarier is when you say "Why does this code work?" | 15:28 |
| Spads | hahaha | 15:28 |
| Spads | lazyPower: okay I think I need help here | 15:39 |
| Spads | my @when('juju-info.available') function never seems to run | 15:39 |
| Spads | despite: | 15:39 |
| Spads | 'juju-info.connected': {'conversations': ['reactive.conversations.juju-info.global'], 'relation': 'juju-info'}, 'juju-info.available': {'conversations': ['reactive.conversations.juju-info.global'], 'relation': 'juju-info'}} | 15:40 |
| Spads | like I put hookenv.log calls in the function and it's simply never run | 15:40 |
| Spads | I'm using the juju-info interface layer | 15:41 |
| Spads | What am I doing wrong? | 15:43 |
| === frankban is now known as frankban|afk | ||
| lazyPower | Spads - oh hey, sorry i stepped away from my desk. /me reads backscroll | 15:50 |
| lazyPower | that sounds correct. the state is raised when the relationship is established... is this on a requires or a provides side of the relationship? (hint: should always be on requires) | 15:52 |
| Spads | yeah, I just realised that @when is a synonym for @when_all | 15:52 |
| Spads | I assumed it would be an or! | 15:52 |
| lazyPower | @when_any | 15:52 |
| Spads | so my attempts to be all-encompassing faaaailed | 15:52 |
| Spads | yeah it's cool | 15:52 |
| lazyPower | it does happen :) | 15:52 |
| Spads | I narrowed it back down to the surgical event again | 15:52 |
| Spads | and now I have other people to blame | 15:52 |
| lazyPower | nice! | 15:52 |
| * Spads 🔥 to bare except: statements | 15:52 | |
| lazyPower | dont charm-blame us ;) | 15:52 |
| Spads | hahahaha | 15:53 |
| lazyPower | i guess in this context, it would be charm-layers us | 15:53 |
| lazyPower | i should add that as an alias for the lulz | 15:53 |
| Spads | well the reactive layers stuff is kind of horrible in the sense that there are all these magic strings that aren't very well documented or inspectable | 15:53 |
| Spads | if you get one of those wrong... | 15:53 |
| lazyPower | magic strings? | 15:53 |
| Spads | yeah | 15:53 |
| Spads | all the '{provides:foo}-derp-{lerp,dorp}' | 15:54 |
| Spads | and then working out what you're supposed to key off of on the other side | 15:54 |
| Spads | and the docs for the layer just say {{name}} | 15:54 |
| Spads | which, uh, thanks? | 15:54 |
| lazyPower | well, thats a byproduct of how juju implements relationships | 15:54 |
| Spads | like stuff just happens as strings | 15:54 |
| lazyPower | an interface is bound to a realtionship name. We need a way to bind on that. so templating the reactive state was the middle of the road | 15:54 |
| Spads | no type checking, no logging of what it's doing | 15:54 |
| lazyPower | all the typechecking and etc should be handled by the interface itself | 15:54 |
| Spads | yeah, I just wish it had a way of telling me precisely what it's doing and why I'm failing | 15:54 |
| Spads | because we've been SO CONFUSED about the interface name vs the relation name vs the remote service name... | 15:55 |
| Spads | and you just try them all and waste hours when something doesn'tw ork | 15:55 |
| Spads | because it's all just strings! | 15:55 |
| lazyPower | Spads - i really want you to file bugs about stuff like that | 15:56 |
| Spads | ok | 15:56 |
| Spads | will do | 15:56 |
| lazyPower | if its been causing you headache, we need to get bugs filed against our charm developer docs to make them easier for the world at large. I'm certain you're not the only one who's run into this. | 15:56 |
| lazyPower | relationships were the most contentious document prior to the reactive refactoring, so its no surprise to me that they yet still remain largely mysterious and misunderstood | 15:57 |
| Spads | https://bugs.launchpad.net/charm-helpers/+bug/1611024 | 15:59 |
| mup | Bug #1611024: magic strings in reactive relations lead to confusion <Charm Helpers:New> <https://launchpad.net/bugs/1611024> | 15:59 |
| lazyPower | Need a quick review on https://github.com/juju-solutions/interface-juju-info/pull/3 | 16:01 |
| lazyPower | Thanks Spads, i broke that up into the respective places i think it targets. | 16:16 |
| Spads | thanks | 16:16 |
| mattrae | hi, i'm attempting to upgrade an environment from juju 2.0 beta 7 to beta 14. after installing the beta 14 juju packages, juju status is asking me to log in. when i try to log in it hangs. i'm hoping i can upgrade and not have to redeploy the environment. https://pastebin.canonical.com/162628/ | 16:36 |
| lazyPower | mattrae - 2.0 are listed as betas and treated as islands, we wont support controller upgrades until 2.0 hits -rc | 16:53 |
| lazyPower | there will be upgrade paths from release-candidates forward | 16:53 |
| lazyPower | the current method is to destroy the controller and re-bootstrap on the new beta | 16:53 |
| === natefinch-afk is now known as natefinch | ||
| mattrae | lazyPower: thanks for the details about upgrades. we'll see if re-bootstrapping is a possiblity | 17:13 |
| mayuri_ | hello everyone..! Good moring | 17:48 |
| lazyPower | o/ mayuri_ | 17:48 |
| mayuri_ | I am writing a juju charm and need help for the same | 17:56 |
| lazyPower | mayuri_ - Have you read the developer docs? https://jujucharms.com/docs/stable/developer-getting-started this is the best resource to get started writing a charm. | 17:58 |
| mayuri_ | yes | 17:58 |
| mayuri_ | i have read these docs | 17:59 |
| mayuri_ | i have a specific query.. | 18:00 |
| kwmonroe | fire away mayuri_ | 18:01 |
| cholcombe | what's the juju2 equiv of destroy-machine --force? I have some stuck units i can't remove | 18:02 |
| mayuri_ | can you please go through the this question? | 18:04 |
| mayuri_ | http://askubuntu.com/questions/808638/how-to-get-ip-addresses-of-all-units-in-a-service-in-juju-charm | 18:04 |
| kwmonroe | cholcombe: remove-machine --force | 18:05 |
| cholcombe | kwmonroe, cool thanks | 18:06 |
| mayuri_ | I am not able to get ip addresses if all units which are participating in a relation. | 18:12 |
| mayuri_ | can anybody help me with that? | 18:17 |
| mbruzek | kwmonroe: Prabakaran wants to check in his layer code on launchpad, but got an error. What should be the recommended location for the layer code? | 19:19 |
| kwmonroe | mbruzek: i think lp:~ibmcharmers/layers/layer-<charm>/trunk | 19:21 |
| kwmonroe | mbruzek: but i'm not sure if /layers/ needs to be a project first or not | 19:22 |
| kwmonroe | i know you have reservations that layers is too generic, but i'm not too worried about that | 19:22 |
| Prabakaran | kwmonroe: shall i try with this branch lp:~ibmcharmers/layers/layer-<charm>/trunk | 19:23 |
| mbruzek | kwmonroe: I am worried about layers may be too generic to create a project for that. | 19:24 |
| kwmonroe | oh, i see mbruzek.. is that because LP would require that to be unique across all namespaces? | 19:24 |
| mbruzek | kwmonroe: That is my concern, I am chatting with sinzui right now about this. | 19:26 |
| kwmonroe | unfortuantely mbruzek, i don't think many are using LP for their layered source.. i just checked all the big data branches and all our layered stuff is in github | 19:26 |
| kwmonroe | mbruzek: Prabakaran, just so i'm clear.. the problem here is because pushing to lp:~name/charms requires a series to be in the branch, and multiseries charms break that? | 19:27 |
| kwmonroe | iow, you can't push a trusty/xenial multiseries foo charm to lp:~name/charms/foo/trunk? | 19:28 |
| Prabakaran | ya my charm is supported on both xenial and trusty | 19:28 |
| Prabakaran | i tried this bzr push lp:~ibmcharmers/layer-ibm-spectrum-symphony/trunk .... | 19:30 |
| Prabakaran | is not working | 19:30 |
| Prabakaran | k | 19:31 |
| mbruzek | Prabakaran: Yes the reason for that is there is no project named layers-ibm-spectrum-symphony | 19:31 |
| mbruzek | Prabakaran: So you could create said project but that would be tedious to do every time you have a new layer. | 19:31 |
| Prabakaran | let me try like this lp:~name/charms/<charm name>/trunk | 19:31 |
| mbruzek | Prabakaran: no that really isn't the right location for _layer_ code. | 19:32 |
| mbruzek | Prabakaran: kwmonroe and I are looking into creating a project named "layers" if that makes sense | 19:32 |
| Prabakaran | so i will have to push built charm only to these branches right? | 19:32 |
| Prabakaran | ok that would help | 19:33 |
| Prabakaran | its time for my bed..if anytning please mail me on this. i will try and come back to you. thanks mbruzek kwmonroe for your help on ths | 19:35 |
| mbruzek | Prabakaran: we will continue with an email | 19:36 |
| Prabakaran | thanks mbruzek | 19:36 |
| kwmonroe | have a good night Prabakaran! | 19:36 |
| kwmonroe | mbruzek: wasn't there a time when lp:~name/charms/<series>/<charm>/[trunk | layer] was a thing? | 19:38 |
| mbruzek | kwmonroe: I am not clear on that. | 19:39 |
| kwmonroe | so the project was still /charms/, with layered source in the ./layer branch and built charm in ./trunk | 19:39 |
| mbruzek | I am worried about people confusing .../charms/ with __charm__ code and not layer code | 19:39 |
| kwmonroe | ack.. it's a bit m00t here anyway since that won't work for multi-series charms anyway. i think <series> was required in the /charms/ project. | 19:40 |
| mbruzek | maybe my concern is unfounded, but I have had to explain a few things like this recently | 19:40 |
| mbruzek | kwmonroe: It seems like we have discussed this before | 19:41 |
| kwmonroe | yeah mbruzek, who's the expert here? seems clear that you and i don't know what we're doing, and i loathe going round-and-round with you. | 19:41 |
| mbruzek | kwmonroe: I am trying to remember _when_ we talked about this last. | 19:41 |
| mbruzek | kwmonroe: I loathe you too buddy | 19:42 |
| kwmonroe | mbruzek: it would have been right around the time ibm switched to layered charms, so early 2016. and i'm fairly sure we went with ./layer vs ./trunk for the branch name precisely because we couldn't find a common root project to replace charms and we didn't want every charm to be a new project. | 19:43 |
| mbruzek | kwmonroe: It looks like you created lp:~ibmcharmers/layer-ibm-base/trunk on 03-23-2016 and modified it on 06-02-2016 | 19:45 |
| cory_fu | tvansteenburgh just showed me ngrok.io for letting other people access services run with local provider and it's the coolest thing I've seen all week | 20:50 |
| cory_fu | Just wanted to mention it here, in case it's new to anyone else | 20:50 |
| magicaltrout | not month though | 20:52 |
| magicaltrout | can't be that great ;) | 20:52 |
| magicaltrout | hmm | 20:55 |
| magicaltrout | interesting | 20:55 |
| bdx | oh the possibilities | 21:00 |
| bdx | cory_fu, tvansteenburgh: thanks for sharing | 21:00 |
| === natefinch is now known as natefinch-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!