Ticket #159 (new)

Opened 10 years ago

Last modified 3 years ago

Seznam verzij imageov

Reported by: mitar Owned by: kostko
Priority: major Milestone: 3.0b
Component: nodewatcher/modules Version:
Keywords: Cc:
Related nodes: Realization state:
Blocking: 123, 161, 1022 Effort: normal
Blocked by: 1134 Security sensitive: no

Description (last modified by mitar) (diff)

Seznam verzij imageov (vsebin /etc/version datoteke). Torej vsakič, ko se rebuildajo generatorji, se doda na ta seznam ta nova verzija. In se označi vsaka verzija s stopnjo pomembnosti nadgradnje (od predhodne), recimo:

  • minor
  • major
  • critical
  • invalid (če je verzija z napako)

Ta seznam bi bil na strani z image generatorjem nekje dostopen (tudi z datumi, kdaj so te verzije prišle na voljo), tako da je uporabnikom bolj jasno, kaj imajo in če je pomembno, da točko nadgradijo.

Lahko se doda pri vsaki verziji seznam povezav na changesete na spletno stran, glede na to, da je enostavno ugotoviti, katere revizije so bile med prejšnjo in to novo verzijo.

Change History

comment:1 Changed 10 years ago by mitar

Povezano s #158.

comment:2 Changed 10 years ago by mitar

  • Blocking set to 161

comment:3 Changed 10 years ago by kostko

Podobno kot pri #158 je potrebno te podatke nekako dodati v bazo. Rebuild image generatorjev je trenutno povsem neodvisen od celotnega sistema - gre samo za zamenjavo direktorijev - tako da bi morali nekako vnašati te podatke v bazo.

comment:4 Changed 10 years ago by mitar

Nekaj bi bilo potrebno v vsakem primeru vnašati v bazo - namreč katere pomembnosti so katere verzije. Torej če se to vnaša v bazo, potem se mora le še uskladiti, da v trenutku, ko je res na voljo nova verzija, da se komaj ta pokaže.

Verjetno bi bilo najlažje to urediti tako, da se to vse ureja na enem mestu. Recimo da bi sistem sam lahko listal tisti direktorij z generatorji in bi gledal, katere verzije so na voljo. In potem glede na to prikazal strani. Tam pa bi bila recimo še datoteka, ki bi povedala pomembnost verzije.

Ne vem, kako bi bilo to tebi najlažje narediti. Mogoče celo tako, da se lahko rebuild generatorjev sproži preko spletnega vmesnika (seveda le administratorji oziroma posebni uporabniki). In bi ta pri sprožanju rebuilda določil katere pomembnosti je rebuild. In tudi fiksirala bi se sama revizija, ki jo naj uporabi, da ne bi prišlo do neujemanja. (Lahko se to da v isti queue kot sedaj samo generiranje imageov.) In potem ko se bi generatorji pripravili, bi se to sporočilu sistemu in bi se nova verzija pokazala kot zadnja.

comment:5 in reply to: ↑ description Changed 10 years ago by mitar

Replying to mitar:

Lahko se doda pri vsaki verziji seznam povezav na changesete na spletno stran, glede na to, da je enostavno ugotoviti, katere revizije so bile med prejšnjo in to novo verzijo.

Tu bi bilo dobro vseeno omejiti seznam teh changesetov na tiste, ki spreminjajo sam direktorij s firmwareom v repozitoriju.

comment:6 Changed 9 years ago by mitar

  • Milestone set to 3.0b

comment:7 Changed 9 years ago by mitar

  • Blocking changed from 161 to 123, 161

(In #123) No. Prvo moramo narediti 2.0b in 2.0. To pomeni, da bi bilo dobro še malo potestirati samo skripto (da bo stable).

Bom dodal še en blocking ticket, da ne bo skušnjav. :-) Saj pomaga pri tem, kar si zgoraj napisal.

comment:8 Changed 9 years ago by mitar

  • Description modified (diff)

comment:9 Changed 7 years ago by mitar

  • Blocking changed from 123, 161 to 123, 161, 1022

comment:10 Changed 6 years ago by kostko

  • Component changed from image generator to nodewatcher/modules

Nodewatcher in 3.0b supports different firmware versions, but currently these are only current versions (there can be multiple active versions like stable and experimental).

Version history should be added as a module.

comment:11 Changed 6 years ago by mitar

I am not sure if history should be a module. Maybe. But we will have admin interface anyway for admins to release new versions (if we will have multiple versions) so to have also history is small addition. Isn't this all part of one module: the one which adds firmware generation itself to the nodewatcher?

So the ticket is not about having multiple concurrent releases (stable vs. experimental) but that for each new version we mark how important is to update to that version. The reason is that if people want to update or if we will have autoupdate, they will be able to decide or configure it. Like, I want that my node gets updated only for critical things.

But I do agree that we might even support multiple releases. So we have a stable release and experimental release. And we can at some point move a firmware from experimental to stable. But still, even then I would like to mark what this new firmware brings: just small updates or it is a critical security version.

Anyway, I am thinking also about one other aspect of versions: it would be sooo great to have a history on the node itself when did firmware updates occur and then have this even as a graph. And even have this as a bars (similar to reboot bars) on all the graphs displayed.

BTW, how hard would be to maintain a way to generate also past versions? At least one previous? So that people could reflash back and compare?

comment:12 Changed 5 years ago by mitar

  • Blocked by set to 1134

comment:13 Changed 3 years ago by mitar

What is the state of this idea? We have something, but I am not sure what exactly is current design? kostko, care to describe it?

comment:14 Changed 3 years ago by kostko

Currently, the versioning system works as follows. At the top level, there are build channels and one build channel is the default one. Each build channel can have multiple builders for multiple versions. The use for build channels is for example the split into "stable" and "experimental" builds, but these can be anything.

By default, the latest version (by creation date) of the default build channel is selected. But any node configuration may override both, the build channel and the exact version, so that it will use a specific version of the firmware.

The exact builder and version used is stored in the build result, so you can go back and get generated firmware images from previous versions.

When builders are removed, all old version information is lost.

comment:15 Changed 3 years ago by mitar

OK, but labeling multiple versions with "stable" and other flags we do not yet support? Or would that be then an additional module, which would add such labels and then also support auto-upgrade?

comment:16 Changed 3 years ago by kostko

As I said above, the build channel "stable" can have multiple versions under it. And they are all considered stable and you can request an explicit version in the node's configuration. By default the newest version is used.

comment:17 Changed 3 years ago by mitar

Aha, OK. So then we can later on have a module which automatically upgrades to the newest version of the channel you are tracking, for example. Cool.

Where is this list of versions and channels available? Do we have some special page listing all of those? With things like link to a GitHub changelog/commit, and date of it and so on?

comment:18 Changed 3 years ago by kostko

Where is this list of versions and channels available? Do we have some special page listing all of those? With things like link to a GitHub changelog/commit, and date of it and so on?

Currently this is only visible in the admin interface, there is an API, but there is no special page for this.

comment:19 Changed 3 years ago by mitar

OK, we should expose this to users somewhere. :-)

Note: See TracTickets for help on using tickets.