[Planetlab-devel] API merge between planetlab & onelab

[Tony Mack]

Hi Thierry,

I've completed another round of our api merge. This included 
incorporating most of the things you've listed below as well as 
supporting non list argument for Get calls. I have updated/patched some 
files in our api as well. The result of this merge is checked into 
planetlab-4_0-branch.  Below are some post merge nodes/details that deal 
with some recent patches/modifications i've made to the api. The 
codebase is almost identical at this point, with the exception of some 
very minor differences.

PLC/Methods/AddSliceAttribute.py - No longer accepts duplicate 
attributes (including node/nodegroup attributes).

PLC/Methods/GetNodes.py - Users couldn't see nodes at their site if the 
node had a whitelist. This even prevented PI's from updating the node's 
info. I've modified this method to allow any site member to see any node 
at their site, even if their slice isn't on the node's whitelist.

PLC/Methods/AddSliceToNodes.py - Users couldn't access nodes at their 
site if the node had a whitelist. I've modified this method to allow any 
site member to add their slice to any node at their site, even if their 
slice isn't on the node's whitelist.

Regards,

Tony
PlanetLab Operations

Thierry Parmentelat wrote:
> Hello Tony
> Thanks for the update, will do
> -- Thierry
>
> tmack at CS.Princeton.EDU wrote:
>> I plan or merging the rest of these remaining items, except for the 
>> .spec file; we will have to take care of that later when we actually 
>> start using the same repository.
>>
>> As far as implementation, it seems like we came to an agreement in 
>> the chatroom last Friday. Let me know if anything else comes up.
>>
>> Quoting Thierry Parmentelat <thierry.parmentelat at sophia.inria.fr>:
>>
>>> Hi Tony
>>>
>>> Thanks for taking care of this.
>>>
>>> Most of the remaining diffs are micro-differences, I'm not going to 
>>> argue now on that, and am ready to agree on almost everything there
>>>
>>> I have a few comments however, that I'd like to discuss before I can 
>>> switch back to your codebase:
>>>
>>> - NotifySupport : we've talked briefly about that already. I need 
>>> this because in my web pages, the site registration form has to send 
>>> an e-mail to the support team; I found that using NotifySupport was 
>>> a convenient way to do this; now if you guys can give me a workable 
>>> alternative I am eager to hear it; otherwise I was not finding that 
>>> adding this new - really simple - method could be a problem; 
>>> security issues are imho not exactly relevant here, anyone can - and 
>>> does - spam this public email address anyway
>>>
>>> - the diff in PyCurl.py that gives the extended error messages in 
>>> case curl fails is something we've come to get used to; when 
>>> something gets wrong here, as it unfortunately tends to do, this 
>>> information is generally very helpful
>>>
>>> - the changes in Makefile is something we use on a daily basis:
>>> ** make sync PLCHOST=testbox.inria.fr
>>> is a target that we have on all our modules, and that takes care of 
>>> pushing a workdir onto a running plc - doing whatever is needed so 
>>> the changes take effect
>>> ** on this module, I've changed make index so the various 
>>> __init__.py are line-formatted and can be properly diff'ed
>>>
>>> - doc building:
>>> I rebuild the doc index and content. My 'myplc' package then hacks 
>>> the resulting html into php pages for drupal integration
>>> (and btw, myplc merge is probably going to be next on this list)
>>>
>>> - spec file.
>>> whether you take this or not at this stage is not important, but to 
>>> give you the background
>>> the way it is phrased, using the name, version and subvesion rpm 
>>> variables first, is linked to the way we tag; essentially, tagging a 
>>> module is done in sync with bumping its subversion, and we have 
>>> scripts for doing this that rely on this way of writing a spec file.
>>>
>>> This more or less summarizes my remarks at this stage
>>> What do you think we should we do next ?
>>> As far as I am concerned, having a clear understanding of how we can 
>>> work together on the same codebase, is key now.
>>> Larry's general description of what the API should or should not do 
>>> is very helpful, but we also need the implementation details at some 
>>> point.
>>> Maybe what Fayiaz has in mind in terms of scm can shed some light as 
>>> well here ?
>>>
>>> Thanks again
>>> -- Thierry
>>>
>>>
>>> Tony Mack wrote:
>>>> Hi Thierry,
>>>>
>>>> I've gone through the first phase of the api merge. The resulting 
>>>> code was checked into our HEAD, manually deployed and tested on our 
>>>> alpha PLC, then checked into planetlab-4_0-branch.  I've attached 
>>>> some post merge notes/details. I will be deploying 
>>>> planetlab-4_0-branch onto our production api servers once I've 
>>>> tested the rpm update our alpha PLC.
>>>>
>>>> Thierry Parmentelat wrote:
>>>>> Hi Tony
>>>>>
>>>>> As we had agreed previously, I've been doing a tentative merge 
>>>>> between our variants of the API
>>>>> You'll find our first candidate for this merge here
>>>>> http://svn.one-lab.org/new_plc_api/tags/new_plc_api-4.0.8/
>>>>> This version seems to work fine as far as 1lab is concerned
>>>>>
>>>>> I've written a few notes on this merge in the attached memo
>>>>> but you'll probably have more questions..
>>>>>
>>>>> -- Thierry
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Devel mailing list
>>>>> Devel at lists.planet-lab.org
>>>>> https://lists.planet-lab.org/mailman/listinfo/devel
>>>>
>>>
>>
>>