Re: [Bacula-devel] Concerning Item 20: Job migration between different SDs

[Allan G. <all...@gm...>]

Hi Kern,

I already read dev manual, and it's extremely outdated.

I cloned bacula git repo two weeks ago and had been studying the code since
then.

Last week I accomplish to compile bacuka trunk (Branch-5.1) with sucess and
finish my sandbox dev environment.

This week I'm recruiting fellows from my local community and some of my
students to start a code team for this feature and possibly others.

When I have the first usable patch it will be posted here. Until there, any
minor progress will be discussed here. I'll use all your suggestions and
guidelines for this features, and you all will be informed of any decisions
to make.

Best regards,

On Tue, Aug 30, 2011 at 11:04 AM, Kern Sibbald <ke...@si...> wrote:

>  Hello Allan,
>
> Nice.
>
> Here are a few suggestions:
>
> 1. Read the Developer's manual, especially the programming style
> guidelines.
>
> 2. Fill out an FLA (www.bacula.org -> FLA License
>
> 3. There are many additional details that need to be resolved, but can only
> be identified and resolved during the development process.  For this
> reason,
> it is important if you want your patch to be accepted to work fairly
> closely
> with us, either asking us when there are important decisions to be made
> or to send us patches (or post your git repo on git hub where we can access
> it).
>
> I hope this helps,
>
> Best regards,
>
> Kern
>
>
> On 08/29/2011 06:13 PM, Allan Garcia wrote:
>
> Hello Kern,
>
> I'm very interest to implement this, as I told before, this is essential
> for the backup plans that I'm implementing. I'm not so sure that I'll be
> capable to finish thou.
>
> My next steps will be:
>
> 1. Contact my local "open source community" to see if I have others
> volunteers.
> 2. Make the initial code using the design you proposed.
> 3. Send to this list the patch for comments.
>
> Any additional suggestions are welcome.
>
> Thanks.
>
> 2011/8/29 Kern Sibbald <ke...@si...>
>
>>  Hello,
>>
>> I have long ago worked out the basic design of Job migration between
>> different SDs,
>> but I haven't written it down, because no one has volunteered to do the
>> project, so
>> I have been planning to do it myself (if I have to do it, it will be as a
>> Bacula Enterprise
>> feature obviously).  The design is basically:
>>
>> 1. Ensure Dir understands that two SDs are involved (possible need for
>> additional directives).
>>
>> 2. Dir initiates connection with each of the SD's, one of which is the
>> Reading SD  (rSD) and one of which is the Writing SD (wSD).
>>
>> 3. Dir transmits the coordinates of the wSD to the rSD as
>> well as the necessary security token.
>>
>> 4. The rSD connects to the wSD as if it were a FD and uses
>> the FD protocol (or possibly a simplified version) to transmit
>> the data from the rSD to the wSD.  Note, the wSD doesn't
>> need to know that the rSD is an SD -- it can simply think
>> it is an FD.
>>
>> The rest of the backup proceeds as a normal back.
>>
>> Is there someone who is interested to implement the project?
>>
>> Best regards,
>>
>> Kern
>>
>>
>> On 08/29/2011 09:57 AM, Radosław Korzeniewski wrote:
>>
>>  Hello,
>>
>> My thoughts about it below:
>>
>> 2011/8/25 Allan Garcia <all...@gm...>
>>
>>> (...)
>>>  MY INITIAL BRAINSTORM
>>>
>>>  1. the dird have to contact the origin *sd* and command the migration
>>> (like it's done now)
>>> 2. the origin *sd* detects if the destination *sd* it's himself or the
>>> other *sd*
>>>
>>
>> I think Director should communicate origin SD that destination is remote
>> device on the other SD and supply required connection info.
>>
>>
>>>  3. if the origin *sd* detects other destination, it respond informing
>>> that to the dird
>>>
>>  4. the dird have to handle the origin *sd* response informing the
>>> destination *sd*
>>>
>>
>> If you change #2, that above steps won't be required.
>>
>>
>>>  5. the dird commands the destination *sd* to wait the origin *sd*
>>> connection
>>> 6. the dird commands waits the destination *sd* to confirm
>>> 7. the dird commands origin *sd* to send data to destination *sd*
>>> 8. when it's done the job are marked as sucess, otherwise fail.
>>>
>>>  Waiting for any comments...
>>>
>>>
>> You have to design a protocol used for SD to SD communication including
>> TLS/SSL encryption layer.
>>
>> Best regards
>>
>> --
>> Radosław Korzeniewski
>> rad...@ko...
>>
>>
>>  ------------------------------------------------------------------------------
>> EMC VNX: the world's simplest storage, starting under $10K
>> The only unified storage solution that offers unified management
>> Up to 160% more powerful than alternatives and 25% more efficient.
>> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
>>
>>
>>
>> _______________________________________________
>> Bacula-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/bacula-devel
>>
>>
>>
>
>
> --
> Allan Garcia
> all...@gm...
>
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
>
>
>
> _______________________________________________
> Bacula-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/bacula-devel
>
>
>
>


-- 
Allan Garcia
all...@gm...