I want to generate a unique identifier of a specific length and use this value across multiple pods internally. Since the length must be specific, and I'd prefer this to be handled internally rather than be adjustable by a user, I'd prefer to create the unique identifier on install/upgrade (only once if has not been set already) and not be changeable.
I want to use the identifiers internally as part of a naming schema for objects created within a specific deployment. I want to share these objects across other deployments, and need the identifier to determine if a given object belongs to a given deployment.
I was looking into setting a value in Secrets using randAlphaNum. Some problems I face with using Secrets are:
Related to this issue: https://github.com/helm/helm/issues/3053
It looks like the Secret value will be overwritten on upgrade. There is an open PR for a possible fix: https://github.com/helm/helm/pull/5290
But I don't have the ability to upgrade helm/kubernetes atm
Secret value is b64 encoded. I want to pass the value as an environment variable to various pods decoded. It doesn't really matter if the user knows the unique identifier. So, maybe I don't need a Secret? But, again, I don't want the user to be able to edit the value and the value should never change for a given deployment.
Any help or suggestions are appreciated! Thanks
You may then try to use ConfigMap instead. Seems it doesn't change on helm upgrade. Then you can use this guide to pass the value from ConfigMap to the pods.
Related
I'm trying to figure out the precise processing order for templates within Helm (v3.8.1 and newer). Specifically, I'm looking for the order in which individual files are processed - if any.
I'm trying to figure out the best means to render some common-use values based on child charts' values. I have some subcharts that will need to interoperate, and I'm aware of the availability of the "global" map in order to publish values consumable by all charts. I've not tested modifying the contents of "global" programmatically, but I expect this should be possible.
Regardless, what I'm getting at is that using static variables defined in values.yaml (global, specifically, or even subcharts' value overrides) may not be enough in order to achieve the interoperation I need for all of these subcharts.
Specifically, I would like for each subchart, as it's processed, to compute specific values that could be consumed for interoperation and then publish them to the "global" map (i.e. global.subchart1.someValue, global.subchart2.someOtherValue, etc).
For instance: one of my subcharts is an LDAP provider, but an external LDAP could also be used, so the LDAP URL is something that needs to be "computed" to either be the external one (manually-specified), or the internal component's one.
This type of modification would allow me to consume those values (if available) wherever interoperation is required, via a single source of truth.
I'm looking for something like this:
Parse the top-level chart's Chart.yaml
Parse and process the top-level chart's non-template files (_* files)
Repeat the prior two steps for all subcharts, recursively
Parse the top-level chart's values.yaml
Parse and process/render the top-level chart's remaining template files
Repeat the prior two steps for all subcharts, recursively
Ideally, also including the order in which files are processed (I'm currently presuming they're processed alphabetically).
I realize this is probably not the ideal scenario, but I do want the ability for each subchart to be able to export information akin to "my service is exported on this port, with this user and password" (yes, I'm aware that secrets would likely be required here, etc...), or "this is the search DN for the LDAP users", etc.
I have several variable groups defined under Pipeline Library. I'm using a different group for each release environment (e.g., DEV, QA, PROD). The deployment for each environment needs all the same variables but with different values.
It's a long list of variables and I have no way to tell if my groups are getting out of sync with one another over time as we add and remove variables.
I really wish I had something like a C# interface to make all the groups match. I was hoping the new YAML templates could help somehow but I can't find anything that would solve this.
Anyone have a good solution to this? It seems like a very common use of variable groups.
Can I enforce the same variables across variable groups in the Azure
DevOps Pipeline Library?
No, we can't do that. It seems what you want is to sync the variable groups for DEV,QA,PROD environments, making these groups have same variable list but different values.
As I know this is not supported for now. Variable groups is originally designed to share variables across pipelines instead of other directions, so Azure Devops Service doesn't support such out-of-box feature to compare and sync variable groups.
Update1:
I submitted a feature request in User Voice forum that you can vote and track.
Update2:
1.Another direction if you want to check the variable list easily: If you want to check the variable list manually, you can consider using Rest API to get a Json response of your variable list for one specific variable group.
2.There're many related topics about how to convert Json to CSV/Excel file online, and after my test it's quite convenient. So maybe you can get three josn response and then convert then into text file/excel file to compare the difference between these three variable lists. It could be a temporary workaround ~
Hope it helps :)
I am trying to figure out which are the main default attributes of agents in Anylogic, e.g., the Id, the position and the index. So far I haven't found them in the help or at stackoverflow.
1) Do you know where this can be found or can you summarize the main you know? For instance the id used as unique identifier or the index used as the position inside of the population.
2) Are there any attributes regarding the agent history? For example time stamps as the creation time or the blocks it has passed through?
3) Is it possible to change the default id attribute of an agent? Can two agents have the same id?
4) As the split block doesn't copy any of the parameters or variables values to the copy, what is the proper way to copy an agent? I noticed in other publication Benjamin mentioned using agent.set_MyParam(original.MyParam). What would be "MyParam" in this code? Would this copy the value of parameters, variables and the current state in the statechart? Is it possible to make a copy and initialize its current state in the statechart as the original agent's current state?
Thank you for your help.
There are many things that are generated when you generate an agent... the best you can do is to check the api for the agent here: agent api
You can only see these things on the log if you activate it, but not from the API
the id is a unique identifier and i've never been in a situation where i need to change it,but if you want to change it, you can use the setId method, in which case, 2 or more agents may have the same id.
you can only use set_MyParam if the MyParam is a parameter, you can't do the same with variables. Nevertheless, if you want to copy an agent, you need to do it variable by variable, state by state, everything from scratch. There's no magical way to copy the exact same agent with all its current values and states and connections etc
I am on Enterprise Architect 13.5, creating a deployment diagram. I am defining our servers as nodes, and using attributes on them so that I can specify their details, such as Disk Controller = RAID 5 or Disks = 4 x 80 GB.
When dragging instances of these nodes onto a diagram, I can select "Set Run State" on them and set values for all attributes I have defined - just like it is done in the deployment diagram in the EAExample project:
Since our design will have several servers using the same configuration, my plan was to use the "initial value" column in the attribute definition on the node to specify the default configuration so that all instances I create automatically come up with reasonable values, and when the default changes, I would only change the Initial Values on the original node instead of having to go to all instances:
My problem is that even though I define initial values, all instances I create do not show any values when I drag them onto the diagram. Only by setting the Run State on each instance, I can get them to show the values I want:
Is this expected behavior? Btw, I can reproduce the same using classes and instances of them, so this is not merely a deployment diagram issue.
Any ideas are greatly appreciated! I'm also thankful if you can describe a better way to achieve the same result with EA, in case I am doing it wrong.
What you could do is to either write a script to assist with it or even create an add-in to bring in more automation. Scripting is easier to implement but you need to run the script manually (which however can add the values in a batch for newly created diagram objects). Using an add-in could do this on element creation if you hook to EA_OnPostNewElement.
What you need to do is to first get the classifier of the object. Using
Repository.GetElementByID(object.ClassifierID)
will return that. You then can check the attributes of that class and make a list of those with an initial value. Finally you add the run states of the object by assigning object.RunState with a crude string. E.g. for a != 33 it would be
#VAR;Variable=a;Value=33;Op=!=;#ENDVAR;
Just join as many as you need for multiple run states.
I'm testing with a kubernetes cluster, and it's been marvelous to work with. But I got the following scenario:
I need to pass to each pod a custom value(s) just for that pod.
Let's say, I got deployment 1, and I define some env vars to that deployment, the env vars will go to each pod and that's good, but what I need is to send custom values that may go to a specific pod(like "to the third pod that I may create, send this").
This is what I got now:
Then, what I need is something like this:
Is there any artifact/feature I could use? It does not have to be an env var, it may be a configmap value, or anything. thanks in advance
Pods in a deployment are homogenous. If you want to set up a set of pods that are distinct from one another, you might want to use StatefulSet, which gives each pod an index you could use within the pod to select relevant config params
The real question here is how do you know what you want to put in particular pod in the first place. You could probably achieve something like this writing a custom initialiser for your pods. You could also have an init container prefetching information from central coordinator. To propose a solution, you need to figure it out in a "not a snowflake" way.