Support for hot-pluggable wifi interfaces

[layereight]

• 2 optional configs for interfaces_ether_interfaces
  • allowclass: anything other than 'auto'
  • wpa-conf: wpa_supplicant configuration
• add "--allow auto" flag to ifup/ifdown to only bounce 'auto' interfaces

[layereight]

@markgoddard BTW, could you trigger a reimport of the project in ansible galaxy? You can also automate this with a Travis notification. See http://docs.ansible.com/ansible/latest/galaxy.html#travis-integrations

Maybe introducing tags for versioning releases is also a good idea. So people can explicitly stick to a certain version and upgrade the role in their playbooks when they feel like it.

[markgoddard]

@layereight I've not needed to do a reimport - galaxy seems to pick up the new code automatically. I'll look into it in case I've just been lucky in my timing.

@michaelrigart what do you think about versioning?

[layereight]

@markgoddard https://galaxy.ansible.com/MichaelRigart/interfaces/ shows me last successful import was 10 month ago (or am I looking at the wrong role). Please compare with the imports from my fork: https://galaxy.ansible.com/layereight/interfaces/

You can also see that galaxy picks up the tags from the repos as version. In my playbook I have a roles.yml pointing the roles to a specific version:

  - name: layereight.interfaces
    src: layereight.interfaces
    version: "1.6"

To install the roles I do:

$ ansible-galaxy install -r roles.yml

See http://docs.ansible.com/ansible/latest/galaxy.html#installing-multiple-roles-from-a-file

[markgoddard]

@layereight the main project in which I use this role is https://github.com/stackhpc/kayobe, where I have a requirements.yml file like your roles.yml. I tend to omit the version, and pull down the latest:

- src: MichaelRigart.interfaces

This seems to always pull down the master branch from github, despite the lack of imports on galaxy, perhaps because there are no tags.

Let's see what @michaelrigart says re versioning - I can see the benefit of being able to specify a version but it does add a little maintenance overhead.

[layereight]

@markgoddard Thanks! I appreciate your consideration.

[michaelrigart]

@markgoddard @layereight

Versioning sounds like a good plan. I just re-imported the repo in galaxy. Any thoughts on versioning schema, without creating too much overhead ( 'major'.'minor'.'bugfix' ) ?

[markgoddard]

Yeah, https://semver.org/ seems like the way to go.

[markgoddard]

@michaelrigart I think you would need to setup the travis notification as it's your account.

[layereight]

@michaelrigart Nice, thanks!

The good thing about versioning schemas is that there are so many you can choose from. ;-) I usually keep it simple. 'major'.'minor'.'bugfix' is totally fine. Important thing is that you have versioning. The big advantage for people is that they can stick to a version and then adapt to a new version (with a change potentially breaking their playbook) at their own pace.

[michaelrigart]

@markgoddard : what kind of notifications do you mean? Aren't notifications configured through the travis-ci.yml file?

[markgoddard]

@michaelrigart yes they are - http://docs.ansible.com/ansible/latest/galaxy.html#travis-integrations. I think it requires the role owner's account to generate an appropriate token for the notification to use though.

[michaelrigart]

@markgoddard : ok, integration should be ready. Can you try adding the notification entry in the yml?

Added integration for travis michaelrigart/ansible-role-interfaces

[layereight]

@michaelrigart Btw, are you going to merge my PR? The whole versioning stuff was just a side discussion. ;-)

[michaelrigart]

@markgoddard @layereight I'm going to open an issue tomorrow regarding the versioning request.

[layereight]

@michaelrigart Cool, thanks!