invalid knative deployments when using SDK functions to upload workflows about knix

[iakkus]

Is this reproducible via giving the workflow a very long name, so that the revision name will be longer than 63 characters? The example 'xyz' doesn't seem to actually create that long revision name. Or is it just an example?

[ksatzke]

Hi Ekin, quite right, I have given the workflow a long name >63 character which cause the problem reproducibly. Furthermore, the workflow name contained a “/” character, which causes problems even with shorter names. The name was auto-generated by asl_Map state test script using paths and filenames of workflow definition files (which probably wasn’t a good idea from the beginning). Shortening the path names and modifying/extending the wf actual name sanitation in deployWorkflow resolved the problem. BR Klaus From: Istemi Ekin Akkus <[email protected]> Sent: Wednesday, October 7, 2020 4:22 PM To: knix-microfunctions/knix <[email protected]> Cc: Satzke, Klaus (Nokia - DE/Stuttgart) <[email protected]>; Assign <[email protected]> Subject: Re: [knix-microfunctions/knix] invalid knative deployments when using SDK functions to upload workflows (#86) Is this reproducible via giving the workflow a very long name, so that the revision name will be longer than 63 characters? The example 'xyz' doesn't seem to actually create that long revision name. Or is it just an example? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#86 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADFTJEIJNSKK2S3BASU5XJ3SJR2R7ANCNFSM4SF6VVMQ>.

[iakkus]

Is this fixed in the 'develop' branch?

It seems like this is only problematic for the labels assigned to the knative service. It just needs to ensure that the label is short enough and does not contain "/".

[ksatzke]

as I have detected the bug during tests in the feature/GPU_support_extended branch with related PR upcoming soon I propose to fix it there.

[iakkus]

I think this is a bug that we can backport to develop. Did you check that change in? Because I haven't seen any differences regarding the workflow name sanitization in deployWorkflow.

[ksatzke]

The check for <63 chars is not yet checked in, the fix fo "/" character is.

[iakkus]

I think it might be better if we were to allow certain characters in a workflow name, so that we will not have to figure out another character that was not handled later on.

I'd suggest we just allow only alphanumeric characters in workflow names, but recently we had a similar issue regarding AWS compatibility with regards to state names. Could this be a problem in that regard?

[ksatzke]

The problem originates from the naming conventions and limitations defined in Kubernetes: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/identifiers.md#identifiers-and-names-in-kubernetes rfc1035/rfc1123 label (DNS_LABEL): An alphanumeric (a-z, and 0-9) string, with a maximum length of 63 characters, with the '-' character allowed anywhere except the first or last character, suitable for use as a hostname or segment in a domain name in fact k8s adapts To my knowledge we do not provide checks on label names in our current KNIX in a systematic way (at least I did not see it). So, if we want to make KNIX bullet-proof in that regard, we need to check any label in K8S/KNative following the DNS name convention above. BR Klaus From: Istemi Ekin Akkus <[email protected]> Sent: Friday, October 9, 2020 12:02 PM To: knix-microfunctions/knix <[email protected]> Cc: Satzke, Klaus (Nokia - DE/Stuttgart) <[email protected]>; Assign <[email protected]> Subject: Re: [knix-microfunctions/knix] invalid knative deployments when using SDK functions to upload workflows (#86) I think it might be better if we were to allow certain characters in a workflow name, so that we will not have to figure out another character that was not handled later on. I'd suggest we just allow only alphanumeric characters in workflow names, but recently we had a similar issue regarding AWS compatibility with regards to state names. Could this be a problem in that regard? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#86 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADFTJENHXSBT6L4VGOGS6ELSJ3NQ3ANCNFSM4SF6VVMQ>.

[ksatzke]

By now I think this is an issue which should better be treated and fixed in develop branch, as you initially proposed. Let’s discuss during today’s meeting. BR Klaus From: Istemi Ekin Akkus <[email protected]> Sent: Friday, October 9, 2020 12:02 PM To: knix-microfunctions/knix <[email protected]> Cc: Satzke, Klaus (Nokia - DE/Stuttgart) <[email protected]>; Assign <[email protected]> Subject: Re: [knix-microfunctions/knix] invalid knative deployments when using SDK functions to upload workflows (#86) I think it might be better if we were to allow certain characters in a workflow name, so that we will not have to figure out another character that was not handled later on. I'd suggest we just allow only alphanumeric characters in workflow names, but recently we had a similar issue regarding AWS compatibility with regards to state names. Could this be a problem in that regard? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#86 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADFTJENHXSBT6L4VGOGS6ELSJ3NQ3ANCNFSM4SF6VVMQ>.