blahdeblahCharmers: 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
jrwrenblahdeblah: 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
jrwrenYes, this is absolutely fixable.03:15
blahdeblahjrwren: 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
blahdeblahbeisner: ^ FYI - re discussion about NTP charm03:20
jrwrenblahdeblah: 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
blahdeblahjrwren: hmm - OK; know of anyone else who has dealt with the issue in more depth?03:29
jrwrenblahdeblah: lazyPower marcoceppi and some others who appear offline03:30
blahdeblahjrwren: Cool - thanks03:30
jrwrenblahdeblah: for example, iirc many openstack charms are transitioning to reactive03:31
=== frankban|afk is now known as frankban
kjackalHello Juju World!08:51
babbageclunkhi kjackal!08:56
jackweirdyI 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 free09:00
beisnerhi blahdeblah, jrwren - possible, but not at all simple.  https://github.com/juju-solutions/charms.reactive/issues/7711:53
beisnerjrwren, we have no classic openstack charms rewritten in reactive for this reason.  new charms, definitely reactive :-)11:55
jrwrenbeisner: ah! I was confused by the new ones. Thanks for the correction.12:34
lazyPowerjrwren - i forget the specifics of what its not doing, however i know cory_fu has been looking into this12:37
stokachuanyone run into this:12:38
stokachubeta 14 attempting to destroy a beta13 controller12:38
lazyPowerstokachu - well thats a fun bug :)12:38
lazyPowerlooks like something certainly did get an upgrade that beta13 isn't responding to12:38
rick_h_stokachu: lazyPower betas don't get upgrades12:39
stokachui can't even force destroy it with kill-controller12:39
stokachurick_h_: i know upgrades aren't supported which is why im attempting to destroy the controller and start fresh12:39
lazyPowerrick_h_ - we need to adjust your keyword scoring mechanism12:39
stokachurick_h_: at least we should be able to do that between version12:39
lazyPowerstokachu - i can get you a revision of charmbox thats beta-13 if you need a temporary hand12:39
stokachuso i was able to manually terminate the controller in aws12:40
stokachuand now it's attempting to destroy through provider :\12:40
stokachulazyPower: thanks though12:40
lazyPowerstokachu - welcome to the pain of having stale machine data in your config12:41
stokachulazyPower: ugh, yea lemme get that charmbox rev so i can try to destroy that way12:42
stokachurick_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 island12:42
rick_h_stokachu: we're not expected to support long running controllers until we hit RC12:43
stokachuwell that's fun12:43
rick_h_stokachu: yea :(12:43
lazyPowerstokachu docker pull jujusolutions/charmbox:devel@sha256:fe61e24d903890502048a18783dc84c6e6d970efa32c1d97cffd22cf7af9fc9212:44
stokachuhah installing docker to destroy a juju controller12:45
* lazyPower rubs his hands together evilly12:45
lazyPoweryessss, let the hate flow through you12:45
rick_h_stokachu: normally we suggest just shutting down using the cloud tools12:45
rick_h_stokachu: with juju unregister12:45
lazyPowerrick_h_ - what is this juju unregister you speak of?12:45
stokachurick_h_: ah much easier than installing docker12:46
rick_h_lazyPower: say you get a controller because of a juju share + juju register12:46
rick_h_lazyPower: you need a way to get rid of that controller from your juju controllers output12:46
lazyPowerRemoves 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 that12:46
lazyPowertime to mail the list!12:46
stokachuso i killed the instance in aws and did a juju unregister12:46
stokachuthat should be all i need?12:46
rick_h_stokachu: yea12:46
stokachuok cool12:46
rick_h_stokachu: unless you used storage/networking bits in which case you need to clean up the cloud bits used for that12:47
stokachunah nothing fancy12:47
rick_h_stokachu: yea, just being clear in case folks are watching :)12:47
lazyPowerand list=pinged12:50
lazyPowerstokachu - i'll get you to install docker one way or another ;)12:50
=== petevg_vacation is now known as petevg
=== D4RKS1D3_OUT is now known as D4RKS1D3
* D4RKS1D3 Hi to everyone13:11
lazyPowero/ D4RKS1D313:20
D4RKS1D3Hi lazyPower :)13:20
D4RKS1D3Someone knows if is posible configure a service with two network interfaces?14:01
lazyPowerD4RKS1D3 - 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 intended14:02
lazyPowersome charms have extra-network-bindings14:02
D4RKS1D3But if I create a new charm, juju has de capabilitie to put more than one nic14:03
D4RKS1D3And this capabilitie is available in 1.25.3 or 2.0?14:05
lazyPowerD4RKS1D3 - seems like we need to get more docs around the feature - but here's a bug to track https://github.com/juju/docs/issues/116314:18
lazyPowerD4RKS1D3 - and network spaces surfaced preliminary in 1.25, its being expanded in 2.0.14:19
=== scuttle|afk is now known as scuttlemonkey
zeestratrick_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 GA14:41
zeestratrick_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 RC14:56
rick_h_zeestrat: so not set14:56
rick_h_zeestrat: it's more we try to do weekly betas with what's in14: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 line14:57
=== natefinch is now known as natefinch-afk
zeestratrick_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 sure15:13
zeestratrick_h_: Good to know. Thanks :)15:17
Spadsa while ago someone here helped me with a command that dumped debug state for reactive relation stuff15:20
Spadswhile in debug-hooks15:20
lazyPowerSpads - sounds like charms.reactive get_states15:20
SpadsI run this from the shell?15:21
lazyPowerin the hook context during debug-hooks, yep15:21
Spadscool thanks, confirmed it says the right thing... so now why is my code notr unning!15:21
* Spads debugs15:22
lazyPowerSpads - welcome to the story of my life :)15:28
lazyPowerSpads - whats even scarier is when you say "Why does this code work?"15:28
SpadslazyPower: okay I think I need help here15:39
Spadsmy @when('juju-info.available') function never seems to run15: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
Spadslike I put hookenv.log calls in the function and it's simply never run15:40
SpadsI'm using the juju-info interface layer15:41
SpadsWhat am I doing wrong?15:43
=== frankban is now known as frankban|afk
lazyPowerSpads - oh hey, sorry i stepped away from my desk. /me reads backscroll15:50
lazyPowerthat 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
Spadsyeah, I just realised that @when is a synonym for @when_all15:52
SpadsI assumed it would be an or!15:52
Spadsso my attempts to be all-encompassing faaaailed15:52
Spadsyeah it's cool15:52
lazyPowerit does happen :)15:52
SpadsI narrowed it back down to the surgical event again15:52
Spadsand now I have other people to blame15:52
* Spads 🔥 to bare except: statements15:52
lazyPowerdont charm-blame us ;)15:52
lazyPoweri guess in this context, it would be charm-layers us15:53
lazyPoweri should add that as an alias for the lulz15:53
Spadswell 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 inspectable15:53
Spadsif you get one of those wrong...15:53
lazyPowermagic strings?15:53
Spadsall the '{provides:foo}-derp-{lerp,dorp}'15:54
Spadsand then working out what you're supposed to key off of on the other side15:54
Spadsand the docs for the layer just say {{name}}15:54
Spadswhich, uh, thanks?15:54
lazyPowerwell, thats a byproduct of how juju implements relationships15:54
Spadslike stuff just happens as strings15:54
lazyPoweran 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 road15:54
Spadsno type checking, no logging of what it's doing15:54
lazyPowerall the typechecking and etc should be handled by the interface itself15:54
Spadsyeah, I just wish it had a way of telling me precisely what it's doing and why I'm failing15:54
Spadsbecause we've been SO CONFUSED about the interface name vs the relation name vs the remote service name...15:55
Spadsand you just try them all and waste hours when something doesn'tw ork15:55
Spadsbecause it's all just strings!15:55
lazyPowerSpads - i really want you to file bugs about stuff like that15:56
Spadswill do15:56
lazyPowerif 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
lazyPowerrelationships were the most contentious document prior to the reactive refactoring, so its no surprise to me that they yet still remain largely mysterious and misunderstood15:57
mupBug #1611024: magic strings in reactive relations lead to confusion <Charm Helpers:New> <https://launchpad.net/bugs/1611024>15:59
lazyPowerNeed a quick review on https://github.com/juju-solutions/interface-juju-info/pull/316:01
lazyPowerThanks Spads, i broke that up into the respective places i think it targets.16:16
mattraehi, 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
lazyPowermattrae - 2.0 are listed as betas and treated as islands, we wont support controller upgrades until 2.0 hits -rc16:53
lazyPowerthere will be upgrade paths from release-candidates forward16:53
lazyPowerthe current method is to destroy the controller and re-bootstrap on the new beta16:53
=== natefinch-afk is now known as natefinch
mattraelazyPower: thanks for the details about upgrades. we'll see if re-bootstrapping is a possiblity17:13
mayuri_hello everyone..!  Good moring17:48
lazyPowero/ mayuri_17:48
mayuri_I am writing a juju charm and need help for the same17:56
lazyPowermayuri_ - 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_i have read these docs17:59
mayuri_i have a specific query..18:00
kwmonroefire away mayuri_18:01
cholcombewhat's the juju2 equiv of destroy-machine --force?  I have some stuck units i can't remove18:02
mayuri_can you please go through the this question?18:04
kwmonroecholcombe: remove-machine --force18:05
cholcombekwmonroe, cool thanks18: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
mbruzekkwmonroe: 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
kwmonroembruzek: i think lp:~ibmcharmers/layers/layer-<charm>/trunk19:21
kwmonroembruzek: but i'm not sure if /layers/ needs to be a project first or not19:22
kwmonroei know you have reservations that layers is too generic, but i'm not too worried about that19:22
Prabakarankwmonroe: shall i try with this branch lp:~ibmcharmers/layers/layer-<charm>/trunk19:23
mbruzekkwmonroe: I am worried about layers may be too generic to create a project for that.19:24
kwmonroeoh, i see mbruzek.. is that because LP would require that to be unique across all namespaces?19:24
mbruzekkwmonroe: That is my concern, I am chatting with sinzui right now about this.19:26
kwmonroeunfortuantely 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 github19:26
kwmonroembruzek: 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
kwmonroeiow, you can't push a trusty/xenial multiseries foo charm to lp:~name/charms/foo/trunk?19:28
Prabakaranya my charm is supported on both xenial and trusty19:28
Prabakarani tried this bzr push lp:~ibmcharmers/layer-ibm-spectrum-symphony/trunk ....19:30
Prabakaranis not working19:30
mbruzekPrabakaran: Yes the reason for that is there is no project named layers-ibm-spectrum-symphony19:31
mbruzekPrabakaran: So you could create said project but that would be tedious to do every time you have a new layer.19:31
Prabakaranlet me try like this lp:~name/charms/<charm name>/trunk19:31
mbruzekPrabakaran: no that really isn't the right location for _layer_ code.19:32
mbruzekPrabakaran: kwmonroe and I are looking into creating a project named "layers" if that makes sense19:32
Prabakaranso i will have to push built charm only to these branches right?19:32
Prabakaranok that would help19:33
Prabakaranits 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 ths19:35
mbruzekPrabakaran: we will continue with an email19:36
Prabakaranthanks mbruzek19:36
kwmonroehave a good night Prabakaran!19:36
kwmonroembruzek: wasn't there a time when lp:~name/charms/<series>/<charm>/[trunk | layer] was a thing?19:38
mbruzekkwmonroe: I am not clear on that.19:39
kwmonroeso the project was still /charms/, with layered source in the ./layer branch and built charm in ./trunk19:39
mbruzekI am worried about people confusing .../charms/ with __charm__ code and not layer code19:39
kwmonroeack.. 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
mbruzekmaybe my concern is unfounded, but I have had to explain a few things like this recently19:40
mbruzekkwmonroe: It seems like we have discussed this before19:41
kwmonroeyeah 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
mbruzekkwmonroe: I am trying to remember _when_ we talked about this last.19:41
mbruzekkwmonroe: I loathe you too buddy19:42
kwmonroembruzek: 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
mbruzekkwmonroe: It looks like you created lp:~ibmcharmers/layer-ibm-base/trunk on 03-23-2016 and modified it on 06-02-201619:45
cory_futvansteenburgh 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 week20:50
cory_fuJust wanted to mention it here, in case it's new to anyone else20:50
magicaltroutnot month though20:52
magicaltroutcan't be that great ;)20:52
bdxoh the possibilities21:00
bdxcory_fu, tvansteenburgh: thanks for sharing21:00
=== natefinch is now known as natefinch-afk

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!