[Planetlab-devel] Re: API merge between planetlab & onelab

[Tony Mack]

Hi Thierry,

Some comments and questions:

========== Only in CVS:
PLC/Cache.py 
PLC/Methods/AdmGenerateNodeConfFile.py
./util.py		Is this useful ? 
./views.sql		Is this useful ?



Ill go ahead and get rid of Cache since it isn't necessary anymore.  
Keeping AdmGenerateNodeConfFile.py for the time being. util.py may be 
used to test the build, but not completely sure. views.sql isn't in our 
branch.

========== Only in subversion:
PLC/Methods/AddNodeNetworkSetting.py
PLC/Methods/AddNodeNetworkSettingType.py
PLC/Methods/DeleteNodeNetworkSetting.py
PLC/Methods/DeleteNodeNetworkSettingType.py
PLC/Methods/GetNodeNetworkSettingTypes.py
PLC/Methods/GetNodeNetworkSettings.py
PLC/Methods/GetPlcRelease.py - provides info on myplc revision and build
PLC/Methods/NotifySupport.py - same as NotifyPersons but for the support
PLC/Methods/UpdateNodeNetworkSetting.py
PLC/Methods/UpdateNodeNetworkSettingType.py
PLC/NodeNetworkSettingTypes.py
PLC/NodeNetworkSetting.py
migrations/*.sql


I plan on adding the db migration scripts functionality you've developed 
as a means to verify current and future db schema upgrades, but will 
keep planetlab4.sql schema up to with the changes as well. I will add 
your GetPlcRelease to the api. We dont really need NotifySupport. Im not 
familiar with the NodeNetworkSettings object. Can you give me more info 
on what you are using it for.

========== Changed location;
a few test scripts moved under tests/ -- see above - should be totally harmless


========== Most problematic:

PLC/EventObjects.py
	To REVIEW
	see also the corresponding view in planetlab4.sql

PLC/NodeNetworks.py
	TO REVIEW
	same kind of difference


I will use your EventObjects.py implementation. Let me know how you feel 
out NodeNetworks

doc/PLCAPI.xml
	our version slightly different - added a custom note on OneLab changes

========== File by file
Makefile:
	make index : __init__.py has one item per line for easier diffs
	make sync : for easily push a working dir onto a running myplc
	make +foo : prints the value of $(foo)

----------
PLC/Methods/BootUpdateNode.py
	attach event to node - not sure that's still useful


No need to explicitly attach an event to this call because the node_id 
of the node making the call is stored in Events.node_id (this is true 
for all the Boot... calls). BTW until all boot called were logged in the 
api even when api call logging (debug mode) was turned off. Now, these 
boot calls are
only logged if they produce an error (just like every other call).

PLC/Methods/GetNodeNetworks.py
	accepts call(int)
PLC/Methods/GetNodes.py
PLC/Methods/GetSites.py
	accepts call (int) or call(string)
PLC/Methods/GetPCUs.py
PLC/Methods/GetSliceAttributes.py
PLC/Methods/UpdateSite.py
	protects del foo['bar'] with if 'bar' in foo
PLC/Methods/GetPersons.py
PLC/Methods/GetSlices.py
	accepts call (int) or call(string)
	protects del foo['bar'] with if 'bar' in foo
PLC/Methods/GetSlivers.py
	searches enabled persons only
PLC/Methods/UpdateNode.py	
	protects del foo['bar'] with if 'bar' in foo
	exception message altered 
PLC/Methods/VerifyPerson.py
	review exception messages to include the email in question
PLC/Nodes.py
	changes in garbage collecting due to NodeNetworkSettingTypes:
	- nodenetworks not in join_tables anymore
	- but instead, related nodenetworks are subject to explicit delete
	  so related nodenetwork settings get deleted
	accepts a single int or single string as argument (see GetNodes)
	xxx 
	last_contact : I have commented this out - cannot remember why 
	I should probably have re-enabled it, your feedback is appreciated


I vaguely remember there was some perfomance problems around the time 
when we first added the 'last_contact' feature. We were yet sure if this 
was the root cause so we suggested you comment it out until we figured 
things out. It turns out that the fault was somewhere else, so we 
re-enabled the last_contact updated. It is ok re-enable  this feature.

PLC/Persons.py
	accepts a single int or single string as argument (see GetPersons)
	patch about email and federation : only formatting
PLC/PyCurl.py
	exception message altered 
PLC/Slices.py
PLC/Sites.py
	accepts a single int or single string as argument (see GetSites)
PLC/Test.py
	protects del foo['bar'] with if 'bar' in foo
PLCAPI.spec
	extracted name, version and subversion (used by external shell scripts)
	performs doc installation (recomputes html and pdf doc)
doc/Makefile
	miscell changes for refreshing doc on each build

php/header.php
	sneaky bug fix -- see comment



planetlab4.sql
	integrates all changes - subversion is 8
	in some cases (see above - 'TO REVIEW') the onelab implementation
	relies on a view while Princeton's implem. only uses the table


See comment/question about regarding nodenetworks/nodenetwork_settings

./setup.py
	for some reason I don't have Test.py in the files to install
	cannot remember why I would have removed it, maybe Tony added it ?


I dont think we intended on releasing the Test.py script in myplc 
installs. We were just using it to test development.

I have some other minor questions/comments. Ill catch you sometime online

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
>