Record arch

[jvonau]

Avoid expanding scripts/local_facts.fact which should shrink in coming years, rather than expanding — to reduce the number of global variables (in favor of modular-not-monolithic code, whenever possible).

Should meet the above requirement, just record the value so it can be easily displayed in the admin-console

[holta]

Both dpkg --print-architecture and dpkg --print-foreign-architectures are already recorded in iiab-summary and iiab-diagnostics output.

Are they also needing to be recorded during IIAB's initial Ansible install, is that the idea?

If so, that seems reasonable.

(0-init/tasks/create_iiab_ini.yml might then spell that out clarifying a bit in /etc/iiab/iiab.ini ...maybe something like option: original_dpkg_arch or option: initial_dpkg_arch or some such?)

[holta]

(0-init/tasks/create_iiab_ini.yml might then spell that out clarifying a bit in /etc/iiab/iiab.ini ...maybe something like option: original_dpkg_arch or option: initial_dpkg_arch or some such?)

Or maybe the section: version and section: location sections within /etc/iiab/iiab.ini are both sufficiently static already (implying these 2 sections created by create_iiab_ini.yml are not supposed to ever change ?)

[jvonau]

(0-init/tasks/create_iiab_ini.yml might then spell that out clarifying a bit in /etc/iiab/iiab.ini ...maybe something like option: original_dpkg_arch or option: initial_dpkg_arch or some such?)

Or maybe the section: version and section: location sections within /etc/iiab/iiab.ini are both sufficiently static already (implying these 2 sections created by create_iiab_ini.yml are not supposed to ever change ?)

You should know the purpose and reasons for the layout that was 'borrowed' from xsce but to spell it out for you the reason is to capture the install time variables that were in play at install time. Remember 'runtime' is updated every time ansible runs, it looks like a duplication but as you now realize create_iiab_ini.yml only runs once. Using 'original' or 'initial' really doesn't gain anything other that being a nit picker, should never change without willful alteration and that is the purpose of recording the value. (Thinking towards apt repo additions that are not correct for the arch in use and how that came into being) Now with this 'Avoid expanding scripts/local_facts.fact', all #3518 was doing was the same procedure that was used with #3439 as I felt this variable would of come in handy for other roles that might need attention going forward. What I find amusing is this 'to reduce the number of global variables' cope out, default_vars.yml and local_vars.yml are full of 'global variables'.

[holta]

Sure.

But those 2 section titles should really be...something like section: initial-location and section: initial-version if we want other people to understand our work.

[jvonau]

Now if you want to add --print-foreign-architectures also that would be cool too. While partially a duplication of iiab-summary but that is a post-install tool that would not capture the 'out of the box' pre-iiab environment that might be altered in some unknown way. Just recording the known starting point, just like any other values that are recorded in the same stanza that should not change without willful intervention.

Sure.

But those 2 section titles should really be...something like section: initial-location and section: initial-version if we want other people to understand our work.

Just a header change feel free.

[holta]

Now if you want to add --print-foreign-architectures also that would be cool too. While partially a duplication of iiab-summary but that is a post-install tool that would not capture the 'out of the box'

Ok

[jvonau]

'ansible_distribution' might be better with 'os_ver' ?

[holta]

'ansible_distribution' might be better with 'os_ver' ?

FWIW after Ansible 2.6+ they ask us not to use ansible_distribution — for whatever reason, one is supposed to use ansible_facts['distribution'] instead:

https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_conditionals.html#ansible-facts-distribution

• test.yml: Document ansible_local.local_facts, ansible_architecture etc #3237 (comment)

[jvonau]

os_ver matches the form of other entries in create_iiab_ini.yml, this is internal information, should match the detection in use and helps explain OS.yml usage.

[jvonau]

Grouping: Move to be under dpkg_foreign_arch?

[jvonau]

Looks fine to me, run with it.