Skip to content

Conversation

@muhamadazmy
Copy link
Member

No description provided.

Copy link
Contributor

@zaibon zaibon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a good step to the right direction. Added a couple of remarks to it.


if len(opts.Type) == 0 {
// sanity check in case type is not set always use hdd
opts.Type = pkg.HDDDevice
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would return an error instead. At this point we should have the information, not having it is mostly sign of a bad request from the user.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually this is an internal call. the user does not have a direct access to flist.Mount.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But in that case, since this is optional (for read/write flists) I should move this check when it's needed.

rootFS, err := flist.Mount(zdbFlistURL, "", pkg.MountOptions{
Limit: 10,
ReadOnly: false,
Type: pkg.HDDDevice,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you remember why we didn't set this to readonly ? Feel like this is the way to go so we don't have to allocate the subvolume for the 0-db other then the one for the actual data.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I remember we had issues when the rootfs of zdb was readonly, but that was all what I remember. BTW this line is the actual cause of the issue.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then I think we need to have more logic. Cause now if there is no HDD, then we cannot deploy 0-db at all.
So I think we should try to deploy on any type of disks

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, but this is not related to this issue. We need to create a new issue (also to retry read-only rootfs) but this now cause minio setup on devent to fail.

rootFS, err := flist.Mount(zdbFlistURL, "", pkg.MountOptions{
Limit: 10,
ReadOnly: false,
Type: pkg.HDDDevice,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then I think we need to have more logic. Cause now if there is no HDD, then we cannot deploy 0-db at all.
So I think we should try to deploy on any type of disks

Limit: 10,
ReadOnly: false,
})
var err error
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@muhamadazmy muhamadazmy merged commit 49aba1f into master Jun 2, 2020
@muhamadazmy muhamadazmy deleted the fix-zdb-container-failure branch June 2, 2020 12:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants