[01:37] <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
[02:06] <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:12] <lucidone> Ooo, just saw kubernetesResources.serviceAccounts !
[02:12] <lucidone> That looks like my ticket to freedom
[02:14] <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?
[03:03] <kelvinliu> lucidone: so SA is always namespaced I think, but Role/ClusterRole could be different
[03:04] <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:06] <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:10] <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:12] <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:13] <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:15] <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:35] <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:41] <lucidone> That might be more challenging with the juju model .. Perhaps the default backend would be another charm that is then related
[03:50] <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:52] <lucidone> Ah right, yea sounds like a good one to discuss :)
[03:52] <kelvinliu> lucidone: so yeah, one charm one pod
[03:53] <kelvinliu> but u can have many containers in the pod
[03:54] <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
[09:14] <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:27] <nammn_de> manadart:  morning, some time for a quick HO?
[09:28] <manadart> nammn_de: Sure.
[09:28] <nammn_de> manadart: heading daily
[09:33] <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:43] <nammn_de> manadart: as you approve it, I will rebase those commits down
[09:44] <manadart> nammn_de: I will give it a last look now.
[11:36] <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:39] <manadart> nammn_de: Call it SupportsProviderSpaces with good comment differentiation between that and SupportsSpaces.
[11:39] <nammn_de> manadart: great, will do
[12:00] <manadart> Pre-real-work refactoring patch for service file writer: https://github.com/juju/juju/pull/11149
[12:01] <stickupkid> manadart, looking
=== narindergupta is now known as narinderguptamac
[15:30] <hml> wallyworld: ping
[17:45] <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:48] <stickupkid> nammn_de, he's gone :)
[17:49] <nammn_de> stickupkid: yeah, not time pressure anyway. Gonna ask him next week=D
[18:17] <madsage> juju make sandwich
[18:18] <madsage> greetings :)
[20:53] <addyess> frankban: any chance you can address https://github.com/go-macaroon-bakery/py-macaroon-bakery/issues/80
[20:54] <addyess> frankban: it's causing issues in https://zuul.opendev.org/t/openstack/build/e6195988f5374039a7645f1d1363c18a