Re: Documenting standalone metastore
+1 for having a separate wiki page for standalone metastore. Would be good to link it to the existing document. On Mon, Apr 2, 2018 at 9:47 PM, Lefty Leverenz wrote: > Agreed. > > In the last 3 years there were only 7 changes to the metastore admin doc, > so maintaining parallel docs might not be much of a problem. > > -- Lefty > > > On Mon, Apr 2, 2018 at 2:06 PM Thejas Nair wrote: > > > Sounds good to me. > > We have done something similar in past for HiveServer1 vs HiveServer2, > > ReplicationV1 vs V2 etc . > > > > > > On Mon, Apr 2, 2018 at 10:42 AM, Alan Gates > wrote: > > > I've started looking at what will be required to document the new > > > standalone metastore. I started by reviewing the existing admin guide > > for > > > the metastore at > > > > > https://cwiki.apache.org/confluence/display/Hive/ > AdminManual+MetastoreAdmin > > > > > > Much of this will need to change for the standalone metastore, as we'll > > > need to add in information for the standalone case, many configuration > > > values and tool names have changed (though the old ones still work for > > > backwards compatibility). I am concerned that if I put all of the > > changes > > > in this document it will make it hard to use for people administering > > Hive > > > 1 and 2, which is everyone right now and will continue to be a majority > > for > > > at least the next year. > > > > > > So I propose to add a new page for Hive 3.0, and clearly edit the > current > > > page to say it only applies to Hive 1 and 2 and put in a pointer to the > > > Hive 3 page. Much of the content of that page will mirror the current > > one, > > > which is painful from a maintenance viewpoint; however, it will > produce a > > > more usable set of documentation for our users. > > > > > > Seem reasonable? I wanted to check before proceeding as this is not > how > > we > > > have usually done our documentation. > > > > > > Alan. > > >
Re: Documenting standalone metastore
Agreed. In the last 3 years there were only 7 changes to the metastore admin doc, so maintaining parallel docs might not be much of a problem. -- Lefty On Mon, Apr 2, 2018 at 2:06 PM Thejas Nair wrote: > Sounds good to me. > We have done something similar in past for HiveServer1 vs HiveServer2, > ReplicationV1 vs V2 etc . > > > On Mon, Apr 2, 2018 at 10:42 AM, Alan Gates wrote: > > I've started looking at what will be required to document the new > > standalone metastore. I started by reviewing the existing admin guide > for > > the metastore at > > > https://cwiki.apache.org/confluence/display/Hive/AdminManual+MetastoreAdmin > > > > Much of this will need to change for the standalone metastore, as we'll > > need to add in information for the standalone case, many configuration > > values and tool names have changed (though the old ones still work for > > backwards compatibility). I am concerned that if I put all of the > changes > > in this document it will make it hard to use for people administering > Hive > > 1 and 2, which is everyone right now and will continue to be a majority > for > > at least the next year. > > > > So I propose to add a new page for Hive 3.0, and clearly edit the current > > page to say it only applies to Hive 1 and 2 and put in a pointer to the > > Hive 3 page. Much of the content of that page will mirror the current > one, > > which is painful from a maintenance viewpoint; however, it will produce a > > more usable set of documentation for our users. > > > > Seem reasonable? I wanted to check before proceeding as this is not how > we > > have usually done our documentation. > > > > Alan. >
Re: Documenting standalone metastore
Sounds good to me. We have done something similar in past for HiveServer1 vs HiveServer2, ReplicationV1 vs V2 etc . On Mon, Apr 2, 2018 at 10:42 AM, Alan Gates wrote: > I've started looking at what will be required to document the new > standalone metastore. I started by reviewing the existing admin guide for > the metastore at > https://cwiki.apache.org/confluence/display/Hive/AdminManual+MetastoreAdmin > > Much of this will need to change for the standalone metastore, as we'll > need to add in information for the standalone case, many configuration > values and tool names have changed (though the old ones still work for > backwards compatibility). I am concerned that if I put all of the changes > in this document it will make it hard to use for people administering Hive > 1 and 2, which is everyone right now and will continue to be a majority for > at least the next year. > > So I propose to add a new page for Hive 3.0, and clearly edit the current > page to say it only applies to Hive 1 and 2 and put in a pointer to the > Hive 3 page. Much of the content of that page will mirror the current one, > which is painful from a maintenance viewpoint; however, it will produce a > more usable set of documentation for our users. > > Seem reasonable? I wanted to check before proceeding as this is not how we > have usually done our documentation. > > Alan.
Documenting standalone metastore
I've started looking at what will be required to document the new standalone metastore. I started by reviewing the existing admin guide for the metastore at https://cwiki.apache.org/confluence/display/Hive/AdminManual+MetastoreAdmin Much of this will need to change for the standalone metastore, as we'll need to add in information for the standalone case, many configuration values and tool names have changed (though the old ones still work for backwards compatibility). I am concerned that if I put all of the changes in this document it will make it hard to use for people administering Hive 1 and 2, which is everyone right now and will continue to be a majority for at least the next year. So I propose to add a new page for Hive 3.0, and clearly edit the current page to say it only applies to Hive 1 and 2 and put in a pointer to the Hive 3 page. Much of the content of that page will mirror the current one, which is painful from a maintenance viewpoint; however, it will produce a more usable set of documentation for our users. Seem reasonable? I wanted to check before proceeding as this is not how we have usually done our documentation. Alan.
