[users at bb.net] Anecdote about attempting to make scheduelrs reconfigurable.

Neil Gilmore ngilmore at grammatech.com
Thu Dec 22 20:34:41 UTC 2016

Hi Pierre,

Thanks for the pointer. I think part of the problem is cognitive 
dissonance attacking me from a previous life, where 'PR' meant 'problem 
resolution'. I don't do much git at all, so while I understand pull 
request, the abbreviation of PR wasn't quite getting through.

Neil Gilmore

On 12/22/2016 2:27 PM, Pierre Tardy wrote:
> PR means pull request
> This is the basic howto for our contribution.
> http://trac.buildbot.net/wiki/SubmittingPatches
> Have great holidays!
> Pierre
> Le jeu. 22 déc. 2016 à 21:20, Neil Gilmore <ngilmore at grammatech.com 
> <mailto:ngilmore at grammatech.com>> a écrit :
>     Hi Pierre,
>     Thanks for the reply.
>     I'll have a look at the worker to see what it's doing, then see
>     what I can do in my code. Mostly, I just needed a direction to go,
>     and there were several available.
>     I think I asked about PR before, as I'm not familiar with the
>     acronym, but I don't recall getting an answer. Any pointer would
>     be helpful.
>     I did get the OK from on high to share the code back. I wouldn't
>     say it's finished by any means, but all the bones are there. I'm
>     not going to be around much until after New Year's, though.
>     Neil Gilmore
>     grammatech.com <http://grammatech.com>
>     On 12/22/2016 2:11 PM, Pierre Tardy wrote:
>>     I think indeed, this is such a case were you would need to
>>     actually store some part of the config in the object inside
>>     checkConfig.
>>     Like you already pointed out there are already some of the
>>     objects (if I recall correctly the worker are doing that) that
>>     are doing that for the same reason.
>>     Looks like you are at the point were you could start sharing the
>>     code. I think it would be easier to discuss this in a PR even if
>>     this is not fully finished.
>>     Pierre
>>     Le jeu. 22 déc. 2016 à 17:08, Neil Gilmore
>>     <ngilmore at grammatech.com <mailto:ngilmore at grammatech.com>> a écrit :
>>         Good morning everyone,
>>         As you remember, we're having a lot of trouble related to
>>         schedulers in
>>         0.9.X not being reconfigurable in any meaningful sense of the
>>         word. I
>>         got the go-ahead to try to make a patch for this.
>>         Unfortunately, I've
>>         run into a fairly serious problem.
>>         The advice I was given was (in a nutshell) to take the code
>>         in the
>>         various schedulers' __init__ functions, and spread it into 2
>>         functions.
>>         checkConfig() would check its arguments for validity, and
>>         reconfigService() would put them into the instance. Sure,
>>         there were
>>         some various snags at first. Partly, I'm not used to Python's
>>         argument-passing model. Partly, figuring out which arguments
>>         needed to
>>         get passed where. Partly, figuring out that name should only
>>         exist in
>>         the __init__'s, not the checkConfig's, etc.
>>         What happens when we create a scheduler is this:
>>         The scheduler's __init__ function is called. This calls it's base
>>         class's __init__, and so on, up to BuildbotService.__init__.
>>         Note that
>>         all arguments must be preserved during these calls. You'll
>>         see why.
>>         BuildbotService.__init__ calls checkConfig. Now, this call
>>         goes to the
>>         scheduler's checkConfig, which checks its own specific
>>         arguments, then
>>         passes everything else up to it's base class's checkConfig,
>>         and so on.
>>         Everything,s great, right? Wrong...
>>         At this point, we have validated everything. But only the
>>         name is in the
>>         instance. Because everything else is supposed to get assigned in
>>         reconfigService.
>>         But in between __init__ and reconfigService, other things
>>         happen. Such
>>         as check_single_master() (at least for single master
>>         systems). That
>>         attempts to check the builder names in the schedulers vs. the
>>         builders'
>>         names in the config. Naturally, this fails because the
>>         builder names
>>         haven't been put into the schedulers yet. And it would go on
>>         to check
>>         other things that probably fail, too.
>>         I'm not sure how to resolve this. The hacktastic way would be
>>         to just
>>         figure out what might ever get checked and put that back into
>>         __init__.
>>         But that's not very clean. The proper way would be to figure
>>         out how to
>>         make a scheduler reconcile it's own builderNames, et al. with the
>>         builders in the config. But I'd need to be able to get the
>>         config being
>>         checked, and I haven't figured out how to do that. There's
>>         other checks
>>         that go between items like this that I'd need to do, too.
>>         Really, I'm just uncomfortable having this task spread out
>>         into other
>>         areas of buildbot.
>>         Or I just go back to our 80% solution and hack checkConfig...
>>         Neil Gilmore
>>         grammatech.com <http://grammatech.com>
>>         _______________________________________________
>>         users mailing list
>>         users at buildbot.net <mailto:users at buildbot.net>
>>         https://lists.buildbot.net/mailman/listinfo/users
>     _______________________________________________
>     users mailing list
>     users at buildbot.net <mailto:users at buildbot.net>
>     https://lists.buildbot.net/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildbot.net/pipermail/users/attachments/20161222/49de3df1/attachment.html>

More information about the users mailing list