We already have an @OnLoad in EppResource that removes LINKED
from any status values, so there's no reason to filter in info.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146146501
Move all of the code to create the request factories into
RequestFactoryModule. Also add the --force_http_connection flag to allow us
to force the use of HTTP connections instead of HTTPOverRPC for our internal
connections.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146116640
Warning: This is a breaking change to custom logic for domain info.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146033749
Downstream users who use gRPC rather than REST don't want to pull down
rest-related dependencies.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145834701
We're shipping default custom configuration files that only contain a
comment, so the system should work in that case the same as if the file
didn't exist at all.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145594737
* Remove LINKED when loading an EppResource
* Enforce that you can't add it to a resource
* Ignore LINKED on xjc import of contacts and hosts
After running ResaveAllEppResourcesAction we will no
longer have persisted LINKED statuses in datastore.
In the process of writing this I discovered that RDAP
treats LINKED like any other status value and returns
the persisted value rather than the derived one. Since
this is an existing bug and is orthogonal to the changes
in this CL, I am addressing it in a separate CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145585227
LINKED is a virtual status that needs to be computed on the fly
when creating an RDAP response.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145583415
This was used in DomainInfoFlow to return a DomainResource with no
nameservers without making INACTIVE show up. It was nominally used
in DomainApplicationInfoFlow for the same reason, but that's just
an artifact of the old flow hierarchy since applications never have
INACTIVE set anyways. In either case, now that we have the DomainInfo
return object instead of returning DomainResource directly from the
flow, it's better handled within the flow.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145582317
This implements the basic framework that allows global YAML
configuration, per-environment custom configuration, and unit-
test-specific configuration.
TESTED=I deployed to alpha, ran some EPP commands through the
nomulus tool, and verified no errors.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145422680
The small efficiency increase in not having to look up the TLDs again
did not justify making the externally extensible API more complicated.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145465971
This also bypasses signed mark validation during domain creation if
the flow is being executed as superuser.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145435268
Now that we return an Info object rather than the resource itself,
there's no reason for the cloning pattern.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145426484
This is preparatory refactoring for the next CL, which gets rid
of cloneWithLinkedStatus
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145424322
This implements the basic framework that allows global YAML
configuration, per-environment custom configuration, and unit-
test-specific configuration.
TESTED=I deployed to alpha, ran some EPP commands through the
nomulus tool, and verified no errors.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145422680
LINKED is supposed to be a virtual status that gets added/removed
when needed. It's mistakenly been persisted to datastore on many
resources, but the persisted value is meaningless and may not
represent reality at all. There is no reason to check for LINKED
status before kicking off a delete, since the smoke test and
[] will catch all actual linked objects, and the LINKED
status can be causing false positives for objects that are no
longer LINKED.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145422457
Among the Futures methods that run user callbacks, those that don't take
an Executor will be deleted. This CL migrates them to the counterparts
that take MoreExecutors.directExecutor() as such Executor in the
parameter list, exactly the way that the old method works.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145358533
This fixes a long-standing bug b/26016322 to move BigqueryCommand off of using a service account to access the Bigquery API. It's now using Application Default Credentials, which can be easily auto-installed on a machine by running 'gcloud auth application-default login' and clicking through the OAuth consent screen.
The old method was a pain because:
1) individual users of the tool each needed to know to download and store a private key for the service account, and specify the key file via a CLI flag
2) BigQuery actions taken via the tool (e.g. load or query jobs) were listed as belonging to the service account, making them harder to find in the UI or for debugging, and difficult to audit (no idea which engineer invoked the tool)
3) within Google, this meant extra whitelisting headaches
The new method also isn't perfect because Application Default Credentials obtained via gcloud are supposed to be used primarily for local testing, and don't support setting any custom scopes. However, we don't need custom scopes for this, and the smoother flow is worth it.
In the longer term, once the CLI is using OAuth to talk to the app itself, we'll be able to switch to the "best practice" option of also using those credentials for talking to the BigQuery API.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145120770
Also more narrowly scopes a catch block in TmchCertificateAuthority.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144744847
We no longer care about ROID suffix uniqueness in a post-Registry-2.0-migration
world, and the Registry cache is sufficient for efficiently grabbing the ROID
suffix for TLDs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144483726
Effectively a revert of [] now that synthetic billing events have been verified in production.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144473744
Note that this merely starts this MR on a daily schedule -- the billing queries that ultimately consume the synthetic OneTime events are filtering out the events at this time, so we're still relying on query-time expansion of Recurrings.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144450565
The command still enforces uniqueness (which is fine), but by changing the cache
from a BiMap to a Map, we can support non-unique suffixes if they happen to be
configured as data. The only reason the cache was ever a BiMap in the first
place was to support the Registry 2.0 migration, which was finished a year and a
half ago. It's only being read one way now, so a Map is fine.
See https://github.com/google/nomulus/pull/53 for context.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144381946
It probably should have always been like this, but the Nomulus test recently
started failing without it for some reason.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144343479
This allows us to use util methods from within config, which is a useful thing
to be able to do for, e.g., being able to log errors while loading configuration.
It makes sense that the util package should be at the very base of the
class inheritance hierarchy; config seems logically higher than it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144324273
This is probably best from a code-cleanliness perspective anyways,
but the rationale is that tightly coupling the resources to the
info responses was a straightjacket that required all status
values and fields to be directly available on the resource. With
this change, I already was able to get rid of the preMarshal()
hackery, and I will be able to get rid of cloneWithLinkedStatus()
and most of the contents of cloneProjectedAtTime() for non-domains.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144252924
This is a reasonable thing that custom code might want to do (Donuts already has
a use case).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144216929
This is the follow up PR for #49. It adds an additional parameter to DomainCreateFlowCustomLogic.AfterValidationParameters: a nullable signed mark id.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143966945
The bazel build was failing with the following error message without it:
error: cannot access CanIgnoreReturnValue
class file for com.google.errorprone.annotations.CanIgnoreReturnValue not found
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143961684
This is the final preparatory step necessary in order to load and load
configuration from YAML in a static context and then provide it either via
Dagger (using ConfigModule) or through RegistryConfig's existing static
functions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143819983
