Re: [Gluster-devel] GlusterFs upstream bugzilla components Fine graining

[Prasanna Kalever]

On Fri, Sep 30, 2016 at 3:16 PM, Niels de Vos  wrote:
> On Wed, Sep 28, 2016 at 10:09:34PM +0530, Prasanna Kalever wrote:
>> On Wed, Sep 28, 2016 at 11:24 AM, Muthu Vigneshwaran
>>  wrote:
>> >
>> > Hi,
>> >
>> > This an update to the previous mail about Fine graining of the
>> > GlusterFS upstream bugzilla components.
>> >
>> > Finally we have come out a new structure that would help in easy
>> > access of the bug for reporter and assignee too.
>> >
>> > In the new structure we have decided to remove components that are
>> > listed as below -
>> >
>> > - BDB
>> > - HDFS
>> > - booster
>> > - coreutils
>> > - gluster-hdoop
>> > - gluster-hadoop-install
>> > - libglusterfsclient
>> > - map
>> > - path-converter
>> > - protect
>> > - qemu-block
>>
>> Well, we are working on bringing qemu-block xlator to alive again.
>> This is needed in achieving qcow2 based internal snapshots for/in the
>> gluster block store.
>
> We can keep this as a subcomponent for now.

What should be the main component in this case?

>
>> Take a look at  http://review.gluster.org/#/c/15588/  and dependent patches.
>
> Although we can take qemu-block back, we need a plan to address the
> copied qemu sources to handle the qcow2 format. Reducing the bundled
> sources (in contrib/) is important. Do you have a feature page in the
> glusterfs-specs repository that explains the usability of qemu-block? I
> have not seen a discussion on gluster-devel about this yet either,
> otherwise I would have replied there...

Yeah, have refreshed some part of the code already (local). The
current code is way old (2013) and miss the compat 1.1 (qcow2v3)
features and many more. We are cross checking the merits in using this
in the block store. Once we are in a state to say yes/continue with
this approach, I'm glad to take initiation in refreshing the complete
source and flush out the unused bundle of code.

Well, I do not know about any qcow libraries other than [1], and don't
think we have choice of keeping this outside the repo tree?

And currently I don't have a feature page, will update after summit
time frame, also make a note to post with the complete details in
devel mailing list.

>
> Nobody used this before, and I wonder if we should not design and
> develop a standard file-snapshot functionality that is not dependent on
> qcow2 format.

IMO, that will take an another year or more to bring into block store use.


[1] https://github.com/libyal/libqcow

--
Prasanna

>
> Niels
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] GlusterFs upstream bugzilla components Fine graining

[Niels de Vos]

On Wed, Sep 28, 2016 at 10:09:34PM +0530, Prasanna Kalever wrote:
> On Wed, Sep 28, 2016 at 11:24 AM, Muthu Vigneshwaran
>  wrote:
> >
> > Hi,
> >
> > This an update to the previous mail about Fine graining of the
> > GlusterFS upstream bugzilla components.
> >
> > Finally we have come out a new structure that would help in easy
> > access of the bug for reporter and assignee too.
> >
> > In the new structure we have decided to remove components that are
> > listed as below -
> >
> > - BDB
> > - HDFS
> > - booster
> > - coreutils
> > - gluster-hdoop
> > - gluster-hadoop-install
> > - libglusterfsclient
> > - map
> > - path-converter
> > - protect
> > - qemu-block
> 
> Well, we are working on bringing qemu-block xlator to alive again.
> This is needed in achieving qcow2 based internal snapshots for/in the
> gluster block store.

We can keep this as a subcomponent for now.

> Take a look at  http://review.gluster.org/#/c/15588/  and dependent patches.

Although we can take qemu-block back, we need a plan to address the
copied qemu sources to handle the qcow2 format. Reducing the bundled
sources (in contrib/) is important. Do you have a feature page in the
glusterfs-specs repository that explains the usability of qemu-block? I
have not seen a discussion on gluster-devel about this yet either,
otherwise I would have replied there...

Nobody used this before, and I wonder if we should not design and
develop a standard file-snapshot functionality that is not dependent on
qcow2 format.

Niels


signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] GlusterFs upstream bugzilla components Fine graining

[Prasanna Kalever]

On Wed, Sep 28, 2016 at 11:24 AM, Muthu Vigneshwaran
 wrote:
>
> Hi,
>
> This an update to the previous mail about Fine graining of the
> GlusterFS upstream bugzilla components.
>
> Finally we have come out a new structure that would help in easy
> access of the bug for reporter and assignee too.
>
> In the new structure we have decided to remove components that are
> listed as below -
>
> - BDB
> - HDFS
> - booster
> - coreutils
> - gluster-hdoop
> - gluster-hadoop-install
> - libglusterfsclient
> - map
> - path-converter
> - protect
> - qemu-block

Well, we are working on bringing qemu-block xlator to alive again.
This is needed in achieving qcow2 based internal snapshots for/in the
gluster block store.

Take a look at  http://review.gluster.org/#/c/15588/  and dependent patches.

--
Prasanna

[...]
> Thanks and regards,
>
> Muthu Vigneshwaran & Niels de vos
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] GlusterFs upstream bugzilla components Fine graining

[Atin Mukherjee]

On Tue, Sep 6, 2016 at 12:42 PM, Muthu Vigneshwaran 
wrote:

> Hi,
>
>   Actually the currently component list in the Bugzilla appears to be in
> just alphabetical order of all components and sub-components as a flattened
> list.
>
> Planning to better organize the component list. So the bugs can be
> reported on the components( mostly matching different git repositories) and
> sub-components( mostly matching different components in the git repository,
> or functionality ) in the list respectively which will help in easy access
> for the reporter of the bug and as well as the assignee.
>
> Along with these changes we will have only major version number(3.6,
> 3.7..) (as mentioned in an earlier email from Kaleb - check that :) )
> unlike previously we had major version with minor version. Reporter has to
> mention the minor version in the description (the request for the exact
> version is already part of the template)
>
> In order to do so we require the maintainers to list their top-level
> component and sub-components to be listed along with the version for
> each.You should include the version for glusterfs (3.6,3.7,3.8,3.9,mainline
> ) and the sub-components as far as you have them ready. Also give examples
> of other components and their versions (gdeploy etc). It makes a huge
> difference for people to amend that has bits missing, starting from scratch
> without examples it difficult ;-)
>

This is the tree structure for cli, glusterd & glusterd2 sub components.
Although glusterd2 is currently maintained as a separate github project
under gluster, going forward the same would be integrated in the main repo
and hence there is no point to have this maintained as a different
component in bugzilla IMHO. @Kaushal - let us know if you think otherwise.

|
|
- glusterfs
| |
| |- cli
| |- glusterd
| |- glusterd2
|


> Thanks and regards,
> Muthu Vigneshwaran and Niels
>
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



-- 

--Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel