[Dextrose] [PATCH] Fix for bugs sl#2713 and au#885.

[Aleksey Lim]

On Wed, Sep 14, 2011 at 04:00:25PM +0530, Anish Mangal wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 09/13/2011 01:29 AM, Aleksey Lim wrote:
> > On Mon, Sep 12, 2011 at 12:35:17AM +0530, Ajay Garg wrote:
> >> Running the "dextrose-updater" cron.daily job, "touches" a "/var/lib/dextrose-updater" file. This file is then used in the subsequent run, to determine if it
> >> is ok to re-run the job. Effectively, the "last-touched-timestamp" value of "/var/lib/dextrose-updater" is made use of in the "dextrose-updater" job script.
> >>
> >> Used similar logic - used the "last-touched-time" as the time when the yum-updater was last run.
> >>
> >> Thanks to Anish, for some wonderful review feedback.
> > 
> > There are a couple of issues in the patch, but my concern is about
> > not having all hardcoded stuf (not only for dextrose but, eg, for OLPC's
> > XS) in shell code and relying only on command line API (the reason is
> > that this command might be called w/o shell's UI at all and might have
> > quite different release schedule in comapring w/ shell).
> > 
> > In other words, it will be useful to:
> > 
> > * rehash such code in Dextrose patch (for updater and school server backups)
> > * rehash XS related code
> > * create a Feature/ page on SL wiki for such refactoring/adding-new-code
> > * in Feature's code, use sugar-client[1] command line API to all
> >   interactions with [school] server (and hide such UI if sugar-client
> >   command doesn't exist)
> > 
> > [1] http://wiki.sugarlabs.org/go/Sugar_Server_Kit/sugar-client
> > 
> 
> Ajay, Perhaps we could simply use the 'yum history' command here. It would:
> * Make the patch not depend on dextrose-updater
> * Not do too many things in shell (except invoke yum history)
> * yum is a critical and mature fedora component. It won't be too
> volatile in terms of compatibility IMHO
> 
> Aleksey, I didn't fully understand your comment. In part, how is this
> related to XS, particularly, the server side (maybe you're implying
> sugar-client side here, but I'm not sure if that is ready to be included
> in dx3 yet?).
> 
> The bug is a simple one: Find out when the yum updater last ran and
> updated successfully. It most probably has value integrating it(finding
> such info) into SSK client/server implementation following the approach
> you mentioned. However, I would also like this to be working for current
> dx3.

m_anish │ alsroot, thanks for reviewing ajay's patch on @dx :)
alsroot │ m_anish: that wasn't a review, I just think that putting bunch of hardcoded stuff that relate to deployment workflow is
        │ not the right way and needs to be hidden behind command line API
m_anish │ alsroot, +1, on that particular patch perhaps, maybe just using yum history would work well... I replied to your email
        │ btw.
alsroot │ m_anish: my idea is that sugar should ask a cli (relying on its API), "get_last_update_time". thats all that sugar should
        │ do (if cli tool exists)
m_anish │ alsroot, +1, agree, i guess it would be good to have it as a part of sugar-client. until that ... 'yum history' followed
        │ by 'python re' would work IMO
m_anish │ alsroot, good morning, btw :)
alsroot │ m_anish: morning, sugar should not rely on what pms is being used, thats the task of sugar-client internal impl
m_anish │ alsroot, yup, that's why I used 'until that...' in my prev. comment
m_anish │ alsroot, while we're discussing, perhaps would be good to know sugar-client impl roadmap?
m_anish │ in particular, any chance of it going in dx3?
alsroot │ m_anish: I'm going to use it in .py pilot program and as result, having it released in SSK-1.1 (1 dec)
m_anish │ also need to consider that it may need to work in cases where the whole SSK is not being used?
alsroot │ m_anish: ie, it can be a part of dx3
alsroot │ m_anish: the whole idea behind SSK, is that it is not a final solution but a kit, ie, sugar-client can be used on its own
m_anish │ alsroot, hmm... we don't plan to do any major changes to dx3 now besides what is captured in the feature freeze doc, 1dec
        │ may be too late (maybe incorporating it in dx4 would be the way to go)
m_anish │ alsroot, okay
alsroot │ m_anish: in my mind having all these hard coded stuff is a really wrong way, eg, troubles w/ trying/not-trying to push it
        │ to upstream
alsroot │ and keeping in mind that dx3 might be supported for year/two is might be useful to get rid of these stuff in dx2
m_anish │ alsroot, if its not too big a change, it should be easily doable (s/hardcoded/SSK_impl/) via the yum updater
alsroot │ m_anish: the benefit of having this cli tool, is that sugar code will be pretty simple (thus, easy to keep it stable). the
        │ logic will in that cli and can be improved in minor dx3 releases
m_anish │ alsroot, i agree in principle on using SSK (cli-tool), but we need to have this working in our test releases, and I guess
        │ cli-tool isn't ready yet?
m_anish │ alsroot, I guess the bigger underlying question is whether we can have this by the time dx3 is released... or do this via
        │ an update later (after testing it)
alsroot │ m_anish: any way, in this particular case (w/ last update date), sugar code can already rely on external API

-- 
Aleksey