generic project name not robust to all user input

[gui1117]

I thing that if a user use a hostname that correspond with a BSF machine but launch with managed_by_bsf to False there is still issue.

the following rule detect a bsf conf file. we should add to the conditional the managed_by_bsf parameter.
https://github.com/ideascube/ansiblecube/blob/oneUpdateFile/roles/ideascube/tasks/ideascube.yml#L76-L79

I think this part may be wrong and reworked

[gui1117]

If you agree that a box not managed by BSF should not use a conf in ideascube then I implement this

otherwise we should create a parameter.

[bochecha]

the following rule detect a bsf conf file

No it doesn't. It detects an Ideascube configuration file named after the box.

That's not specific to BSF at all, it's how Ideascube is supposed to be configured at the moment. (yes, that's unfortunate, but it's what we have to work with, until we eventually change all that and make it much saner)

[fheslouin]

As @bochecha pointed it out, https://github.com/ideascube/ansiblecube/blob/oneUpdateFile/roles/ideascube/tasks/ideascube.yml#L76-L79 is there only to verify if an ideascube configuration file exist regarding the ansiblecube hostname. If no file is found, it fall-back on generic configuration file for ideasbox and koombook

[bochecha]

If no file is found, it fall-back on generic configuration file for ideasbox and koombook

@fheslouin do you think that maybe what @thiolliere needs is to add a third type of fallback for his pibox?

[fheslouin]

@fheslouin do you think that maybe what @thiolliere needs is to add a third type of fallback for his pibox?

If the fall-back configuration file does not fit the needs, we can create an ideascube configuration file matching the needs of @thiolliere then add a test case in ideascube.yml to fall back to it on a given hostname.