Closed mssawant closed 5 years ago
closed
Closing Halon merge requests.
I believe there is nothing else to be done in this patch. Good work, @mandar.sawant!
This patch cannot be landed without EOS-166 though, which I am yet to deliver. (I've added WIP:
prefix to this merge request's title in order not to land it accidentally.)
resolved all discussions
added 1 commit
changed this line in version 4 of the diff
changed the description
marked as a Work In Progress
added 3 commits
master
Fixing this isn't worth the trouble.
It's concatMap
. ;)
It's w x y z
in the alphabet. Gotcha! :smiling_imp:
added 1 commit
changed this line in version 2 of the diff
changed this line in version 2 of the diff
changed this line in version 2 of the diff
changed this line in version 2 of the diff
changed this line in version 2 of the diff
changed this line in version 2 of the diff
changed this line in version 2 of the diff
changed this line in version 2 of the diff
May be tests. Once Halon changes are in place, need to make sure cluster bootstraps fine. It would also be great if we demo fail over where these changes would help.
Done.
Agree.
Makes sense. Refactored.
Agree, done.
Removed.
Agree, fixed.
Yes, changed it because of the some build earlier which I probably fixed differently later. Fixed it.
Agree, there's a possibility of duplicate M0Devices. Updated.
@mandar.sawant The patch looks good!
Apart from configuration files (m0genfacts, .ede templates, h0fabricator), what else is needed for the “Multiple IOS per node” feature to work?
Consider exporting host2devs
as suggested above.
[optional] We could use TupleSections
extension to reduce the boilerplate:
, mdsProcess ifaddr $ map (0,) [CST_MDS, CST_RMS, CST_ADDB2]
, m0t1fsProcess ifaddr [(0, CST_RMS)]
, iosProcess ifaddr $ (_id_drives, CST_IOS) : map (0,) [CST_RMS, CST_SNS_REP, CST_SNS_REB, CST_ADDB2, CST_ISCS]
Actually, don't bother introducing that IP4
data type. This can be done at leisure time, if we feel like refactoring. (He he, I've just condemned this data type to nonexistence.)
1) We underuse type system here. Suggestion:
-- | IPv4 octets.
data IP4 = IP4 Word8 Word8 Word8 Word8
2) The second tuple does not let us have meaningful arguments. (My first question was “Was does Int
value signify?” I would not have this question if there was self-descriptive argument.)
Suggestion:
mkSvc :: IP4 -> Endpoint -> Int -> ServiceType -> CI.M0Service
mkSvc (IP4 _ _ _ w) ep nrDrives svcType =
And this is how it would be used:
, CI.m0p_services = map (uncurry $ mkSvc ifaddr ep) devs
This is equivalent to map host2devs
. If host2devs
was exported, we would not need hosts2devs
at all.
These lines should not remain in the final patch. Do you want to keep them while the patch is being reviewed?
[optional] Explicit import lists or quantified imports are preferable. What other identifiers of Data.List
were used? If there were not many of them, perhaps they could be added to the explicit import list?
Why is this needed? Data constructors of Either
(Left
and Right
) exported by Prelude, no explicit import is necessary.
We might want to use Set.toList . Set.fromList . concat $
to prevent duplicates. Unless we are absolutely sure (I'm not) that no M0Device can ever be used by several services.
Closes EOS-187