Bug 1688672

I checked with Tina and we think this is working as designed.

I can understand the confusion, but this is currently working as designed.

The naming code checks for the first available suffix based on the prefix, and the number of digits specified.
In this case with $n(1) specified, it used 1 - 9, then found the first available 2 digit suffix which is 01.  Based on this, it's possible the next number after 9 could be anywhere up to 99, depending on the starting number for $n(2).

Hi Gellert,

Can I close this ticket?

Thanks,
Tina

I have spent some time thinking about this topic recently and posted the follow proof-of-concept PR to further the discussion.

Gellert/Ian/Loic - I welcome comments/suggestions on how to move forward with this topic.

https://github.com/ManageIQ/manageiq/pull/18590

@Greg, I don't get what the -1 refers to or what would be other values passed in its place, but I like that it works. What were yout hinking if somsone passes in a value other then -1, such as 0,1,2,3, etc?

The -1 value was just a proof-of-concept that we could parse out control parameters and still enumerate on the same naming sequence.  Meaning "$n{3}" and "$n{3, -1}" would end up using the same enumeration counter on the region.

Otherwise, I put the PR out there to ask for suggestions.  How would you want to specify that you want to use a different naming pattern?  Ignoring the PR I created.

Would we use named algorithms?
  For example, "$n{3, zero-padded}"

What other concepts or best practices could be used here?

This opens up the ability to extend the available naming patterns.  I recall seeing an RFE a long time ago asking to use hex values in the name, which could be another possible naming algorithms that gets implemented.

I will note that these changes create the undesirable side effect that we could generate duplicate names and I still need to determine if there is a solution for this.

Based on the current PR "$n{1, -1}" and "$n{2}" would overlap once the enumeration value was over 9.
"$n{1, -1}" : machine8,  machine9,  machine10
"$n{2}"     : machine08, machine09, machine10

It is a timing issue, but if provision1 uses "$n{1, -1}" and selects "machine10" because it does not exist, a second provision task could use "$n{2}" and also potentially select "machine10" if the VM name from provision1 does not exist in the database yet.

This is why you see the behavior with the existing code today.  We bump the "padding" value to ensure that the returned numbers is always unique within the region.  So when we increase from 1 to 2 digits we increase the padding value to ensure any task requesting a two digit name is guaranteed to get a unique value.  By forcing the padding to stay 1 we lose that guarantee.

I like it. But I am one voice.

Loic, Gellert - Any thoughts on the information I supplied in comment #15?

All - My comment above was asking for advice/suggestions on what you would want to see implemented.  Based on comment #9 I would expect/welcome more feedback.

Hi Greg,

Can we discuss?

Thanks,
Tina

When implementing, need to clearly articulate in release notes the change in behavior. If possible, provide a configuration option to enable the old behavior for customers relying on it.

Hi Peter,

Can we discuss?

Thanks,
Tina

Hi Tina, sorry I missed this. Sure, happy to discuss.

See https://github.com/ManageIQ/manageiq/issues/19756

Created attachment 1677033 [details]
Automate Domain for Custom vm provisioning naming changes