[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Add a function to split a glist into two lists at a specific...
>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/358466 Change subject: Add a function to split a glist into two lists at a specific point .. Add a function to split a glist into two lists at a specific point Change-Id: I4fc51d1855b6d445fecaa352fba753c28ced39cc Signed-off-by: Frank S. Filz --- M src/include/gsh_list.h 1 file changed, 36 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/66/358466/1 -- To view, visit https://review.gerrithub.io/358466 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I4fc51d1855b6d445fecaa352fba753c28ced39cc Gerrit-Change-Number: 358466 Gerrit-PatchSet: 1 Gerrit-Owner: Frank Filz -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Split large dirent chunks
>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/358465 Change subject: Split large dirent chunks .. Split large dirent chunks Change-Id: I63f09417a128b8af9b0c9e9f96c56db219a6953e Signed-off-by: Frank S. Filz --- M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_ext.h M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_read_conf.c M src/include/gsh_list.h 4 files changed, 85 insertions(+), 4 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/65/358465/1 -- To view, visit https://review.gerrithub.io/358465 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I63f09417a128b8af9b0c9e9f96c56db219a6953e Gerrit-Change-Number: 358465 Gerrit-PatchSet: 1 Gerrit-Owner: Frank Filz -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] 2.5rc2 and FSAL_RGW, no bueno
Hi Frank, - Original Message - > From: "Frank Filz" > To: d...@redhat.com, "Dominique Martinet" > Cc: nfs-ganesha-devel@lists.sourceforge.net > Sent: Monday, April 24, 2017 12:53:44 PM > Subject: Re: [Nfs-ganesha-devel] 2.5rc2 and FSAL_RGW, no bueno > > > >> Our proposal is this: > > >> > > >> Branch when Ganesha goes into -rc, rather than on .0 release. This > > >> allows us to modify the -rc version of Ganesha to build and work > > Typically while we are in rc, stuff that will not go into the release under > rc is just held until we open dev again, so no double merges. > > So the remaining issue is what is the best way to converge on stable code > that will build with release versions of other packages. > > What kinds of fixups are we talking here? Can we just revert the fixups when > we open dev of the next release? > The main issue are changes that adapt FSAL_RGW to use an updated version of our librgw interface. To date, the changes in any give release have been minor, usually adding or adjusting the arguments to a well-known operation or callback function signature. Matt > Frank > -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] 2.5rc2 and FSAL_RGW, no bueno
> >> Our proposal is this: > >> > >> Branch when Ganesha goes into -rc, rather than on .0 release. This > >> allows us to modify the -rc version of Ganesha to build and work against > >> the then-extant versions of Ceph in the distros, and not have to worry > >> about syncing dev cycles between Ceph and Ganesha. > > > > Forking at -rc makes sense for me, as we can then only land fixes there > > and continue with regular development on next. > > The only black spot there is that it will give Frank more work (as there > > will have to be two merges for a few weeks), so I guess ultimately it's > > down to him. > > > > Or hand the -rc off to the next version maintainer? But yes, slightly > more work either way. (Of course, there may not be anything to merge > for the next -dev, at least for a while) Typically while we are in rc, stuff that will not go into the release under rc is just held until we open dev again, so no double merges. So the remaining issue is what is the best way to converge on stable code that will build with release versions of other packages. What kinds of fixups are we talking here? Can we just revert the fixups when we open dev of the next release? Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Fix CMake configuration so ganesha_conf is installed correctly.
>From Wyllys Ingersoll : Wyllys Ingersoll has uploaded this change for review. ( https://review.gerrithub.io/358443 Change subject: Fix CMake configuration so ganesha_conf is installed correctly. .. Fix CMake configuration so ganesha_conf is installed correctly. Change-Id: Ib62b488a926f8aa21986c5091e38d30c0eb3 Signed-off-by: Wyllys Ingersoll --- M src/scripts/ganeshactl/CMakeLists.txt R src/scripts/ganeshactl/ganesha_conf.py 2 files changed, 1 insertion(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/43/358443/1 -- To view, visit https://review.gerrithub.io/358443 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: Ib62b488a926f8aa21986c5091e38d30c0eb3 Gerrit-Change-Number: 358443 Gerrit-PatchSet: 1 Gerrit-Owner: Wyllys Ingersoll -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] NFS-Ganesha 2.5rc2 builds for testing
On 04/24/2017 01:55 PM, Kaleb S. KEITHLEY wrote: > We have nfs-ganesha-2.5rc2 packages for testing > > https://kkeithle.fedorapeople.org/ganesha25.tgz > > Includes libntirpc-1.5.0 rpms. > > Use with glusterfs-3.10.1 rpms from CentOS Storage SIG. That is, if you want to test with gluster. You can test XFS and VFS, amongst other things, without gluster. And they are for CentOS 7 (and RHEL 7) on x86_64 hardware. > > For the truly bold, there are also nfs-ganesha-2.5rc2 and > libntirpc-1.5.0 RPMs in Fedora rawhide (f27) -- Kaleb -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] NFS-Ganesha 2.5rc2 builds for testing
We have nfs-ganesha-2.5rc2 packages for testing https://kkeithle.fedorapeople.org/ganesha25.tgz Includes libntirpc-1.5.0 rpms. Use with glusterfs-3.10.1 rpms from CentOS Storage SIG. For the truly bold, there are also nfs-ganesha-2.5rc2 and libntirpc-1.5.0 RPMs in Fedora rawhide (f27) -- Kaleb -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Fix COMPONENT_NFSPROTO's string as "PROTO"
>From Malahal : Malahal has uploaded this change for review. ( https://review.gerrithub.io/358397 Change subject: Fix COMPONENT_NFSPROTO's string as "PROTO" .. Fix COMPONENT_NFSPROTO's string as "PROTO" Currently it logs 'NFS3' which is confusing as COMPONENT_NFSPROTO is used in many nfs v4 functions as well. Reported-by: Ravi Komanduri Change-Id: I719e451f182ffe5944d22cb79dec708b636811af Signed-off-by: Malahal Naineni --- M src/log/log_functions.c 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/97/358397/1 -- To view, visit https://review.gerrithub.io/358397 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I719e451f182ffe5944d22cb79dec708b636811af Gerrit-Change-Number: 358397 Gerrit-PatchSet: 1 Gerrit-Owner: Malahal -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Don't call state_share_remove with support_ex
>From Malahal : Malahal has uploaded this change for review. ( https://review.gerrithub.io/358396 Change subject: Don't call state_share_remove with support_ex .. Don't call state_share_remove with support_ex Change-Id: I4836d4e485a271402c447152a4b1d6e454a6f341 Signed-off-by: Malahal Naineni --- M src/SAL/nfs4_state.c 1 file changed, 7 insertions(+), 4 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/96/358396/1 -- To view, visit https://review.gerrithub.io/358396 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I4836d4e485a271402c447152a4b1d6e454a6f341 Gerrit-Change-Number: 358396 Gerrit-PatchSet: 1 Gerrit-Owner: Malahal -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Fix nlm state refcount going up from zero
>From Malahal : Malahal has uploaded this change for review. ( https://review.gerrithub.io/358393 Change subject: Fix nlm state refcount going up from zero .. Fix nlm state refcount going up from zero Once a refcount goes to zero, we should not be using it any more and let the thread that made it zero free up the entry. If zero refcount entry is found in the hash table, don't use it, remove it from the hash table and insert a new nlm state. Also, under some cases, we do delete non zero refcnt nlm state objects from the hash table as well. This change should avoid logging spurious messages from dec_nlm_state_ref() for not finding the nlm state in the hash table and accidentally deleting someone else's nlm state. Change-Id: I3917327f2fdfe8df0e5d9d2a64786ba4c1eb4cd4 Signed-off-by: Malahal Naineni --- M src/SAL/nlm_state.c 1 file changed, 33 insertions(+), 40 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/93/358393/1 -- To view, visit https://review.gerrithub.io/358393 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I3917327f2fdfe8df0e5d9d2a64786ba4c1eb4cd4 Gerrit-Change-Number: 358393 Gerrit-PatchSet: 1 Gerrit-Owner: Malahal -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Fix nsm client refcount going up from zero
>From Malahal : Malahal has uploaded this change for review. ( https://review.gerrithub.io/358392 Change subject: Fix nsm client refcount going up from zero .. Fix nsm client refcount going up from zero Once a refcount goes to zero, we should not be using it any more and let the thread that made it zero free up the entry. If zero refcount entry is found in the hash table, don't use it, remove it from the hash table and insert a new nsm client. Change-Id: I68a4e848a13981932e1d34dc654de5985f3fb491 Signed-off-by: Malahal Naineni --- M src/SAL/nlm_owner.c 1 file changed, 32 insertions(+), 30 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/92/358392/1 -- To view, visit https://review.gerrithub.io/358392 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I68a4e848a13981932e1d34dc654de5985f3fb491 Gerrit-Change-Number: 358392 Gerrit-PatchSet: 1 Gerrit-Owner: Malahal -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Fix F_GETLK/SETLK/SETLKW having F_GETLK64/SETLK64/SETLKW64 v...
>From Malahal : Malahal has uploaded this change for review. ( https://review.gerrithub.io/358395 Change subject: Fix F_GETLK/SETLK/SETLKW having F_GETLK64/SETLK64/SETLKW64 value .. Fix F_GETLK/SETLK/SETLKW having F_GETLK64/SETLK64/SETLKW64 value Commit 036703eb471da2eadb374dec6ffe5e5302334f66 added -D_FILE_OFFSET_BITS=64 compilation flag to use 64 bit variants of some system calls on 32 bit systems. This plays with F_GETLK and related command values causing GPFS kernel code not work with ganesha lock requests. Temporarily disable this until we get a fix in GPFS kernel module. Change-Id: I18784b1fd56c74beda6cd69db0a1691b9778236e Signed-off-by: Malahal Naineni --- M src/FSAL/FSAL_GPFS/file.c M src/FSAL/FSAL_GPFS/fsal_lock.c 2 files changed, 2 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/95/358395/1 -- To view, visit https://review.gerrithub.io/358395 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I18784b1fd56c74beda6cd69db0a1691b9778236e Gerrit-Change-Number: 358395 Gerrit-PatchSet: 1 Gerrit-Owner: Malahal -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Convert state_owner hash table to behave like others
>From Malahal : Malahal has uploaded this change for review. ( https://review.gerrithub.io/358394 Change subject: Convert state_owner hash table to behave like others .. Convert state_owner hash table to behave like others Curently, get_state_owner() waits for a zero refcount state owner to be deleted by another thread before it can insert its own. Instead, let it delete such entry and insert its own. Change-Id: If40662ee59cd5bce25a6a38fc49d34859ccc4d6d Signed-off-by: Malahal Naineni --- M src/SAL/state_misc.c M src/hashtable/hashtable.c 2 files changed, 33 insertions(+), 87 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/94/358394/1 -- To view, visit https://review.gerrithub.io/358394 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: If40662ee59cd5bce25a6a38fc49d34859ccc4d6d Gerrit-Change-Number: 358394 Gerrit-PatchSet: 1 Gerrit-Owner: Malahal -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: [FSAL_GPFS] Remove duplicate code.
>From Swen Schillig : Swen Schillig has uploaded this change for review. ( https://review.gerrithub.io/358389 Change subject: [FSAL_GPFS] Remove duplicate code. .. [FSAL_GPFS] Remove duplicate code. The error handling of most functions in fsal_internal.c is identical. Therefore, the common part can be extracted into a static function. Change-Id: I36f297834dc2bb7065162333c6496f0f025ca271 Signed-off-by: Swen Schillig --- M src/FSAL/FSAL_GPFS/fsal_internal.c M src/FSAL/FSAL_GPFS/handle.c 2 files changed, 62 insertions(+), 183 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/89/358389/1 -- To view, visit https://review.gerrithub.io/358389 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I36f297834dc2bb7065162333c6496f0f025ca271 Gerrit-Change-Number: 358389 Gerrit-PatchSet: 1 Gerrit-Owner: Swen Schillig -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] 2.5rc2 and FSAL_RGW, no bueno
On 04/24/2017 10:10 AM, Dominique Martinet wrote: > Hi folks, > > Daniel Gryniewicz wrote on Mon, Apr 24, 2017 at 09:48:33AM -0400: >> After a discussion with Matt, here's my thoughts. >> >> 1. We want -dev versions of Ganesha to track Master versions of Ceph. >> This makes development much easier for us, and shouldn't cause problems, >> since -dev versions aren't packaged. This also makes upstream Ceph >> happier, with is CI integration. > > A quick note on that, is that when the ceph requirement is bumped up the > CEA bot will likely fail builds as well until someone here updates it -- > but I guess as it currently says it's OK we might already have given up > on that... I'm happy leaving Ceph builds to Ceph upstream. Automation is basically done at this point, and I'll get with Ali to see about adding Gerrithub integration. > >> 2. Matt doesn't want to maintain a compatibility layer. I can >> understand this. >> >> 3. Once Ganesha enters -rc, we suddenly care about what is shipping in >> distros, since test packages have to be made. >> >> Our proposal is this: >> >> Branch when Ganesha goes into -rc, rather than on .0 release. This >> allows us to modify the -rc version of Ganesha to build and work against >> the then-extant versions of Ceph in the distros, and not have to worry >> about syncing dev cycles between Ceph and Ganesha. > > Forking at -rc makes sense for me, as we can then only land fixes there > and continue with regular development on next. > The only black spot there is that it will give Frank more work (as there > will have to be two merges for a few weeks), so I guess ultimately it's > down to him. > Or hand the -rc off to the next version maintainer? But yes, slightly more work either way. (Of course, there may not be anything to merge for the next -dev, at least for a while) Daniel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: FSAL_GLUSTER - initialize buffxstat. CID 161510
>From Daniel Gryniewicz : Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/358373 Change subject: FSAL_GLUSTER - initialize buffxstat. CID 161510 .. FSAL_GLUSTER - initialize buffxstat. CID 161510 Change-Id: If68ce0206bc016c9ec54cd7642a15485bd6c5aa9 Signed-off-by: Daniel Gryniewicz --- M src/FSAL/FSAL_GLUSTER/handle.c 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/73/358373/1 -- To view, visit https://review.gerrithub.io/358373 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: If68ce0206bc016c9ec54cd7642a15485bd6c5aa9 Gerrit-Change-Number: 358373 Gerrit-PatchSet: 1 Gerrit-Owner: Daniel Gryniewicz -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] 2.5rc2 and FSAL_RGW, no bueno
Hi folks, Daniel Gryniewicz wrote on Mon, Apr 24, 2017 at 09:48:33AM -0400: > After a discussion with Matt, here's my thoughts. > > 1. We want -dev versions of Ganesha to track Master versions of Ceph. > This makes development much easier for us, and shouldn't cause problems, > since -dev versions aren't packaged. This also makes upstream Ceph > happier, with is CI integration. A quick note on that, is that when the ceph requirement is bumped up the CEA bot will likely fail builds as well until someone here updates it -- but I guess as it currently says it's OK we might already have given up on that... > 2. Matt doesn't want to maintain a compatibility layer. I can > understand this. > > 3. Once Ganesha enters -rc, we suddenly care about what is shipping in > distros, since test packages have to be made. > > Our proposal is this: > > Branch when Ganesha goes into -rc, rather than on .0 release. This > allows us to modify the -rc version of Ganesha to build and work against > the then-extant versions of Ceph in the distros, and not have to worry > about syncing dev cycles between Ceph and Ganesha. Forking at -rc makes sense for me, as we can then only land fixes there and continue with regular development on next. The only black spot there is that it will give Frank more work (as there will have to be two merges for a few weeks), so I guess ultimately it's down to him. -- Dominique -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: FSAL_MEM - Check for valid attrs. CID #161621
>From Daniel Gryniewicz : Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/358363 Change subject: FSAL_MEM - Check for valid attrs. CID #161621 .. FSAL_MEM - Check for valid attrs. CID #161621 attrs doesn't have to be passed into open, but was unconditionally dereferenced in mem_alloc_handle(). Check to see if it's actually valid. Change-Id: I16d402fe51e03a297661f5a1f30572ea8b22f6ba Signed-off-by: Daniel Gryniewicz --- M src/FSAL/FSAL_MEM/mem_handle.c 1 file changed, 7 insertions(+), 7 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/63/358363/1 -- To view, visit https://review.gerrithub.io/358363 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I16d402fe51e03a297661f5a1f30572ea8b22f6ba Gerrit-Change-Number: 358363 Gerrit-PatchSet: 1 Gerrit-Owner: Daniel Gryniewicz -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] 2.5rc2 and FSAL_RGW, no bueno
After a discussion with Matt, here's my thoughts. 1. We want -dev versions of Ganesha to track Master versions of Ceph. This makes development much easier for us, and shouldn't cause problems, since -dev versions aren't packaged. This also makes upstream Ceph happier, with is CI integration. 2. Matt doesn't want to maintain a compatibility layer. I can understand this. 3. Once Ganesha enters -rc, we suddenly care about what is shipping in distros, since test packages have to be made. Our proposal is this: Branch when Ganesha goes into -rc, rather than on .0 release. This allows us to modify the -rc version of Ganesha to build and work against the then-extant versions of Ceph in the distros, and not have to worry about syncing dev cycles between Ceph and Ganesha. The alternative is that we have to modify -rc, and then undo the mods again as soon as the next -dev open up. What do people think? Daniel On 04/24/2017 08:57 AM, Daniel Gryniewicz wrote: > Dev versions of FSAL_RGW have pretty much always required dev versions > of Ceph. I believe the backports for the ceph fixes are in the works. > > Matt? > > Daniel > > On 04/22/2017 08:54 AM, Kaleb Keithley wrote: >> >> Just an FYI, >> >> building against Ceph 10.2.7 in Fedora rawhide (f27) the build fails. >> >> Details at >> https://kojipkgs.fedoraproject.org//work/tasks/5601/19135601/build.log >> >> versus ganesha-2.4.5 which does build. >> >> I'm guessing that this might be a Ceph 10 versus 11 or 12 thing? >> branto tried to build Ceph 11.2 back in February, but it failed and >> there's been no activity around Ceph 11 or Ceph 12 since then. >> >> Looks like we need to do something a little different in our >> development strategy around Ceph RGW.) >> >> -- >> >> Kaleb >> >> -- >> >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Nfs-ganesha-devel mailing list >> Nfs-ganesha-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel >> > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] Documentation using Sphinx
I think this is a good idea. Maintaining raw man pages has always been a bit of a pain. Daniel On 04/23/2017 04:53 PM, Supriti Singh wrote: > Hello all, > > I recently submitted a patch for man page for NFS-Ganesha configuration > options. > > I would like to suggest using sphinx tool for documentation. Similar to > what ceph is using https://github.com/ceph/ceph/tree/master/doc > > The doc can be written in ReStructured text markdown format, and can be > compiled into various formats such as man, html, pdf and latex. Its > easier to maintain, and easier for others to change. > > I have re-written the current patch in rst format. I have attached the > rst file and man file generated using sphinx. I am still working on the > format. > > Let me know your thoughts. Going ahead, we can think of converting > existing documents into rst. > > Thanks, > Supriti > > > -- > Supriti Singh > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, > HRB 21284 (AG Nürnberg) > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > ___ > Nfs-ganesha-devel mailing list > Nfs-ganesha-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] 2.5rc2 and FSAL_RGW, no bueno
Dev versions of FSAL_RGW have pretty much always required dev versions of Ceph. I believe the backports for the ceph fixes are in the works. Matt? Daniel On 04/22/2017 08:54 AM, Kaleb Keithley wrote: > > Just an FYI, > > building against Ceph 10.2.7 in Fedora rawhide (f27) the build fails. > > Details at > https://kojipkgs.fedoraproject.org//work/tasks/5601/19135601/build.log > > versus ganesha-2.4.5 which does build. > > I'm guessing that this might be a Ceph 10 versus 11 or 12 thing? branto tried > to build Ceph 11.2 back in February, but it failed and there's been no > activity around Ceph 11 or Ceph 12 since then. > > Looks like we need to do something a little different in our development > strategy around Ceph RGW.) > > -- > > Kaleb > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Nfs-ganesha-devel mailing list > Nfs-ganesha-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
