Noctam/DWP/ACS Test Harness/Diary

From The Dreaming
Jump to navigation Jump to search
ACS Test Harness

Meetings

Existing System

Specifications

Diary
2009:

Notes

Diary

I'll be recording a daily log of what I did, and maybe a 'plans for the next working day' in lieu of a stand-up or similar to go over this stuff with peers.

Week 1: 06/09/2021-12/09/2021

Day 1: 06/06/2021

Initial workshop to discuss requirements and broad development strategy. See Meetings: Initial Workshop.

Day 2: 07/09/2021

In which I:

  • installed and set up intellij + python on my noctam PC
  • created simplistic sim-start and sim-stop scripts to start and stop the CISSIM server
  • got it up and running, which required a bit of jiggery-pokery:
    • needed to install windows-curses in my python environment: pip install windows-curses
    • Fixed a couple of relative paths hardcoded into a couple of python files. To wit:
 commit 5205c969edcfe9e075ca8261a3ca2f13fa3e7129
 Author: Stuart Wood (Noctam) <stuart.wood@noctam.co.uk>
 Date:   Tue Sep 7 14:34:42 2021 +0100
   
   Don't rely on relative paths for files/folders
   
   Adds a 'getrootfolder' function to pdutils which gets the root folder of
   the 'project', by getting the parent of the directory in which the
   pdutils file is found.
   
   I can't immediately think of any problem with this, and it means you can
   run it safely from anywhere.
   
   This also dynamically alters the 'FOLDERS' config value (actually it
   checks of the config value starts with '../' and replaces '../' with the
   root folder provided by getrootfolder()) when it loads the config.
  • Stepped it through a DCI913 call to get an idea of a) what it did, and b) how it did it. My notes are available, for now, but in a nutshell:

OK, this is actually quite flexible, and, although the code is terse and uncommented, it's not that hard to follow. Ultimately, it doesn't do that much (in the above, quite narrow, use case) - I could fairly easily strip out everything that isn't required by a DCI call and just have that as our starting block of code... I might do that, though I want to get PDD and NPS in there too, neither of which are handled in my initial examination above.

Day 3: 08/09/2021

Plan

  • Step through PDD processing in the CISSIM program
  • Step through NPS processing too
  • Document the aboves
  • Start stripping out unused files / classes and reduce the program to its minimum codeset for ACS testing
  • Start a design of the java version of it
    • I'll probably need to talk through some aspects of it (inputs / outputs) with the FDACS team, maybe tomorrow for that.

Execution

  • Well, I stepped through the PDD processing
  • I identified a few things which will need looking into - see Notes/CISSIM - the config processing is probably the main one since it's needed for PDD and it does some pretty meaty stuff at config loading time to determine the locations for the fields within PDD data blocks.
  • I picked up some new setup instructions, which included reference to scripts that Sean has written to start and stop the servers - plural, i.e. the NPS server as well. Duh.
  • Looked through NPS - looks really straightforward - doesn't really do that much as far as I can tell. I'll look at it more in a bit, because...
  • I decided to take a half day, because I'm really feeling like I need the real stuff rather than the piecemeal bits that I'm looking at here. Gives me chance to catch up on some home chores too.

Plans for tomorrow

  • Look through NPS and document it properly.
  • Modify the scripts to start and stop the NPS Sim server too
  • Really dive into the config to see what it does - more concerned with the PDD side of things than DCI / NPS
  • Start stripping away the stuff that we don't immediately need for ACS Test Harness
  • Broad design for the java CIS Sim server, with respect to ACS dev testing

Day 4: 09/09/2021

  • So, I got all of this up and running on Linux too - actually makes the terminal and python run much smoother - it's kinda built for that sort of environment.
  • I did an analysis of the two server files and deleted (pretty much) everything which they don't use. Quite a bit easier to see what's there now.
  • I also analysed NPS as much as I could without a valid config to use or example client calls. This is available at Notes/NPS Handling

The rest of the day

I want to start designing really, so I'm going to spend some time with pen and paper to see what I can come up with in the next couple of hours.

Day 5: 10/09/2021

Reflections on yesterday

So the design that I put together yesterday was a bit... well, "simplistic", I guess. 

Server -> URLMatcher -> TxnTypeHandler -> Validator -> ...
                        |- DCIHandler     |- HeaderValidator
                        |- PDDHandler     |- ContentValidator
                        |- NPSHandler     |- OtherThingsValidator

No real notion of how to configure all of this... and, if I'm honest, still no real notion of what we will be testing.

"Given input X, ensure output of Y"

