In order to allow for rapid testing of profiles and Edward features, it may be useful to have the option to skip the build step when launching.

A flag should be added to allow the default timeouts for starting and stopping services to be overriden.

One some slower machines running larger services, 30s isn't sufficient.

The first attempt to stop a service should always be with an interrupt (ctrl+c equivalent), but this may not actually stop the service.

If a service takes more than a certain amount of time to stop (configurable with a sensible default), it should be forcibly killed (kill -9 equivalent).

When running the generate command, if a list of service names are passed, only services with those names should be generated. This will allow for adding a service that is ready for wider testing, without adding half-complete and false-positive services.

If no services by that name are found, Edward should error out.

It is possible for a group to reference itself, or another group that references itself.

Edward should detect such cycles and error out appropriately.

The group would always have precedence.

The generate command can do a lot of work in a short space of time, so it makes sense to make it interactive for most usage.

The user will first be prompted to confirm the config file that will be updated.

An initial pass will be made, and a list of services (with some additional information, such as generator type) will be output for confirmation before they are written to the config file.

It should be possible to disable these prompts with a flag.

In order to maintain expectations, this should be done before anyone gets any ideas about putting edward into a CI workflow.

Add a column to the status table that shows the ports on which a service is listening, which will be useful for debugging bind issues and reminding oneself of which ports are used by a service.

This list could be limited to 5 ports to avoid bloating the table. If a single service is displayed, a longer list can be shown.

Add "platform" property to service/group configuration that allow them to be ignored on non-supported platforms (this way we can have separate configurations for rabbitmq on OSX and Linux).

If omitted, all platforms are supported.

Ideally it would be possible to both blacklist and whitelist platforms.

If a service is disabled for the current platform, and no second service with the same name is provided, it will not result in a config error if that service is named in a group.

If a service is disabled for the current platform, but a second service with the same name is enabled, then the enabled service takes precedence and there is no error.

Platform detection can be achieved using GOOS.

If a service already exists, but you want to regenerate it, the generate command should have an option to permit forcing the generation and overwriting of the existing service.

For context, it would be useful to have a copy of the full set of arguments to edward on each run.

A property should be added to Edward config files to specify the minimum version of Edward that is required for the config file to work.

Either check a port exists, or check that a particular HTTP path on that port returns 200.

It can sometimes be desirable to apply environment variables to a group of services, but not necessarily to those services when they're run in isolation.

The service group object should allow for an env property.

Some go packages (such as sites-cfg and leroy) don't make sense as services, but generate will add them to the config file due to their being a main package.

It should be possible to ignore these directories, either through configuration or an .edwardignore file similar to Git ignores.

It looks like the Travis build is failing because the services are not being created in the same order as expected.

This can be remedied by sorting the service list by name.

https://travis-ci.org/yext/edward/builds/149616382

Got this error when trying to build on my personal computer. Seems that the file doesn't exist and it is failing rather than creating the file

On every operation, Edward should check if a newer version is available (based on Git tags), and display a message suggesting upgrading if there is a newer version.

This check should be cached for an hour to prevent unnecessary calls to Git and possible exceeding of the limits.

Only display the services that actually stopped.

Generated services added to an existing config file should not include env variables in the Env property of the config file.

The update check is performed at the end of executing the command, which can delay a clean exit.

The check should be triggered at the beginning of main, in a goroutine, which the app will wait on at the end of main before outputting any results.

Hashicorp's HCL may be a decent alternative to bare-JSON config.
https://godoc.org/github.com/hashicorp/hcl

See this article for a roundup of comment-preserving issues in config formats:
https://kev.inburke.com/kevin/more-comment-preserving-configuration-parsers/

We use edward to start up play services. The launch step simply starts up the play process, after that it takes a while to actually startup a play service. This is usually due to all the initialization code that play has to run before it can serve it's first request.

The idea is to add a "warmup" step in edward which could be as simple as just hitting a pre-configured url to get that play service to startup and be ready to serve requests without a long pause.

One idea would be to start by adding a warmup-url param in the config file, which edward would hit after an edward is done with the launch phase of an application.

Once a service has been detected as started (via its start log message), the goroutine that waits for it to exit will stay around, which can cause a confusing error (negative wait group counts) should it subsequently fail.

The routine that waits for the service to exit should not error out or report done if this service has already been reported as started, although another error should be reported if possible.

Reproduction steps

Can check for haproxy processes with:
$ ps aux |grep -i haproxy
Before a run, verify there are none running.

$ edward start haproxy
$ ps aux |grep -i haproxy
$ edward stop haproxy
$ ps aux |grep -i haproxy

Can see that 3 processes are still running after the stop.

The Edward config file has no documentation at present, a .md file in a docs/ directory would likely be a big help.

Some things to call out:

• Shared environment variables with the env array
• Imports and how they are processed (every config file imported can see the services and groups in the parent and all other imported files)
• The requiresSudo flag (when supported)
• Custom stop commands

In order to speed up the startup process, it would often be nice to be able to parallelize the build and launch process.

This has to be carefully managed to avoid unintended clashes (particularly with alpha), and ensuring availability of dependencies when starting services in order.

One option may be to include a flag in groups to say whether their services can be parallelized or not.

The go generator is currently hard-coded to only look in the yext folder. Ideally, the whole $GOPATH/src folder should be searched, with appropriate ignore configuration to prevent 3rd party projects being picked up.

If a service is included as a child before a group in a group definition, the group will be started first.

The order in the file should be respected.

Either through a flag or reserved option for the restart command.

This would require knowledge of the groups that were used to start each service to ensure they were restarted in the right order.

~/.edward/edward_logs/edward.log can get very large and difficult to follow.

This should ideally be rotated into daily files, perhaps even separated into folders by year and month.

When running restart, any failure in trying to stop a service is ignored and treated as that service not running. In the event that a service cannot be stopped (permission issues, for example), this may result in the subsequent start failing with confusing symptoms.

Failure to stop should only be ignored iff the service in question had neither a pidfile, nor an associated process when restart was called.

Only a few services need sudo in order to be managed, and some users have their password cache duration set pretty low, so are being prompted unnecessarily.

Services currently allow for a requiresSudo property, but this isn't acted upon. Calls to start/stop/restart should check if any services they're acting upon have this set to true before calling ensureSudoAble()

When starting a group everything is first built before launching anything. This is super unfortunate when something at the end of the group fails, causing the next try to rebuild everything again. It would be great if each item performed build then launch, instead of build, build, build, etc then launch, launch, launch, etc.

This would allow only rebuilding/launching the smaller subset of service(s) that failed, while the successful ones stay running.

Low priority, but Revel projects are not picked up by the generators, so have to be added to config manually.

It's unlikely we'll add any more such projects, but it may be a timesaver for existing projects and shouldn't be a huge change.

Example:
MY_ENV_VAR=value edward start serviceNeedingSudo

I know the use of local vs. office RabbitMQ has gone back and forth recently. It would be nice if there was a way to specify which to use (override default of office) on service starts.

Perhaps if rabbitmq is started within a group then all services in that group should use the locally start one.

Should edward hang while starting a service, there is no debug information output. In such situations, before exiting, edward should output the log from the service it is currently waiting for, both to the console and edward.log.

The cli package supports bash autocompletion: https://github.com/urfave/cli#bash-completion

Being able to autocomplete services and groups would save even more time!

It would cool to be able to stop all running services.

For example if development doesn't require anything to be running, bunch of local services could make memory-hogging IDEs like eclipse even more painful.

Maybe there's a way to do this already? Other than something like edward status | awk '{print $2}' | grep -v -e '^$' | grep -v NAME | xargs edward stop

Edward searches for config in the following locations:

• Working directory
• Git root from working directory
• ~/.edward

Because not all environments have monorepos, it makes sense to search through the parent directories from the working directory rather than the Git root.

As a brute force way of using your directory structure to group services, if you have a parent edward config, and you're in a subdirectory, running edward start with no parameters should start all known services below the current working directory.

Should add a prompt if this is a large number of services.

In order to help debug issues on different environments, Edward should create a detailed log file under ~/.edward.

This should cover:

• Time of each call
• Command executed
• Trace of operations
• All errors
• Events such as clearing PIDfiles on a reboot and the uptime information used to trigger this

goreportcard (https://goreportcard.com/report/github.com/yext/edward) lists a 33% score with golint.
Where possible, these warnings should be addressed.

The local rabbitmq flag is currently set for all generated services, which is Yext specific and covered by the in-house config file.

This should be removed.

In some places (such as the service path for generated services), the $ALPHA env variable is used explicitly.

These references should be removed.

At minimum, a build and test should be run for each commit with Travis.

Once a service has been built it should be possible to launch it in the background while the next service builds.

However, the launches should still run in series, so only one worker should be available for this task.

There is currently a mix of errgo and no specific error handling.
Error handling should be standardized across the project.

pkg/errors is a possible avenue to explore.