documentation is missing key details for non programers

[cah-roger-bauer]

in the event the scripts do not function following the instructions here will create public and private keys,

https://www.howtogeek.com/762863/how-to-generate-ssh-keys-in-windows-10-and-windows-11/

Go to the vm instance, edit , and add the public key. this will allow you to ssh using the -i command to call ~/.ssh/id_rsa and to troubleshoot why the scripts didnt complete. It appears that windows 10, is dependent on the -i and windows 11 sets the id_rsa to the default. Once the scripts are functioning properly, renaming the id_rsa will properly prompt for password.

For GCP the command : google_metadata_script_runner --script-type startup --debug execute the startup script so you can watch for errors and troubleshoot.

• • there are difference in cloud commands and syntax. better regression testing is need - and differences should be called out if its not going to work.

the basic process should be better explained.

The scripts build a generic instance however some components do not function as expected, and you can get lost troubleshooting.
I.E - a quick login will show proper interfaces eth0 eth1 etc. however all disappear except mgmt which will reside on eth0 ifconfig <---check mac addresses and compare. the best practice recommendation is to move the mgmt interface from eth0 to eth1, and this is done if the scripts execute properly , it takes 3-5 minutes as the instance will reboot . This can be moved to eth2 or other interface as needed. This will also generate an anomaly that results in show net interface providing a large quantity of errors on the mgmt interface.

currently this is undocumented (numbered ) bug, it is my belief its related to mgmt being set to 100mb settings vs. letting it just detect like other interfaces. also - these numbers can not be reset with cli commands. all working GCP ve's exhibit this bug. A ping flood of over a million packets in ~3 minutes from 1 mgmt interface to another did not drop a single packet, this appears to be cosmetic.

i.e. after the instance (shell) is built, and the mgmt interface is alive, you see all interfaces 20 seconds after mgmt allows login, however 90 seconds later all other interfaces eth0, eth2 .... will disappear technically there according to the cloud but not according to ifconfig. Once the vlan commands add the interfaces 1.0 1.1 etc... the interfaces will show up properly. this can be done in either the startup-script or in the DO scripts., keeping in mind the DO scripts are called from startup..

I strongly encourage a change in the thought process for disk allocations, disk size is tied to performance and is available at a trivial cost. We are spending $$$$$ to have f5 do the magic it does, allocating $10 per month to have triple the disk capacity makes more sense then having a sub 100GB image. None of the documentation specifically calls out, if you run LTM you need X, if you run LTM and APM you need Y, and it you run need Z disk capacity. This is a common pit fall for ASM deployments.. You have to dig long and hard but you can find the documentation with the following information:

• ASM does not "log" its WAF logs into /var/log/asm file
• ASM WAF logs go into the database, /var/log/asm = is used for the health of asm.
• The result of using ASM will be the database will swell the /var mount point ( different mount point from /var/log) until it runs out of space.
• once the /var runs out of space, you will not be able to store a single copy of a UCS in the default folder /var/local/ucs and or a SCF file if you use those in /var/local/scf.
• fun fact - the database can grow to 5GB, this is not adjustable - too little space - it allows the filesystem to go to 0, allocate 20 GB extra, it will prune to 5gb.
• Also ATM - WAF logs are not able to utilize HSL, and is dependent on a syslog configuration, performance, and limitations. Unless this is corrected in the base image, it I would recommend setting these in the startup-script, so they catch the reboot during nic swap, and you know they are ready for provisioning.

A helpful bit of advice would be to trouble shoot the onboard script by checking the file and folder structure.

In the README.md: in the custom user and metatdate area:

• modules? how did you get here, where do you configure it ? how is it linked.?
• example 4 appears to have some syntax issues: extra "s" on the module line and is missing the open brace, count has vas. should be var

With 5 examples of the deployments, there is no documentation of what runtime init is , why we need it, and kind of looks like its only needed for 1nic deployments. Also - what is changing from 1-2-3-4 nics, can this be summerized with If you need more NIC in any of: *( 1 nic deployment) mgmt_subnet_ids <---- is default config refrenced in output and variables tf files ( 2 nic deplloyment) copy and modify mgmt_subnet_ids to a new variable either internal_subnet_ids or external_subnet_ids (3 nic + deployments, either copy and modify mgmt_subnet_ids to a new variable name OR inside the [ square braces] copy from { to } add a comma and make sure it closes with the squire brace ending.

[trinaths]

Created INFRAANO-608 for internal tracking

[RavinderReddyF5]

@cah-roger-bauer did you try providing f5_ssh_publickey input to module by specifying windows ssh public key path?

[KrithikaChidambaram]

This was included in v1.1.2, closing this now, thanks!