Hello Allan,

On 08/30/2011 04:18 PM, Allan Garcia wrote:
Hi Kern,

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

Yes, I agreed.


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.

Great.  Branch-5.1 is definitely the right one to be working on.


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.

Nice.  That is a good way to get something really going ...


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.

OK, thanks.

Best regards,

Kern


Best regards,

On Tue, Aug 30, 2011 at 11:04 AM, Kern Sibbald <k...@sibbald.com <mailto:k...@sibbald.com>> 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 <http://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 <k...@sibbald.com <mailto:k...@sibbald.com>>

        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 <allan.gar...@gmail.com
        <mailto:allan.gar...@gmail.com>>

            (...)
            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
        rados...@korzeniewski.net <mailto:rados...@korzeniewski.net>


        
------------------------------------------------------------------------------
        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 list
        Bacula-devel@lists.sourceforge.net  
<mailto:Bacula-devel@lists.sourceforge.net>
        https://lists.sourceforge.net/lists/listinfo/bacula-devel




-- Allan Garcia
    allan.gar...@gmail.com <mailto:allan.gar...@gmail.com>


    
------------------------------------------------------------------------------
    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 list
    Bacula-devel@lists.sourceforge.net  
<mailto:Bacula-devel@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/bacula-devel





--
Allan Garcia
allan.gar...@gmail.com <mailto:allan.gar...@gmail.com>


------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev


_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to