lucidone | Is it possible to define multiple service accounts in the k8sspec? It looks like it's not, as the serviceAccount key takes no name and requires a list of rules | 01:37 |
---|---|---|
lucidone | I'm also needing to bind multiple roles to the service account. Natively this is a ClusterRole and a Role. In k8sspec spec language this specific use case could be done if there were global:true rules and global:false rules | 02:06 |
lucidone | Ooo, just saw kubernetesResources.serviceAccounts ! | 02:12 |
lucidone | That looks like my ticket to freedom | 02:12 |
lucidone | Actually, that solves the first issue, but not the second. as each service account still takes a global key and a list of rules - does it allow specifying the same serviceAccount name twice? | 02:14 |
kelvinliu | lucidone: so SA is always namespaced I think, but Role/ClusterRole could be different | 03:03 |
kelvinliu | so u can't have two SA having same name in same namespace. | 03:04 |
tlm | lucidone: Are you able to provide any deatails on the integration you are doing for future reference | 03:04 |
kelvinliu | lucidone: and u can see `kubernetesResources.serviceAccounts` is actually an array, so u can create multi SA but they should have different names or K8s will give u an already exist error. | 03:06 |
lucidone | Yeap, the 'kubernetesResources.serviceAccounts' solves the first issue. I'm looking at charmifying the nginx-ingress helm chart. It has an nginx-ingress service account, and it binds a ClusterRole to it aswell as a Role - which I believe is currently unsupported as you define a serviceAccount with a global flag and a list of rules | 03:10 |
tlm | ah yeah I see the problem. The global rule shouldn't be defined on the SA but the rules | 03:12 |
lucidone | One possible fix would be to remove the global flag, and add a globalRules list instead .. so the user can specify either | 03:12 |
lucidone | But in general you can bind N roles to a given service account | 03:12 |
lucidone | So separating rules from the SA is a more general solution | 03:13 |
tlm | yeah. What about if each rule could be set global or not ? That way juju would make one clusterole and role and split them based on the flag ? | 03:13 |
tlm | but sounds like rules should not be tied so hard to sa's | 03:13 |
lucidone | global flag per rule would work for this use case. But yea, I think splitting is the better solution. Would allow you to define rule lists, and then bind as many as you wish to a set of service accounts | 03:15 |
lucidone | It looks like multiple services are also not supported? .. nginx-ingress needs to create 'nginx-ingress-controller' and 'nginx-ingress-default-backend' services | 03:35 |
lucidone | That might be more challenging with the juju model .. Perhaps the default backend would be another charm that is then related | 03:41 |
kelvinliu | lucidone: yeah, we used to support the main SA linking to multi role/cluster but later we changed to current spec because we wanted to make it simpler, but we can have a discussion on Tue. | 03:50 |
lucidone | Ah right, yea sounds like a good one to discuss :) | 03:52 |
kelvinliu | lucidone: so yeah, one charm one pod | 03:52 |
kelvinliu | but u can have many containers in the pod | 03:53 |
kelvinliu | so in this case, they would be two charms | 03:54 |
lucidone | Yea, that one makes a lot of sense with the juju model | 03:54 |
stickupkid | manadart, you looking into the focal stuff from the PR? | 09:14 |
manadart | stickupkid: Which stuff in particular? | 09:14 |
stickupkid | manadart, ignore me, I just saw your comment | 09:14 |
stickupkid | haha | 09:14 |
nammn_de | manadart: morning, some time for a quick HO? | 09:27 |
manadart | nammn_de: Sure. | 09:28 |
nammn_de | manadart: heading daily | 09:28 |
nammn_de | manadart: ahhh now I understand what you meant. Wrapping the type in spaces_test so we don't touch the stub_network as we don't plan to change it anymore. Thanks! | 09:33 |
nammn_de | manadart: as you approve it, I will rebase those commits down | 09:43 |
manadart | nammn_de: I will give it a last look now. | 09:44 |
nammn_de | manadart: regarding rename spaces provider support. Is adding a method to networking interface called seomthing along "supportspacesrenames" enough? Then implementing it on the supporting provider. In this case only ec2. | 11:36 |
manadart | nammn_de: Call it SupportsProviderSpaces with good comment differentiation between that and SupportsSpaces. | 11:39 |
nammn_de | manadart: great, will do | 11:39 |
manadart | Pre-real-work refactoring patch for service file writer: https://github.com/juju/juju/pull/11149 | 12:00 |
stickupkid | manadart, looking | 12:01 |
=== narindergupta is now known as narinderguptamac | ||
hml | wallyworld: ping | 15:30 |
nammn_de | manadart: shouldnt the method `DeltaOps` takes a collection param? As the collection we need to update in rename-space should be controllers? | 17:45 |
stickupkid | nammn_de, he's gone :) | 17:48 |
nammn_de | stickupkid: yeah, not time pressure anyway. Gonna ask him next week=D | 17:49 |
madsage | juju make sandwich | 18:17 |
madsage | greetings :) | 18:18 |
addyess | frankban: any chance you can address https://github.com/go-macaroon-bakery/py-macaroon-bakery/issues/80 | 20:53 |
addyess | frankban: it's causing issues in https://zuul.opendev.org/t/openstack/build/e6195988f5374039a7645f1d1363c18a | 20:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!