ctubbsii commented on code in PR #4116: URL: https://github.com/apache/accumulo/pull/4116#discussion_r1464127069
########## server/tserver/src/main/java/org/apache/accumulo/tserver/log/CreateEmptyWal.java: ########## @@ -0,0 +1,110 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * https://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.accumulo.tserver.log; + +import static java.nio.charset.StandardCharsets.UTF_8; +import static java.nio.file.StandardOpenOption.CREATE_NEW; +import static org.apache.accumulo.tserver.log.DfsLogger.LOG_FILE_HEADER_V4; +import static org.apache.accumulo.tserver.logger.LogEvents.OPEN; + +import java.io.DataOutputStream; +import java.io.IOException; +import java.nio.file.Files; +import java.nio.file.Path; + +import org.apache.accumulo.core.cli.ConfigOpts; +import org.apache.accumulo.core.crypto.CryptoEnvironmentImpl; +import org.apache.accumulo.core.crypto.CryptoUtils; +import org.apache.accumulo.core.spi.crypto.CryptoEnvironment; +import org.apache.accumulo.core.spi.crypto.CryptoService; +import org.apache.accumulo.server.ServerContext; +import org.apache.accumulo.start.spi.KeywordExecutable; +import org.apache.accumulo.tserver.logger.LogFileKey; +import org.apache.accumulo.tserver.logger.LogFileValue; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +import com.beust.jcommander.Parameter; +import com.google.auto.service.AutoService; +import com.google.common.annotations.VisibleForTesting; + +import edu.umd.cs.findbugs.annotations.SuppressFBWarnings; + +@AutoService(KeywordExecutable.class) +public class CreateEmptyWal implements KeywordExecutable { + private static final Logger LOG = LoggerFactory.getLogger(CreateEmptyWal.class); + private static final LogFileValue EMPTY = new LogFileValue(); + + static class Opts extends ConfigOpts { + @Parameter( + description = " <path> the path / filename of the created empty wal file. The file cannot exist", + required = true) + String walFilename; Review Comment: > If I recall, when needing to use an empty rfile it was convenient to have a "local" file. The empty RFile create tool doesn't create a local file, though. It creates one in the DFS. However, you can specify a local file by using a URL filename pattern, like `file:///path/to/empty.rf`. > you could create an single file and then either use the command line or better, a simple script to do the delete / copy. I agree, and think that's probably how most will use it. But the current CreateEmpty is more flexible than that by allowing creation of multiple at a time. I don't know how people will use that, but that's how it's implemented. > If the intended usage is the utility would to create the files directly - you would still need to delete the original files. Overwriting is probably a bad idea - if there was mistake, you could clobber valid files. Understood, but creating in DFS isn't about overwriting. It's about where you're placing the seed file before you move it into place. You can place it in the DFS, so it's a simple hdfs mv instead of a copyFromLocal. > I assumed that the intention of this utility was to simply create the empty seed file. These changes can be done. but it seems to be unnecessarily complicating things to create that empty wal seed file. It can definitely serve that purpose, but I do not want to restrict the user's ability to do things in batches, if that's how they've written their scripts. and it's not that much complexity to just loop over the file names to create multiple. This is already a feature for the CreateEmpty utility. Using the DFS API to create a file from a URL rather than a local file does add a tiny bit of complexity, but I still think it's worth it to keep parity with the behavior of CreateEmpty. Users don't need to learn two different sets of quirks/restrictions for two, essentially equivalent, utilities that vary only in the type of empty file being created. In fact, I think this utility could just be a `--type wal|rf` option to the existing CreateEmpty, with a default type of `rf`, which would make adding this utility very trivial... but that would require more complex changes to the filename validation in the JCommander Opts. So, to keep things the same for both utilities, you can either add a tiny bit of complexity to what you've written in this separate utility, or you can add a bit of a complexity in the filename validation and argument parsing for the existing utility, and move your impl into that for the WAL case. Either way, I think there's value in keeping the behavior of the two utilities as close as possible. Divergence invites confusion. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
