Hello all, I took the liberty to send my last report on the project progress to you and would like start discussing over some aspects involved.<br><br>1- New metadata arch field extension. I added the archId to the ncInstance_t struct. Now, for this to be used I'm adding a new parameter as well to related functions such allocate_instance(). I'm adding it as the last parameter and making not required. My questions are:<br>
- do you think we should initialize this field with a default or it will be better set when the user choose to. This would involve later modifiying the UI for allowing the user to set the arch.<br>- using the new parameter as the last one is my approach to don't break existing functionality also to keep the boundaries of my changes as shortest as possible. From the use POV it will not represent any problem, just a matter of keeping standards for the developer.<br>
<br>
2- I'm keeping my patches in a local git repo. I plan to push them to the pkg-eucalyptus svn repo as quilt patches in a branch. I'd like to know which approach would be more appealing for you.<br><br>If you have any comments regarding my report I'll be happy to hear from you.<br>
<br>best regards,<br>Rudy<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Rudy Godoy</b> <span dir="ltr"><<a href="mailto:rudy@stone-head.org" target="_blank">rudy@stone-head.org</a>></span><br>
Date: Fri, Aug 5, 2011 at 12:18 AM<br>Subject: Compute Clusters Integration for Debian Development and Building - Report 4<br>To: <a href="mailto:soc-coordination@lists.alioth.debian.org" target="_blank">soc-coordination@lists.alioth.debian.org</a><br>
<br><br><br>
Hello, this is the fourth report for the project. First, I'd like to<br>
apologize for being late, I took a short trip over the weekend and<br>
missed the deadline. This time I've good news for my project. As<br>
expected I've made the necesary changes to have Eucalyptus support ARM<br>
images. The approach was extending and exposing an 'arch' field that<br>
will be used by libvirt's XML domain file. I'm working currently on<br>
having the involved functions working with the new extension and I<br>
expect to have this done over the middle of the next week.<br>
<br>
What was done so far<br>
--------------------<br>
- Extended the ncInstance_t struct on util/data.h adding the archId<br>
parameter. This struct keeps the information regarding a node (nc),<br>
say RAM, Kernel, etc. Currently it has no way to set an arch in order<br>
to be used later.<br>
<br>
typdef struct ncInstance_t{<br>
...<br>
char reservationId[CHAR_BUFFER_SIZE];<br>
char userId[CHAR_BUFFER_SIZE];<br>
char archId[CHAR_BUFFER_SIZE]; // arch field added<br>
int retries;<br>
...<br>
}<br>
The Eucalyptus team was OK with this approach that I've proposed few<br>
weeks ago. For all my changes the approach is maintain compatibility<br>
with existing features.<br>
We still have to define if we are setting a default value, say amd64,<br>
or keep it unset until the user sets one. For now we will be supporting<br>
amd64 and arm as valid fields.<br>
<br>
- Modified the allocate_intance() function to support the archId<br>
field. This involved adding a new parameter and detecting whether its<br>
present and setting de value accordingly. This function is later used<br>
by the doRunInstance() function in node/handlers_kvm.c<br>
<br>
- Modified the involved functions that are called by the KVM handlers<br>
and result in passing parameters to the XML file generator for being<br>
used by libvirt's and KVM and have the image running under<br>
Eucalyptus. The new parameters and field are not required and only<br>
being used if they are set with a value. The archId parameter has been<br>
added as the last one, so existing function calls can work. This could<br>
be rearranged later, but will involve a more extensive revision with<br>
Eucalyptus developers.<br>
<br>
- I've set a git local repo in order to keep track of the changes to<br>
Eucalyptus. Since this part is a sort of a Eucalyptus branch I took<br>
this approach. Steffen and I are discussing whether to release this as<br>
a pkg-eucalyptus branch (as dpatch, using existing packaging). Either<br>
way I'm putting the diff files form my git repo over the wiki and will<br>
put them on my site too. I plan to use git-svn in order to send them<br>
later to the pkg-eucalyptus repo once we are settled with this.<br>
<br>
- Updated the project's wiki[1] page with information regarding all that's<br>
involved on my work, so it can be 're-played' or resumed later.<br>
<br>
1- <a href="http://wiki.debian.org/SummerOfCode2011/BuildWithEucalyptus/ProjectLog" target="_blank">http://wiki.debian.org/SummerOfCode2011/BuildWithEucalyptus/ProjectLog</a><br>
<br>
What I plan to to over the next weeks<br>
-------------------------------------<br>
- Finish the modifications to the relevant functions. Expected dealine:<br>
next week.<br>
- Do integration tests:<br>
- Write a test program, there's an example under node/ that could be<br>
helpful.<br>
- Generate the XML domain definition from Eucalyptus functions. The<br>
full cycle: handler_kvm -> allocate_instance -> get_instance_xml -><br>
have the XML file properly generated -> qemu-kvm runs the instance<br>
using the proper emulator (arm in our case).<br>
- Test runnning the image I've worked on the project's begining.<br>
- Fixing bits and cooperate with the pkg-eucalyptus team on the<br>
packaging bits.<br>
- Talk to Eucalyptus so they adopt our patches.<br>
- Rock and roll :)<br>
<br>
<br>
What would be nice to have after the project ends<br>
-------------------------------------------------<br>
- The Debian packaging *needs* work. I've already discussed this on the<br>
pkg-eucalyptus mailing list. I've also committed myself to help on<br>
that side even after the SoC ends.<br>
- Talk with upstream and Ubuntu to coordinate the packaging efforts and<br>
modifications to the software.<br>
- Get adopters to use our work :)<br>
<br>
<br>
By now, few weeks about to finish the SoC, I can say that it's been a<br>
good experience and as I stated I'm planning to keep maintaing/working<br>
on the software after that. I've already joined the pkg-eucalyptus team<br>
and plan to contribute actively. I'm sad I didn't managed to get Debconf<br>
this year, time was a constraint again, hopefully we can meet in 2012! I<br>
guess that all by now!<br>
<br>
Best regards,<br>
<font color="#888888">Rudy<br>
</font></div><br><br clear="all"><br>-- <br>Rudy Godoy<br><a href="http://stone-head.org" target="_blank">http://stone-head.org</a><br><br>