[#170] Support tar.gz archives #177

Merged
alexvanin merged 4 commits from nzinkevich/frostfs-http-gw:tar_download into master 2025-01-23 14:42:42 +00:00
Member

Add handler DownloadTar for downloading tar.gz archives with objects by prefix (same as zip). Make methods more universal for using in both implementations.
Add feature for unpacking archive during upload via /upload handler (to do that Explode-Archive http header should be set)

Add handler DownloadTar for downloading tar.gz archives with objects by prefix (same as `zip`). Make methods more universal for using in both implementations. Add feature for unpacking archive during upload via `/upload` handler (to do that `Explode-Archive` http header should be set)
nzinkevich self-assigned this 2024-12-06 12:41:27 +00:00
nzinkevich added 2 commits 2024-12-06 12:41:28 +00:00
Split DownloadZipped handler on methods. Add handler DownloadTar for downloading tar.gz archives. Make methods more universal for using in both implementations

Signed-off-by: Nikita Zinkevich <n.zinkevich@yadro.com>
[#170] Updated docs and configuration of archive section
All checks were successful
/ DCO (pull_request) Successful in 3m9s
/ Vulncheck (pull_request) Successful in 3m16s
/ Builds (pull_request) Successful in 1m54s
/ Lint (pull_request) Successful in 2m58s
/ Tests (pull_request) Successful in 1m42s
967ed1d6ae
Signed-off-by: Nikita Zinkevich <n.zinkevich@yadro.com>
requested reviews from alexvanin, dkirillov, storage-services-committers, storage-services-developers 2024-12-06 12:41:51 +00:00
nzinkevich changed title from [#170] Support downloading tar.gz archive to [#170] Support tar.gz archives downloading 2024-12-06 12:42:50 +00:00
dkirillov reviewed 2024-12-11 11:36:30 +00:00
@ -130,2 +130,2 @@
// Zip compression.
cfgZipCompression = "zip.compression"
// Archive compression.
cfgArchiveCompression = "archive.compression"
Member

I'm not sure if we can remove zip.compression parameter. Probably we should keep it for one release.
cc @alexvanin

I'm not sure if we can remove `zip.compression` parameter. Probably we should keep it for one release. cc @alexvanin
docs/api.md Outdated
@ -65,0 +61,4 @@
| Common headers | See [bearer token](#bearer-token). |
| `X-Attribute-System-*` | Used to set system FrostFS object attributes <br/> (e.g. use "X-Attribute-System-Expiration-Epoch" to set `__SYSTEM__EXPIRATION_EPOCH` attribute). |
| `X-Attribute-*` | Used to set regular object attributes <br/> (e.g. use "X-Attribute-My-Tag" to set `My-Tag` attribute). |
| `X-Attribute-Explode-Archive` | If this header is set, gate reads files from uploaded `tar.gz` archive and creates object for each file in it. Set FilePath attribute as relative path from archive root. |
Member

This should be X-Explode-Archive

This should be `X-Explode-Archive`
dkirillov marked this conversation as resolved
@ -115,3 +140,1 @@
c.Response.Header.Set(fasthttp.HeaderContentType, "application/zip")
c.Response.Header.Set(fasthttp.HeaderContentDisposition, "attachment; filename=\"archive.zip\"")
c.Response.SetStatusCode(http.StatusOK)
c.Response.Header.Set(fasthttp.HeaderContentType, "application/x-gzip")
Member

Shouldn't it be application/x-gtar ?
https://en.wikipedia.org/wiki/List_of_archive_formats

Shouldn't it be `application/x-gtar` ? https://en.wikipedia.org/wiki/List_of_archive_formats
Author
Member

According to this only application/gzip is presented. So i think it's more common

According to [this](https://www.iana.org/assignments/media-types/media-types.xhtml) only `application/gzip` is presented. So i think it's more common
dkirillov marked this conversation as resolved
@ -165,1 +197,3 @@
}
func (h *Handler) putObjectToArchive(ctx context.Context, log *zap.Logger, cnrID cid.ID, bufZip *[]byte, createArchiveHeader func(obj *object.Object) (io.Writer, error)) func(id oid.ID) bool {
return func(id oid.ID) bool {
log := log.With(zap.String("oid", id.EncodeToString()))
Member

Should be

log = log.With(zap.String("oid", id.EncodeToString()))
Should be ```golang log = log.With(zap.String("oid", id.EncodeToString())) ```
dkirillov marked this conversation as resolved
@ -86,2 +88,4 @@
}
if header := c.Request.Header.Peek(utils.UserAttributeHeaderPrefix + explodeArchiveHeader); header != nil {
h.explodeGzip(c, log, bktInfo, file)
Member

Is this different from #176 ?
If no than we should either:

  • keep only one PR with logically separated commits (upload/download etc)
  • make this PR draft and mention that it requires #176 (and again commits be different)

If yes than why do we ever need #176 ?

Is this different from https://git.frostfs.info/TrueCloudLab/frostfs-http-gw/pulls/176 ? If no than we should either: * keep only one PR with logically separated commits (upload/download etc) * make this PR draft and mention that it requires #176 (and again commits be different) If yes than why do we ever need #176 ?
Author
Member

I accidently include changes from #176 here. For now I think I should remain this PR with commits for download/upload

I accidently include changes from [#176](https://git.frostfs.info/TrueCloudLab/frostfs-http-gw/issues/176) here. For now I think I should remain this PR with commits for download/upload
dkirillov marked this conversation as resolved
alexvanin added this to the v0.33.0 milestone 2024-12-12 11:57:10 +00:00
nzinkevich force-pushed tar_download from 967ed1d6ae to 8281a02d3a 2024-12-13 13:31:42 +00:00 Compare
nzinkevich force-pushed tar_download from 8281a02d3a to 6886fc6f92 2024-12-13 13:33:47 +00:00 Compare
nzinkevich force-pushed tar_download from 6886fc6f92 to e7238eff9c 2024-12-13 13:43:50 +00:00 Compare
Author
Member

I'm not sure what should return upload handler with Explode-Archive option. Should it be only status code or array of object addresses (it seems that the latter would be inefficient if archive contains huge amount of files) @dkirillov @alexvanin

I'm not sure what should return upload handler with Explode-Archive option. Should it be only status code or array of object addresses (it seems that the latter would be inefficient if archive contains huge amount of files) @dkirillov @alexvanin
nzinkevich force-pushed tar_download from e7238eff9c to 27d9b02be4 2024-12-13 13:50:13 +00:00 Compare
nzinkevich force-pushed tar_download from 27d9b02be4 to f8290c3603 2024-12-16 09:23:23 +00:00 Compare
nzinkevich changed title from [#170] Support tar.gz archives downloading to [#170] Support tar.gz archives 2024-12-16 09:23:44 +00:00
nzinkevich force-pushed tar_download from f8290c3603 to 6166505ccd 2024-12-16 11:46:50 +00:00 Compare
dkirillov reviewed 2024-12-16 13:42:14 +00:00
@ -656,6 +656,7 @@ func (a *app) configureRouter(handler *handler.Handler) {
r.OPTIONS("/get_by_attribute/{cid}/{attr_key}/{attr_val:*}", a.addPreflight())
a.log.Info(logs.AddedPathGetByAttributeCidAttrKeyAttrVal)
r.GET("/zip/{cid}/{prefix:*}", a.addMiddlewares(handler.DownloadZipped))
r.GET("/tar/{cid}/{prefix:*}", a.addMiddlewares(handler.DownloadTar))
Member

Please add r.OPTIONS also

Please add `r.OPTIONS` also
dkirillov marked this conversation as resolved
@ -68,0 +95,4 @@
if errIter != nil {
log.Error(logs.IteratingOverSelectedObjectsFailed, zap.Error(errIter))
} else if bufZip == nil {
log.Error(logs.ObjectsNotFound)
Member

Why do we need log this? I don't think this is error by the way.
And probably there is more straightforward way to know if no objects were found:

diff --git a/internal/handler/download.go b/internal/handler/download.go
index 0c83b0d..cbafaa1 100644
--- a/internal/handler/download.go
+++ b/internal/handler/download.go
@@ -87,8 +87,10 @@ func (h *Handler) getZipResponseWriter(ctx context.Context, log *zap.Logger, res
                zipWriter := zip.NewWriter(w)
                var bufZip []byte
 
+               var writtenObjects int
                errIter := resSearch.Iterate(h.putObjectToArchive(ctx, log, bktInfo.CID, &bufZip,
                        func(obj *object.Object) (io.Writer, error) {
+                               writtenObjects++
                                return h.createZipFile(zipWriter, obj)
                        }),
                )

The same for tar

Why do we need log this? I don't think this is error by the way. And probably there is more straightforward way to know if no objects were found: ```diff diff --git a/internal/handler/download.go b/internal/handler/download.go index 0c83b0d..cbafaa1 100644 --- a/internal/handler/download.go +++ b/internal/handler/download.go @@ -87,8 +87,10 @@ func (h *Handler) getZipResponseWriter(ctx context.Context, log *zap.Logger, res zipWriter := zip.NewWriter(w) var bufZip []byte + var writtenObjects int errIter := resSearch.Iterate(h.putObjectToArchive(ctx, log, bktInfo.CID, &bufZip, func(obj *object.Object) (io.Writer, error) { + writtenObjects++ return h.createZipFile(zipWriter, obj) }), ) ``` The same for `tar`
Author
Member

I can change log to Warn, but I think creating new variable for counting is redundant whilst I can only check for bufzip == nil (or len(bufzip) == 0 for more readability)

UPD: I forgot that I can omit usage of *[]byte in case of using separate counter, so this suggestion seems valid

I can change log to Warn, but I think creating new variable for counting is redundant whilst I can only check for `bufzip == nil` (or `len(bufzip) == 0` for more readability) UPD: I forgot that I can omit usage of *[]byte in case of using separate counter, so this suggestion seems valid
dkirillov marked this conversation as resolved
@ -68,0 +97,4 @@
} else if bufZip == nil {
log.Error(logs.ObjectsNotFound)
}
if err := zipWriter.Close(); err != nil {
Member

We shouldn't invoke zipWriter.Close on writing error. This method finishes writing the zip file by writing the central directory I suppose this in't what we want when writing zipped object to client failed

We shouldn't invoke `zipWriter.Close` on writing error. This method `finishes writing the zip file by writing the central directory` I suppose this in't what we want when writing zipped object to client failed
dkirillov marked this conversation as resolved
@ -123,0 +151,4 @@
if h.config.ArchiveCompression() {
gzipWriter, _ = gzip.NewWriterLevel(w, gzip.DefaultCompression)
} else {
gzipWriter, _ = gzip.NewWriterLevel(w, gzip.NoCompression)
Member

Matter of taste, but can we use something like this:

		compressionLevel := gzip.NoCompression
		if h.config.ArchiveCompression() {
			compressionLevel = gzip.DefaultCompression
		}

		gzipWriter, _ := gzip.NewWriterLevel(w, compressionLevel)
Matter of taste, but can we use something like this: ```golang compressionLevel := gzip.NoCompression if h.config.ArchiveCompression() { compressionLevel = gzip.DefaultCompression } gzipWriter, _ := gzip.NewWriterLevel(w, compressionLevel) ```
dkirillov marked this conversation as resolved
@ -163,3 +197,1 @@
},
Address: addr,
}
func (h *Handler) putObjectToArchive(ctx context.Context, log *zap.Logger, cnrID cid.ID, bufZip *[]byte, createArchiveHeader func(obj *object.Object) (io.Writer, error)) func(id oid.ID) bool {
Member

Do we really need bufZip *[]byte ?
It seem we can use just bufZip []byte and init this buffer in getZipResponseWriter/getTarResponseWriter

Do we really need `bufZip *[]byte` ? It seem we can use just `bufZip []byte` and init this buffer in `getZipResponseWriter/getTarResponseWriter`
dkirillov marked this conversation as resolved
@ -176,1 +254,4 @@
return resSearch, nil
}
func (h *Handler) writeToArchive(resGet *Object, objWriter io.Writer, bufZip []byte) error {
Member

It seems this we don't use h. So function should be

func writeToArchive(resGet *Object, objWriter io.Writer, bufZip []byte) error {
It seems this we don't use `h`. So function should be ```golang func writeToArchive(resGet *Object, objWriter io.Writer, bufZip []byte) error { ```
dkirillov marked this conversation as resolved
@ -152,0 +224,4 @@
// default reader - without gzip decompression
accReader := newAccumulatedReader(formFile)
var reader io.Reader
if gzipReader, err := gzip.NewReader(accReader); err == nil {
Member

Maybe we can use Content-Encoding header for this purpose?
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding

Maybe we can use `Content-Encoding` header for this purpose? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding
dkirillov marked this conversation as resolved
@ -0,0 +1 @@
package handler
Member

Empty file

Empty file
Member

Still

Still
dkirillov marked this conversation as resolved
Owner

Good feature for this PR is to support asynchronous object upload. We can implement a pool of go-routines that are accessible by channels. During unzipping uploader can extract file and send it to the channel for asynchronous upload. Then wait acknowledge signal from all goroutines to finish upload.

Good feature for this PR is to support asynchronous object upload. We can implement a pool of go-routines that are accessible by channels. During unzipping uploader can extract file and send it to the channel for asynchronous upload. Then wait acknowledge signal from all goroutines to finish upload.
nzinkevich force-pushed tar_download from 6166505ccd to a589a33a1b 2024-12-17 12:27:01 +00:00 Compare
nzinkevich force-pushed tar_download from a589a33a1b to 4c50d54ead 2024-12-18 06:41:26 +00:00 Compare
nzinkevich force-pushed tar_download from 4c50d54ead to b353b2cd81 2024-12-18 06:55:52 +00:00 Compare
Author
Member

Good feature for this PR is to support asynchronous object upload. We can implement a pool of go-routines that are accessible by channels. During unzipping uploader can extract file and send it to the channel for asynchronous upload. Then wait acknowledge signal from all goroutines to finish upload.

Unfortunately, we cannot get several Readers simultaneously. In http-gw we call tarReader.Next() and pass it as io.Reader to storage. But calling tarReader.Next() once again will reset Reader and previous file upload would be interrupted. Thus, the uploading of files directly to storage can be made only sequentially.
We can try to temporary upload files to http-gw (sequentially) and then upload them to storage (via workerpool). But I'm not sure in performance benefits from it.

> Good feature for this PR is to support asynchronous object upload. We can implement a pool of go-routines that are accessible by channels. During unzipping uploader can extract file and send it to the channel for asynchronous upload. Then wait acknowledge signal from all goroutines to finish upload. Unfortunately, we cannot get several Readers simultaneously. In `http-gw` we call `tarReader.Next()` and pass it as `io.Reader` to storage. But calling `tarReader.Next()` once again will reset Reader and previous file upload would be interrupted. Thus, the uploading of files directly to storage can be made only sequentially. We can try to temporary upload files to http-gw (sequentially) and then upload them to storage (via workerpool). But I'm not sure in performance benefits from it.
KurlesHS reviewed 2024-12-20 07:59:15 +00:00
@ -179,0 +239,4 @@
return
}
// add filepath attribute
attributes = append(attributes, *newAttribute(utils.UserAttributeHeaderPrefix+object.AttributeFilePath, obj.Name))
Member

The prefix "X-Attribute-" isn't needed for the FilePath attribute

The prefix "X-Attribute-" isn't needed for the FilePath attribute
Member

We also should check (and probably drop if it exists) if the FilePath attribute already presence in attributes. Otherwise (as I remember) we will get error duplicate attributes from storage.

We also should check (and probably drop if it exists) if the `FilePath` attribute already presence in `attributes`. Otherwise (as I remember) we will get error `duplicate attributes` from storage.
nzinkevich marked this conversation as resolved
dkirillov reviewed 2024-12-20 13:48:29 +00:00
@ -95,0 +133,4 @@
return
} else if objectsWritten == 0 {
log.Warn(logs.ObjectsNotFound)
return
Member

Probably we shouldn't return here. I would expect that empty archive be downloaded

Probably we shouldn't `return` here. I would expect that empty archive be downloaded
dkirillov marked this conversation as resolved
dkirillov reviewed 2024-12-20 13:49:28 +00:00
@ -213,3 +300,1 @@
return fmt.Errorf("flush zip writer: %v", err)
}
// TODO: проверить zip.Flush
Member

Debug?
If not we should add link to issue and write comment in English

Debug? If not we should add link to issue and write comment in English
dkirillov marked this conversation as resolved
dkirillov reviewed 2024-12-20 13:50:20 +00:00
@ -15,2 +16,4 @@
ObjectsNotFound = "objects not found" // Error in ../../downloader/download.go
CloseZipWriter = "close zip writer" // Error in ../../downloader/download.go
CloseGzipWriter = "close gzip writer" // Error in ../../downloader/download.go
CloseTarWriter = "close tar writer" // Error in ../../downloader/download.go
Member

Please don't add comments at the line end

Please don't add comments at the line end
Author
Member

Shall we remove the rest of the comments in file?

Shall we remove the rest of the comments in file?
Member

Yes, we should remove this either:

  • In separate commit
  • In separate issue/PR
Yes, we should remove this either: * In separate commit * In separate issue/PR
nzinkevich marked this conversation as resolved
dkirillov reviewed 2024-12-20 13:51:12 +00:00
docs/api.md Outdated
@ -65,0 +61,4 @@
| Common headers | See [bearer token](#bearer-token). |
| `X-Attribute-System-*` | Used to set system FrostFS object attributes <br/> (e.g. use "X-Attribute-System-Expiration-Epoch" to set `__SYSTEM__EXPIRATION_EPOCH` attribute). |
| `X-Attribute-*` | Used to set regular object attributes <br/> (e.g. use "X-Attribute-My-Tag" to set `My-Tag` attribute). |
| `X-Explode-Archive` | If set, gate tries to read files from uploading `tar` archive and creates object for each file in it. Uploading `tar` could be compressed via Gzip. Sets FilePath attribute as relative path from archive root. |
Member

We should mention behavior with Content-Encoding header

We should mention behavior with `Content-Encoding` header
dkirillov marked this conversation as resolved
dkirillov reviewed 2024-12-20 13:54:03 +00:00
@ -179,0 +232,4 @@
}
fileName := filepath.Base(obj.Name)
attributes, err := h.extractAttributes(c, log, fileName)
Member

Probably we can extract attributes (at least common) once before the loop.

Probably we can extract attributes (at least common) once before the loop.
dkirillov marked this conversation as resolved
nzinkevich force-pushed tar_download from b353b2cd81 to 6cf5fe295f 2024-12-23 10:39:23 +00:00 Compare
nzinkevich force-pushed tar_download from 6cf5fe295f to ed65df3533 2024-12-23 10:47:05 +00:00 Compare
nzinkevich force-pushed tar_download from ed65df3533 to 9b403da852 2024-12-23 10:47:45 +00:00 Compare
nzinkevich force-pushed tar_download from 9b403da852 to 6d0398ef39 2024-12-23 11:40:19 +00:00 Compare
dkirillov reviewed 2024-12-23 12:27:19 +00:00
@ -93,1 +100,4 @@
}
// setIfNotExist sets key value to map if key is not present yet.
func setIfNotExist(m map[string]string, key, value string) {
Member

thoughts: I'm not sure if we need this function. But this matter of taste. I'm ok to keep it

thoughts: I'm not sure if we need this function. But this matter of taste. I'm ok to keep it
dkirillov reviewed 2024-12-23 12:30:30 +00:00
@ -179,0 +187,4 @@
return attributes, nil
}
func newAttribute(key string, val string) *object.Attribute {
Member

Let's use

func newAttribute(key string, val string) object.Attribute {
Let's use ```golang func newAttribute(key string, val string) object.Attribute { ```
dkirillov marked this conversation as resolved
dkirillov reviewed 2024-12-23 12:36:08 +00:00
@ -179,0 +217,4 @@
attrlen := len(attributes)
filePathIndex, fileNameIndex := attrlen-1, attrlen-2
var reader = file
Member

Please, write:

reader := file
Please, write: ```golang reader := file ```
dkirillov marked this conversation as resolved
dkirillov reviewed 2024-12-23 12:39:03 +00:00
@ -179,0 +212,4 @@
}
attributes = append(attributes,
*newAttribute(object.AttributeFileName, ""),
*newAttribute(object.AttributeFilePath, ""),
Member

Suggestion:

diff --git a/internal/handler/upload.go b/internal/handler/upload.go
index fb54e6c..2d1912e 100644
--- a/internal/handler/upload.go
+++ b/internal/handler/upload.go
@@ -204,18 +204,14 @@ func (h *Handler) explodeArchive(req request, bkt *data.BucketInfo, file io.Read
        delete(filtered, object.AttributeFileName)
        delete(filtered, object.AttributeFilePath)
 
-       attributes, err := h.extractAttributes(c, log, filtered)
+       commonAttributes, err := h.extractAttributes(c, log, filtered)
        if err != nil {
                log.Error(logs.FailedToGetAttributes, zap.Error(err))
                response.Error(c, "could not extract attributes: "+err.Error(), fasthttp.StatusBadRequest)
                return
        }
-       attributes = append(attributes,
-               *newAttribute(object.AttributeFileName, ""),
-               *newAttribute(object.AttributeFilePath, ""),
-       )
-       attrlen := len(attributes)
-       filePathIndex, fileNameIndex := attrlen-1, attrlen-2
+
+       attributes := commonAttributes
 
        var reader = file
        if bytes.EqualFold(c.Request.Header.Peek(fasthttp.HeaderContentEncoding), []byte("gzip")) {
@@ -249,10 +245,10 @@ func (h *Handler) explodeArchive(req request, bkt *data.BucketInfo, file io.Read
                        continue
                }
 
-               // set varying attributes
+               attributes = attributes[:len(commonAttributes)]
                fileName := filepath.Base(obj.Name)
-               attributes[filePathIndex].SetValue(obj.Name)
-               attributes[fileNameIndex].SetValue(fileName)
+               attributes = append(attributes, *newAttribute(object.AttributeFilePath, obj.Name))
+               attributes = append(attributes, *newAttribute(object.AttributeFileName, fileName))
 
                idObj, err := h.uploadObject(c, bkt, attributes, tarReader)
                if err != nil {

Suggestion: ```diff diff --git a/internal/handler/upload.go b/internal/handler/upload.go index fb54e6c..2d1912e 100644 --- a/internal/handler/upload.go +++ b/internal/handler/upload.go @@ -204,18 +204,14 @@ func (h *Handler) explodeArchive(req request, bkt *data.BucketInfo, file io.Read delete(filtered, object.AttributeFileName) delete(filtered, object.AttributeFilePath) - attributes, err := h.extractAttributes(c, log, filtered) + commonAttributes, err := h.extractAttributes(c, log, filtered) if err != nil { log.Error(logs.FailedToGetAttributes, zap.Error(err)) response.Error(c, "could not extract attributes: "+err.Error(), fasthttp.StatusBadRequest) return } - attributes = append(attributes, - *newAttribute(object.AttributeFileName, ""), - *newAttribute(object.AttributeFilePath, ""), - ) - attrlen := len(attributes) - filePathIndex, fileNameIndex := attrlen-1, attrlen-2 + + attributes := commonAttributes var reader = file if bytes.EqualFold(c.Request.Header.Peek(fasthttp.HeaderContentEncoding), []byte("gzip")) { @@ -249,10 +245,10 @@ func (h *Handler) explodeArchive(req request, bkt *data.BucketInfo, file io.Read continue } - // set varying attributes + attributes = attributes[:len(commonAttributes)] fileName := filepath.Base(obj.Name) - attributes[filePathIndex].SetValue(obj.Name) - attributes[fileNameIndex].SetValue(fileName) + attributes = append(attributes, *newAttribute(object.AttributeFilePath, obj.Name)) + attributes = append(attributes, *newAttribute(object.AttributeFileName, fileName)) idObj, err := h.uploadObject(c, bkt, attributes, tarReader) if err != nil { ```
dkirillov marked this conversation as resolved
dkirillov reviewed 2024-12-23 12:49:00 +00:00
@ -150,3 +191,2 @@
var bufZip []byte
var addr oid.Address
gzipWriter, _ := gzip.NewWriterLevel(w, compressionLevel)
Member

Can we add comment why do we ignore the error?

Can we add comment why do we ignore the error?
nzinkevich marked this conversation as resolved
dkirillov approved these changes 2024-12-23 12:50:01 +00:00
Dismissed
dkirillov left a comment
Member

Overall LGTM, but see comment #177 (comment)

cc @alexvanin

Overall LGTM, but see comment https://git.frostfs.info/TrueCloudLab/frostfs-http-gw/pulls/177#issuecomment-61097 cc @alexvanin
nzinkevich force-pushed tar_download from 6d0398ef39 to e20b2bf22d 2024-12-25 09:37:00 +00:00 Compare
nzinkevich dismissed dkirillov's review 2024-12-25 09:37:00 +00:00
Reason:

New commits pushed, approval review dismissed automatically according to repository settings

requested reviews from storage-services-committers, storage-services-developers 2024-12-25 09:37:37 +00:00
nzinkevich added 1 commit 2024-12-25 10:08:33 +00:00
[#170] logs: Remove comments
All checks were successful
/ DCO (pull_request) Successful in 2m14s
/ Vulncheck (pull_request) Successful in 3m5s
/ Builds (pull_request) Successful in 3m41s
/ Lint (pull_request) Successful in 4m0s
/ Tests (pull_request) Successful in 3m36s
0f8b77b67b
Signed-off-by: Nikita Zinkevich <n.zinkevich@yadro.com>
nzinkevich force-pushed tar_download from 0f8b77b67b to d42465f494 2025-01-09 12:35:17 +00:00 Compare
nzinkevich force-pushed tar_download from d42465f494 to 5373f156c3 2025-01-21 07:34:18 +00:00 Compare
alexvanin requested changes 2025-01-22 12:29:10 +00:00
Dismissed
@ -179,3 +179,3 @@
func (s *appSettings) update(v *viper.Viper, l *zap.Logger) {
defaultTimestamp := v.GetBool(cfgUploaderHeaderEnableDefaultTimestamp)
zipCompression := v.GetBool(cfgZipCompression)
archiveCompression := v.GetBool(cfgArchiveCompression)
Owner

I had a chat with developers who configure gateways and received a feedback that deprecated version of old settings will be nice for one minor release. This also was mentioned by @dkirillov in the comments.

I suggest:

  1. Keep cfgZipCompression constant and declare it deprecated in the comment
  2. if v.IsSet(cfgZipCompression) then use it as value for archiveCompression variable
  3. Add comment to config.yaml, config.env that setting is deprecated, use new one
  4. Keep zip section in gate-configuration.md but mention this is deprecated
  5. Create an issue to remove deprecated zip section
I had a chat with developers who configure gateways and received a feedback that deprecated version of old settings will be nice for one minor release. This also was mentioned by @dkirillov in the comments. I suggest: 1) Keep `cfgZipCompression` constant and declare it deprecated in the comment 2) `if v.IsSet(cfgZipCompression)` then use it as value for `archiveCompression` variable 3) Add comment to config.yaml, config.env that setting is deprecated, use new one 4) Keep `zip` section in gate-configuration.md but mention this is deprecated 5) Create an issue to remove deprecated zip section
alexvanin marked this conversation as resolved
@ -189,3 +234,1 @@
},
Address: addr,
}
func (h *Handler) putObjectToArchive(ctx context.Context, log *zap.Logger, cnrID cid.ID, bufZip []byte, createArchiveHeader func(obj *object.Object) (io.Writer, error)) func(id oid.ID) bool {
Owner

bufZip may confuse in the future. I think it's just a buf now for both tar ang zip archives.

`bufZip` may confuse in the future. I think it's just a `buf` now for both tar ang zip archives.
alexvanin marked this conversation as resolved
@ -266,3 +266,3 @@
addr.SetObject(objID)
handler(ctx, h.newRequest(c, log), addr)
handler(ctx, newRequest(c, log), addr)
Owner

Can you describe this change? In my opinion we should either:

  • keep newRequest and remove (h *Handler) newRequest
  • do not add newRequest at all.

Both are okay for me.

Can you describe this change? In my opinion we should either: - keep `newRequest` and remove `(h *Handler) newRequest` - do not add `newRequest` at all. Both are okay for me.
alexvanin marked this conversation as resolved
nzinkevich force-pushed tar_download from 5373f156c3 to 617b150845 2025-01-23 12:45:31 +00:00 Compare
alexvanin approved these changes 2025-01-23 13:47:14 +00:00
Dismissed
nzinkevich force-pushed tar_download from 617b150845 to 36bd3e2d43 2025-01-23 14:16:38 +00:00 Compare
nzinkevich dismissed alexvanin's review 2025-01-23 14:16:38 +00:00
Reason:

New commits pushed, approval review dismissed automatically according to repository settings

alexvanin approved these changes 2025-01-23 14:42:29 +00:00
alexvanin merged commit 36bd3e2d43 into master 2025-01-23 14:42:42 +00:00
alexvanin deleted branch tar_download 2025-01-23 14:42:44 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TrueCloudLab/frostfs-http-gw#177
No description provided.