[tor-bugs] #31957 [Internal Services/Tor Sysadmin Team]: automate upgrades

[Tor Bug Tracker & Wiki]

#31957: automate upgrades
-------------------------------------------------+-------------------------
 Reporter:  anarcat                              |          Owner:  hiro
     Type:  project                              |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:
Component:  Internal Services/Tor Sysadmin Team  |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tpa-roadmap-february                 |  Actual Points:
Parent ID:                                       |         Points:  0.5
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by anarcat):

 * status:  needs_review => assigned
 * owner:  anarcat => hiro


Comment:

 > I have pushed a new branch addressing all your comments: unattended-
 upgrades.

 it seems we now have three branches for this... i think it would have been
 preferable to force-push to the topic branch instead of creating new
 ones... please do cleanup the old ones to leave only the current one.

 after you merge, do remove the good branch as well, of course. :)

 now as for the review of the `unattended-upgrades` branch...

 I don't think this is necessary:

 {{{
 +# a host that is monitored
 +class roles::unattended_upgrades {
 +  include profile::unattended_upgrades
 +}
 }}}

 we don't need a role at all, we can include the profile in the relevant
 roles. for example, this:

 {{{
 --- a/hiera/nodes/chives.torproject.org.yaml
 +++ b/hiera/nodes/chives.torproject.org.yaml
 @@ -1,2 +1,3 @@
  classes:
    - roles::ircbox
 +  - roles::unattended_upgrades
 }}}

 ... could be turned into an `include profile::unattended_upgrades` inside
 the `roles::ircbox`.

 that said, that's how the progressive deployment docs look right now, so I
 can't really blame you for following it. :)

 anyways this looks good and I'd say go ahead with it. you are correctly
 including the functionality only in one node in that way, that's the
 important part to get right and it looks like you've done it. :)

 (if you're curious about why i'm now hesitant in adding roles to hiera
 there: it's because those classes get added as prometheus labels which
 creates needless noise in the prometheus time series and confuses
 grafana...)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31957#comment:15>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online