Changes between Version 1 and Version 2 of Development/YumAndSPMA


Ignore:
Timestamp:
Aug 29, 2012, 3:38:42 AM (13 years ago)
Author:
munoz
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Development/YumAndSPMA

    v1 v2  
    77This document describes the internals of the integration of Yum and SPMA. User documentation will be provided in Github pages.
    88
    9 The main priority is to make the transition as smooth as possible for users. În the first stage, all changes are on the client side. This means *no changes to any Pan schemas*. In the second phase, some schemas may add fields for the user's benefit, but it *should* be backwards-compatible.
     9The main priority is to make the transition as smooth as possible for users. În the first stage, all changes are on the client side. This means '''no changes to any Pan schemas'''. In the second phase, some schemas may add fields for the user's benefit, but it '''should''' be backwards-compatible.
    1010
    11 Whatever changes we do to SPMA schema or internals, we *must* port them into AII, which is going to be time consuming.
     11Whatever changes we do to SPMA schema or internals, we '''must''' port them into AII, which is going to be time consuming.
    1212
    1313=== What `ncm-spma` does ===
    … …  
    4343
    4444Users willing to go back to the previous behaviour can just downgrade ncm-spma, and it will just work.
     45
     46=== Future work: reverting to a previous state ===
     47
     48The only drawback is reverting to a previous state. Imagine that you deployed tag `a`, which introduced dependency `x-1.2`. Then, tag `n+1` upgrades `x` to `1.4`. For watever reasons, you redeploy `a`, and all the configuration is replayed. But `x` is still in `1.4`, when we expected `1.2`!!.
     49
     50To solve this, we'll make use of the Yum `history` feature. We'll store in a file the deployed tags, and associate them with a transaction ID. If `ncm-spma` finds that the tag had already been deployed, it will just undo all the subsequent transactions!
     51
     52The map of tags to transactions can be stored in a JSON file, since it's expected to be small (a few hundreds of transaction at most). Something like this:
     53
     54{{{
     55#!text/x-javascript
     56{
     57    "2012/04/13-00:01:02" : 74,
     58    "2012/05/06-00:01:02" : 75,
     59}
     60}}}
     61
     62'''Question:''' Which portion of the profile contains this tags? At UGent, we use `/system/quattorid`.
     63
     64'''Note:''' This feature requires Yum 3.2.29, which is not shipped (but can be built) on SL5.