Not managed by BSF box should not update

[gui1117]

because a box that is not configured in ideascube should not update as it can break if device_fact definition changes.

I don't know precisely what managed_by_bsf means but I think we can use this argument to disable update process if not set.

[bochecha]

As far as I know, "not managed by BSF" means we don't copy the BSF folks's SSH keys to the ideascube user's ~/.ssh/authorized_keys.

My Koombook at home, installed with Ansiblecube, is not managed by BSF, and I very much want it to be updated. 😉

I think you probably want a "do not update" switch instead, rather than piggy-backing on an unrelated switch.

[gui1117]

I think this is related to the configuration file issue. if you use a configuration that is not in ideascube nor ansiblecube you should not update the machine as it can break it.

[bochecha]

if you use a configuration that is not in ideascube nor ansiblecube you should not update the machine as it can break it.

And I think you're trying too hard to link two unrelated things.

Really, a "do not update" option in Ansiblecube would solve your problem, without abusing an existing setting.

In fact, we already have something: https://github.com/ideascube/ansiblecube/blob/oneUpdateFile/roles/ideascube/tasks/ideascube.yml#L62

Maybe that could be extended, so that the value is either read globally (as it is now) or from the fact file?

[letompouce]

This is the RED BUTTON for when somethign screwed up ideascube side.

I agree with @bochecha here, managed_by_bsf means we manage the device so we need our SSH keys and a VPN link. Completely unrelated to the upgrade process.

I would close this ticket as invalid and create a Option switch to freeze any upgrades issue.

[gui1117]

I understand managed_by_bsf is not related to configuration but only to SSH and VPN things.

But what I don't understand is the way you want to use device_list.fact
does you want to keep in the long term the fact that user can use a device name that correspond to an entry in device_list.fact ?

I propose a parameter own_config_file where if set then ansiblecube doesn't manage its configuration and so disallow update because update can break configuration or update the configuration also. (but I think the usual way is to only have minor update that a compatible with the configuration)

if not set then the hostname must correspond to a configuration in ansiblecube

I am not in favor of an option to freeze update because it is not the goal. the user doesn't want to freeze update, he wants to have its own configuration.

[bochecha]

if set then ansiblecube doesn't manage its configuration and so disallow update because update can break configuration or update the configuration also.

It shouldn't, though.

the user doesn't want to freeze update, he wants to have its own configuration.

Then why would you prevent updates?

[gui1117]

It shouldn't, though

this happened in the past deliberately

device_fact definition is not backward compatible so a user defined device_fact can break (for example at this commit: 4cd67a84)

[bochecha]

this happened in the past deliberately

Oh, right, things like splitting the cards... Sorry about that.

device_fact definition is not backward compatible so a user defined device_fact

But users shouldn't define device_fact.

Let's put this differently: how does pibox-installer drive ansiblecube? How does it provide ansiblecube the variables for the box it is making?

[gui1117]

first without talking about pibox-installer:

using buildMyCube.sh if the name I provide is not in ansiblecube configuration then it ask for content
https://github.com/ideascube/ansiblecube/blob/oneUpdateFile/buildMyCube.sh#L354-L359
https://github.com/ideascube/ansiblecube/blob/oneUpdateFile/buildMyCube.sh#L413
and write device_list.fact with the content I chose:
https://github.com/ideascube/ansiblecube/blob/oneUpdateFile/buildMyCube.sh#L170-L208

this device_list.fact is not handle by ansiblecube in update (it could be however but this would require to update the configuration on things like splitting the cards)

pibox-installer rewrite buildmycube.sh in python because it is more easy than interacting with TUI through python. but theoritically pibox-installer could use buildmycube.sh

[bochecha]

pibox-installer rewrite buildmycube.sh in python because it is more easy than interacting with TUI through python

And because it was a good thing to do anyway. 😄

I keep thinking what you need is to pass a new "do not update ideascube" variable to ansiblecube, the same way you already pass other variables, and teach ansiblecube to respect it.

And again, there's already one, which, as Tom mentioned is the nuclear option we used when Ideascube releases were broken (it happens less and less, we got better at this), and I think you could just use it.

I really don't understand why you'd need anything else, to be honest.

[gui1117]

I'm OK with an option to disable update but what I say is that a box created with this command:
./buildMyCube.sh -n my_box -t Africa/Dakar -m false (from the doc)
or this one: ./buildMyCube.sh -n my_box
will break on update

[bochecha]

Yeah, so one thing to keep in mind is that ansiblecube works for what it was designed: deploying and managing the BSF boxes.

It's not really a surprise that it doesn't handle as well other use cases.

And since you're the first one who tries to reuse ansiblecube for something else, you're the one having a hard time.

But thank you for doing this, because once ansiblecube works well for you, then it will be less BSF-specific and more generally reusable. 👍

---

As for the whole config files situation in Ideascube, that's also unfortunate. Honestly the problem is just so much bigger than breaking existing config files when updating. It really is a swamp we need to drain.

Eventually we'll get there.

[fheslouin]

I propose a parameter own_config_file where

I'm using it here : https://github.com/ideascube/ansiblecube/blob/oneUpdateFile/roles/set_custom_fact/tasks/main.yml#L18-L26 and there : https://github.com/ideascube/ansiblecube/blob/oneUpdateFile/roles/set_custom_fact/tasks/main.yml#L32-L38

if not set then the hostname must correspond to a configuration in ansiblecube

It is the case currently. If the hostname is not found in device_list.fact, the end user is asked to create is own device_list.fact file. buildMyCube.sh does help with few dialog box.

this one: ./buildMyCube.sh -n my_box
will break on update

You mean that on update tag the content of device_list.fact is emptied ? It should not be the case and if so, please report the issue