To be honest, this won't be doing much testing work itself beyond:

  • Is ACS using certs correctly?
  • Is ACS sending correct header values
  • Is ACS sending appropriate content

So, we need to ensure that we can configure:

  • Certs to use
  • Header checks against... what? URL?
  • Content checks, and how to take what's given and reflect it back in the response.

To be honest, for all the hackiness of Mark's code, it's pretty solid and does the job. Once you trim away all the unnecessaries, you could strip it down to quite a simple few program files and wrap a couple of bash scripts around it to do the dirty work.

So the real benefit that I will be adding, I think, isn't the java version of CISSIM, but the containerised images. I think I can define a network within the docker containers which will allow us to use the runtime hostnames / URLs, so we can run ACS as close to a real deployment as possible.

Reflections on today

OK, so I've implemented a first draft of a java-based server. See the JCIS Test on Gitlab. It's really really basic - just a proof of concept of an HTTPS server which uses PEM files, really.

Most of the heavy lifting is done by the SSL Context Kickstart library - it makes it pretty easy to generate an SSLContext using PEM files for keys and certificates.

The rest is the very simplistic HttpsServer provided in java. I don't think this will be the solution going forward; I just wanted a very straightforward implementation that I could get up and running without a load of boilerplate or 'magic code' so I could concentrate on getting the PEM handling working.

Next steps

So, there's quite a bit to do, really.

  • Clean it up - the code's a disgrace ("listenAndTing", really?)
  • Fully implement the handler for DCI908, and, in so doing, introduce a semi-sensible architecture for handling HTTP calls
  • Implement DCI913 and DCI923 in the same way
  • Using (possibly extending) the above mechanism, implement PDD and NPS
  • Separate the handling from the server implementation - as little hardwiring as possible
  • Implement using a different server implementation - a spring boot one perhaps - wrapping jetty or tomcat

The above will probably take me at least a week to nail it. But we should be in a pretty good place by the end of it - with a test server more or less there, and we can start expanding it to cover all the test cases we need.

Week 2: 13/09/2021-19/09/2021

Day 6: 13/09/2021

Today I have been mostly... config loading.

I've been working through the loading of the config file as seen in the CISSIM program. It's almost there, at time of writing; I need to figure out how best to represent the replacement configs (just lists of lists of strings keyed against maps of tuples of strings in the python version, which is... fine, but it means everywhere needs to know the format of everything).

Once that's done, I'll be rejigging it to try and get the specification away from the implementation, so that we can drop in a different implementation (JSON, YML, XML, whatever) and we have a spec and set of tests to run it against.

After that, I'll need to implement a full DCI call with querying the config entries, replacing values, etc. The config needs to be in place for that.

After that, I'll turn to PDD and NPS to do the same for them.

I'm still happy with the COP 15/09 for finishing this - at least to the point where it's usable as an ACS CIS-replacement server. I suspect configurable pauses won't be there by then, but that should be pretty trivial to implement.

Day 7: 14/09/2021

Plan

So I realised last night that PDD will require loading of data definitions, so the config is going to be a way off yet. I'm going to get DCI working end to end before I tackle that, I think.

In that vein, I'm going to be finishing off the config (for DCI) this morning - just the replacement handling to go. Once that's complete, I'll get all the processing up to speed - never used XPath in java, so that'll be fun.

Finally, I'll be wiring up the https server to the processing / config and watching it go.

Hopefully, I'll get all this done by COP today, leaving tomorrow to tackle PDD.

HAHAHAHHAHAHAHA.

So that didn't happen. I spent most of this afternoon single-stepping through Apache Xalan (XPath) code trying to figure out why my fairly simple query wasn't working. It wasn't working because I'd loaded the wrong XML file (request, not response).

sigh

Anyway; just getting DCI done is now going to be the best I can hope for tomorrow... I'll have to leave PDD until I get back; hopefully that will be on my shiny new (old) Macbook - we'll see.

Day 8: 15/09/2021

15:15: Well, the DCI handler is almost there. I'm still messing around with the XML handling, but should be done before too long.

I've cleaned up some of the code, but it needs a deeper clean than it's had, and I could do with scripts to start and stop it, and to figure out how to feed in the config(s).

Once I'm done, I'll need a day or two to clean up the code properly - separate things out so they are pluggable in and out, then get PDD done.

So I'm a little behind schedule, but I'm not hugely concerned. Considering I don't even have a macbook yet, I'd say I've not done too bad.

I'll be closing up shop in a couple of hours; I'll add a quick "where I got to before my holidays" before I jet (rail) off tomorrow morning.

Day 9: 16/09/2021

On leave

Day 10: 17/09/2021

Still on leave

Week 3: 20/09/2021-26/09/2021

Day 11: 20/09/2021

Paved with good intentions

OK, so I didn't get done last week like I wanted to.

So today I'm going to finish off this DCI server. I'm currently sorting out some XML stuff - the search "{namespace}:{localname}" thing doesn't work as simply in java as it does in python (the XPath support in vanilla java is pretty creaky). However, it's much quicker anyway to just use the XML DOM method to walk the document, rather than XPath with such a simple query, so I'm reworking it to use that instead.

After that, I should be able to plug in the replacement code pretty quickly and get this turned around.

I'm very much hoping to have DCI feature-complete by the end of the day. I'll try and keep this diary up to date when I hit any milestones.

I neglected to update this last night, so... very quickly:

I finished the DCI handling but it is entirely untested. Tomorrow I've set aside the day to run through some tests, get the config data in place (i.e. all the response files, stub config, etc) and then get a basic script going so it can be started and stopped relatively easily.

Day 12: 21/09/2021

As mentioned in yesterday's entry, today is about fixing the inevitable issues in the DCI handling, getting the config elements in place and putting together a start/stop script for the server.

I've created a skeleton script, with placeholders for the actual starting and stopping (and querying status) of the server. I've held off from putting that in yet for a couple of reasons:

  • Can't really start it until all the example response files are somewhere, and I've still not 100% determined how they should be handled
  • I'm not sure where to put the lockfile for ensuring that the server only starts once

I may just skip the lockfile for now, or put it somewhere arbitrary and figure out a better location later. Anyway, my main thing now is getting the response files in place, getting the stub config loaded correctly and then pelting it with the (4) examples that I've got and making sure that the XML manipulation is working correctly.

Once that's done and I have a rudimentary script up and running, I want to start cleaning the code and adding unit tests for the stuff that's there - they are almost nonexistent at the moment (TDD for the win!) so that needs sorting.

I ended up taking a half day yesterday, so I never got this finished. And...

Day 13: 22/09/2021

...I'm kind of benched at this point. It's been made clear to Liz & Nigel that I should not be writing anything that might be coming into the DWP. I'm not allowed any code / test cases... even specifications are disallowed. Ludicrous.

Anyway, there's little point in doing very much so I'm just going to park this where it is - I still have the meeting next Friday with Mark H; I'm half-tempted to just quit - wading through the DWP's ineptitude is far more work than I remember, and I find I don't really have the patience for it any more.

Day 14: 23/09/2021

Benched

Day 15: 24/09/2021

Benched

Week 4: 27/09/2021-03/10/2021

Day 16: 27/09/2021

Not officially working

News, though: my Macbook is ready to pick up at the tech bar, on Friday 1st October at 11am.

So I should be properly up and running at that point.

I might put a few hours in before that to give me a head start. If I do, I'll update here with details.

So I did do, so here's some details.

The server is up and running and handling DCI calls. It's all a bit clunky at the moment; the start/stop scripts aren't tied in - indeed "kill -9"-ing the process is still the only way to get rid of it.

I've moved config around quite a bit; there's the concept of a 'config directory' now, under which all other config lives. The config directory is provided as an argument to the server, or defaults to ${JCIS_HOME}/config (IIRC). The response files all sit in the responses.d directory underneath that. They are not currently date/time-sensitive, and there are no triggered reloads or anything like that. All very vanilla.

I'm not really happy with the config yet, but it's taking shape; better than it was? Well, maybe more structured anyway. There's a few classes going in to help with config directories and such like.

One thing to note; the HttpsServer that I'm using doesn't handle curl very well - it will hang with 100% CPU after handling the first request that curl sends. This is apparently a problem with socket management in TLS1.3 vs TLS1.2. I don't really understand it, but apparently JDK-8208526 explains it some.
The workaround is to set the JVM variable: -Djdk.tls.acknowledgeCloseNotify=true.

I wish I understood it better - I'd need to dive deeper into the HttpServer class and the SSH handling to do so, and odds are that we won't be using that going forward, so I probably won't... something to be aware of, though.

Next steps are:

  • Get the scripts starting and stopping the server
    • Indeed, implement a mechanism for stopping the server
  • Clean up the code and organise it better

Day 17: 28/09/2021

Day 18: 29/09/2021

Day 19: 30/09/2021

Day 20: 01/09/2021

Retrieved from "https://wiki.panglossian.net/wiki/index.php?title=Noctam/DWP/ACS_Test_Harness/Diary&oldid=341"