bharatviswa504 commented on pull request #1494: URL: https://github.com/apache/ozone/pull/1494#issuecomment-861133132
> > IMHO, this looks a little confusing. Because let's say I am the customer who is running ozone, and as I know we donot support rolling upgrade and I need this feature, as I want to convert my non-HA (ratis enabled cluster) to HA enabled cluster. Generally I will update the config on all the nodes to add 2 more node details, and restart all 3 nodes. (Because in general, Ozone will have the same config on all nodes) (So, from a code point of view it is an upgrade/fresh install should not matter if we can support this). > > I don't completely agree with this. You are saying we should be able to skip the bootstrap step if all the OM's are started with new config. But what would happen if the old OM (let's say om1) did not come up during this restart. The new OMs (om2 and om3) started up and formed a ring and started servicing requests. This will lead to data loss and an inconsistent system. > Sorry, Let me be more clear. What I mean is the old OM which was there before the upgrade will do a normal start, and the other 2 OM's will do bootstrap way of start. So, in my view, this scenario should be the same as let's say one OM I start with normal, and the other 2 OM's with bootstrap on a freshly installed cluster. Because config update needs to happen on all nodes, so updating config after the node starts normally is confusing, if it happens before will it work on an upgraded cluster? This kind of scenario (when the config is updated with newly added nodes when start), will not work only on freshly installed clusters? like this is the [scenario](https://github.com/apache/ozone/pull/1494#issuecomment-859326322)? > I think from a code perspective we can support this. (We can introduce another flag like ozone.om.bootstrap.the startup, if you want to separate out normal start where all OM"s started together with later OM's adding to ring) if this flag is enabled, we start each OM with peers empty, and they will learn about other OM's in-ring with setConf call/addOM. (We cannot remove the old way start up). On a side note, this is the approach followed in SCM HA. > > This approach would also require that one OM be set as primary (similar to the primordial SCM node). Subsequently, it would mean we need to redo the way OM HA works currently. I am not opposed to this approach but it would be a big change and I think not worth the effort (seeing how we have to keep it compatible too). This is one way to handle this, as we cannot remove the old way of starting up OM's. So, if I understandand for the normal start we shall follow the existing way of start-up, and when new OM needs to be added then only we shall use bootstrap way? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
