Question Regarding Requests on Production

[AlexThurston]

This is not a bug report, but rather a question. I wasn't entirely sure the best location to pose such a question.

It has to do with how requests (changes to vendors, modules, people, OEs, dependencies and submitting for validation) are handled on production and how best to testing tooling that is being developed.

As you are aware, demo requests are automatically approved but on production they require an email to acvts-prod@nist.gov with the request IDs that are to be looked at/approved which then results in some manual validation.

I would like to test some tooling and a system which would require me to generate requests. In some cases, I would like these requests to go through the workflow and ultimately be approved., but in others I'd likely just want to delete/cancel them. However, there is no API to delete/remove a request. I don't mind creating requests on my end that aren't ever intended to be approved, but I also don't want to bloat production with this kind of data if it's not desired or recommended. Obviously I've tested in demo, but since production's workflow is slightly different, I can't be certain things are working unless I exercise them entirely.

[rstaplesnist]

You're correct in your assumption/concern that this may not be possible. We don't want Production used this way, and auto-approve in demo is only enabled or disabled at the level of the whole environment, so if we disabled it for a time, it would affect everyone.

The best I think we could do here is provide a sample rejection JSON as it would appear from the user's side and you can place that in the correct location to simulate it having come from us. If you'd like to go that route, let me know ad I can go about getting something for you.

[AlexThurston]

An example of rejection might not be all that necessary since the documentation https://pages.nist.gov/ACVP/draft-fussell-acvp-spec.html#requests does say that the status will be rejected and presumably the message would contain some information about why. Unless that not accurate, that should be sufficient for me to build against.

The scenario I was thinking about with regards to cancelling a request is where I update the name of a vendor and subsequently (before sending the email to have the request ID approved) update the name of the vendor again. In that situation, there are two requests in-flight. What is the expectation in that case? Would the first request just live in perpetuity as living in the initial or processing state? Are users expected to state via email when they not only want requests to be looked at to be approved but also if they want to reject/cancel them?

[rstaplesnist]

Ahh, that's actually pretty straight-forward!

Yes, if you have any request that you simply want rejected, just email acvts-prod@nist.gov like usual and we're happy to reject it. This actually happens with some regularity. Usually someone accidentally submits a duplicate or realizes a typo between submission and their email. I get at least one a week, probably. No problem at all.

[rstaplesnist]

Oh, and one other note. If you sent a request but never emailed to ask for review, it wouldn't actually live on forever. At the beginning of each month, I go through and reject anything older than the previous month. Just to keep the queue clean. So, even if you forgot, it won't live totally forever. It would get rejected by someone on the team, probably myself, after about a month.

[AlexThurston]

This is all immensely helpful. Thank you. I'll close this for now, but if I had other questions, is it best to do it over Github, or does email make more sense?

[rstaplesnist]

Typically questions related to the protocol or aimed at the developers come in via GitHub, while business-process questions or questions aimed at the reviewers usually end up emailed to acvts-prod@nist.gov.

This falls mostly into the latter category for sure. But there's no hard rules. We're a small team and the question will get to the right person either way. It took me a few days to see this one since I don't normally review GitHub issues. In this case, one of the devs forwarded it to me internally.