| === spaok_ is now known as spaok | ||
| * D4RKS1D3 morning | 09:23 | |
| kwmonroe | cory_fu: is there a tactic like 'ignore' that would ignore things in downstream layers? ie, my base layer has a HEY.md that i don't want propogated to charms that include my base layer. | 14:52 |
|---|---|---|
| cory_fu | kwmonroe: Yes. It's called ignore | 14:52 |
| cory_fu | Or maybe exclude | 14:52 |
| cory_fu | There's both, one in each direction | 14:52 |
| kwmonroe | ah - sweet. ignore ignores stuff upstream; i didn't know about exclude | 14:52 |
| cory_fu | kwmonroe: Actually, that might not do quite what you want. I think exclude ignores things from the current layer, but I don't think there's a way to say "exclude this forever more" | 14:54 |
| cory_fu | Because the assumption is that downstream layers should be able to override anything they want | 14:55 |
| cory_fu | Oh wait, that's exactly what you want. Exclude this file from the current layer | 14:55 |
| kwmonroe | cory_fu: as much as i enjoy you talking in circles, i think i'll just do some charm build tests myself. | 14:56 |
| cory_fu | :p | 14:56 |
| ak_dev | hi, i needed some help understanding the leadership layer | 16:09 |
| ak_dev | stub: are you free? just have a couple of questions | 16:10 |
| stub | sure. whats up? | 16:10 |
| ak_dev | stub: I wanted to know who / how it is decided who is the leader, and does every unit get to be leader like some sort of round robin? | 16:11 |
| stub | The Juju controller decides who is the leader. | 16:12 |
| stub | IIRC the first unit that asks is given leadership | 16:12 |
| stub | The lead unit remains the leader as long as it maintains the leadership lease | 16:13 |
| ak_dev | stub: oh, is there a way I can ask via code? Cause my use case requires that every unit be leader | 16:13 |
| stub | If the lead unit fails to renew the lease every 30 seconds, Juju will let the next unit that asks be the new leader | 16:13 |
| stub | You want to maintain your own leader, rather than using the Juju appointed one. Call it something different, like principal or master to avoid confusion | 16:14 |
| stub | Have the juju leader choose which of your units should be the principal | 16:15 |
| ak_dev | stub: could you point me to resources on how to ask / give up leadership? | 16:16 |
| ak_dev | in code that is | 16:17 |
| ak_dev | stub: | 16:18 |
| ak_dev | sorry, that was not intentional | 16:18 |
| stub | The leader needs to select the primary unit. If the primary unit needs to give up its role, it needs to signal the leader via the peer relation | 16:19 |
| stub | Its going to get complicated if you need that, so your best option may be an alternative approach | 16:20 |
| stub | Can you describe your use case? | 16:20 |
| ak_dev | stub: yeah | 16:20 |
| ak_dev | this charm is the OVN charm for kubernetes (to replace flannel) | 16:21 |
| ak_dev | so the OVN unit which is subordinate to worker, requests certificates from OVN unit which is subordinate to master | 16:21 |
| ak_dev | then, the OVN master unit responds with a certificate, which is then received by the other OVN worker unit | 16:21 |
| ak_dev | so, this has to happen for every OVN unit subordinate to k8s worker, there being only one master | 16:22 |
| * stub tries to remember if peer relations work for subordinates | 16:23 | |
| ak_dev | stub: If i remember right, subordinate relations are normal relations with just 'subordinate: true' | 16:24 |
| stub | I think you want a peer relation for this, and don't want to use leadership | 16:25 |
| ak_dev | oh alright, I was implementing it through peer relations, but ran in to some problem, so though of changing the approach to this | 16:26 |
| stub | Which subordinate is the master subordinate is controlled by the primary charm | 16:26 |
| stub | I think you just want each of your subordinates to publish on their peer relation if they are subordinate to the master, or subordinate to a worker. | 16:26 |
| stub | A worker subordinate can iterate over all the remote units in the peer relation to discover the one that is subordinate to the master | 16:27 |
| ak_dev | stub: hmm yeah, will do it this way then, probably a small error I am facing | 16:28 |
| ak_dev | cool, thanks a lot for the help :-) | 16:28 |
| stub | The worker likely doesn't even need to discover the master. It can just publish the request to the peer relation, and which ever unit happens to be subordinate to the master can respond. | 16:29 |
| ak_dev | yeah! This is kind of how I am doing it i think | 16:30 |
| stub | (which is a little nicer, as peer relations tend to be eventually consistent - you might end up with two units claiming to be master for instance, in which case you need to back off and try again later) | 16:30 |
| ak_dev | cool, if you too are thinking about the same approach, it must mean it works | 16:30 |
| ak_dev | great! | 16:30 |
| kwmonroe | raising the bar for you cory_fu: http://paste.ubuntu.com/25241863/ | 19:07 |
| cory_fu | :) | 19:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!