Conversation
|
@astromechza this is a draft like a starting point. I have exposed type and class on the interface can you take a look and let me know if I am on the good track or if it could have a cleaner way to achieve it before I move forward. also output with current implementation: go run cmd/score-compose/main.go provisioners list
INFO: Listing provisioners in project 'test1'
INFO: Class: (any), Type: volume
INFO: Class: (any), Type: service-port
INFO: Class: (any), Type: redis
INFO: Class: (any), Type: postgres
INFO: Class: (any), Type: s3
INFO: Class: (any), Type: amqp
INFO: Class: (any), Type: dns
INFO: Class: (any), Type: route
INFO: Class: (any), Type: mongodb
INFO: Class: (any), Type: mysql
INFO: Class: (any), Type: kafka-topic
INFO: Class: (any), Type: elasticsearch
|
|
Last changes pushed give go run cmd/score-compose/main.go provisioners list
INFO: Listing provisioners in project 'test1'
+-------+-----------+--------------------------------+
| TYPE | CLASS | OUTPUTS |
+-------+-----------+--------------------------------+
| mysql | (any) | host, port, name, database, |
| | | username, password |
| mssql | database | server, port, connection, tcp, |
| | | database, username, password |
| mssql | database | server, port, connection, tcp, |
| | | database, username, password |
| amqp | messaging | host, port, vhost, username, |
| | | password |
+-------+-----------+--------------------------------+ |
|
@astromechza could you have a look and tell me if I am on the good track or if you see a more elegant way to extract outputs value ? |
|
also all tests are ok matthieu@pop-os:~/Repos/github/score/score-compose$ go test ./...
? github.com/score-spec/score-compose/cmd/score-compose [no test files]
? github.com/score-spec/score-compose/internal/logging [no test files]
? github.com/score-spec/score-compose/internal/project [no test files]
ok github.com/score-spec/score-compose/internal/command 3.351s
ok github.com/score-spec/score-compose/internal/compose (cached)
ok github.com/score-spec/score-compose/internal/provisioners (cached)
ok github.com/score-spec/score-compose/internal/provisioners/cmdprov (cached)
ok github.com/score-spec/score-compose/internal/provisioners/envprov (cached)
ok github.com/score-spec/score-compose/internal/provisioners/loader (cached)
ok github.com/score-spec/score-compose/internal/provisioners/templateprov (cached)
ok github.com/score-spec/score-compose/internal/util (cached)
ok github.com/score-spec/score-compose/internal/version (cached) |
|
With latest changes I have params also +--------------+-----------+------------------+--------------------------------+
| TYPE | CLASS | PARAMS | OUTPUTS |
+--------------+-----------+------------------+--------------------------------+
| mysql | (any) | | host, port, name, database, |
| | | | username, password |
| mssql | database | | server, port, connection, tcp, |
| | | | database, username, password |
| route | (any) | port, host, path | |
| mssql | database | | server, port, connection, tcp, |
| | | | database, username, password |
| amqp | messaging | | host, port, vhost, username, |
| | | | password |
| service-port | (any) | workload, port | hostname, port |
+--------------+-----------+------------------+--------------------------------+ |
delca85
left a comment
There was a problem hiding this comment.
Changes look very good, I'd propose to add some unit tests for the more complex provisioner to check their behaviour in isolation.
|
thanks @delca85 I'll add more tests on both |
66d84af to
10d5089
Compare
|
Another thoughts, @lekaf974, I'm wondering if sorting alpabetically both the |
Perfect will see how I can do it |
|
lastest output after applied changes requested ~$ score-compose provisioners list
+---------------+-------+------------------+--------------------------------+
| TYPE | CLASS | PARAMS | OUTPUTS |
+---------------+-------+------------------+--------------------------------+
| amqp | (any) | | host, password, port, |
| | | | username, vhost |
+---------------+-------+------------------+--------------------------------+
| dns | (any) | | host |
+---------------+-------+------------------+--------------------------------+
| elasticsearch | (any) | | host, password, port, username |
+---------------+-------+------------------+--------------------------------+
| kafka-topic | (any) | | host, name, num_partitions, |
| | | | port |
+---------------+-------+------------------+--------------------------------+
| mongodb | (any) | | connection, host, mongodb, |
| | | | password, port, username |
+---------------+-------+------------------+--------------------------------+
| mysql | (any) | | database, host, name, |
| | | | password, port, username |
+---------------+-------+------------------+--------------------------------+
| postgres | (any) | | database, host, name, |
| | | | password, port, username |
+---------------+-------+------------------+--------------------------------+
| redis | (any) | | host, password, port, username |
+---------------+-------+------------------+--------------------------------+
| route | (any) | host, path, port | |
+---------------+-------+------------------+--------------------------------+
| s3 | (any) | | access_key_id, |
| | | | aws_access_key_id, |
| | | | aws_secret_key, bucket, |
| | | | endpoint, http, region, |
| | | | secret_key |
+---------------+-------+------------------+--------------------------------+
| service-port | (any) | port, workload | hostname, port |
+---------------+-------+------------------+--------------------------------+
| volume | (any) | | source, type |
+---------------+-------+------------------+--------------------------------+ |
|
@lekaf974 @astromechza, in addition to this default table format (awesome!) and out of curiosity, |
Perhaps we could do it in a second Ticket ? But I could add it here, it looks not a big work since we have already the data |
Yes for sure, totally fine with that. Up to you ;) |
I am happy to contribute, i am trying to improve my development skills in Golang so just give it a try! |
|
Any updates ? |
|
@astromechza, one last review on this one please? Thanks! |
astromechza
left a comment
There was a problem hiding this comment.
Sorry I've been slow, been on holiday, but getting back now!
| return []string{} | ||
| } | ||
| re := regexp.MustCompile(`\w+:`) | ||
| matches := re.FindAllString(p.OutputsTemplate, -1) |
There was a problem hiding this comment.
I'm sorry I've been slow getting back to this, but this has flaws and is an NP-hard problem in general (you can't know the result without evaluating the template). The Params() function above has the same issue.
Please just hardcode the expected outputs and supported parameters as fields in the provisioner, and backfill the existing default provisioners to have the correct values.
This makes it simpler, and means we can enforce the values elsewhere in score-compose (probably in a separate ticket):
- During provisioner execution, we can validate that the parameters passed in are all in the
Params()list of the provisioner. - After provisioner execution, we can validate that the outputs returned from the driver are all in the
Outputs()list.
There was a problem hiding this comment.
I'll take a look during next week on your point, thanks for feedback
There was a problem hiding this comment.
Cool, sorry for the run-around on this :)
There was a problem hiding this comment.
@astromechza I was not able to work on this last week but got time now. Can you give more details about what you have in mind here
Please just hardcode the expected outputs and supported parameters as fields in the provisioner, and backfill the existing default provisioners to have the correct values.
There was a problem hiding this comment.
@lekaf974 I mean, in the provisioner data structure that we read from yaml, support a supported_params and expected_outputs field, both string arrays.
There was a problem hiding this comment.
@astromechza added expected_output fields, can you confirm I am on the good track before I continue with supported_params
There was a problem hiding this comment.
@lekaf974 yeah this is looking good! just 2 comments now
Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
…s to interface Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
… order Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
b95f63d to
d06efef
Compare
|
Finally added json output support with same fields for now ~$ score-compose provisioners list --help
The list command will list out the provisioners. This requires an active score compose state
after 'init' or 'generate' has been run. The list of provisioners will be empty if no provisioners are defined.
Usage:
score-compose provisioners list [--format table|json] [flags]
Flags:
-f, --format string Format of the output: table (default), json (default "table")
-h, --help help for list
Global Flags:
--quiet Mute any logging output
-v, --verbose count Increase log verbosity and detail by specifying this flag one or more times~$ score-compose provisioners list --format json
[
{
"Type": "amqp",
"Class": "(any)",
"Params": "",
"Outputs": "host, password, port, username, vhost"
},
{
"Type": "dns",
"Class": "(any)",
"Params": "",
"Outputs": "host"
},
{
"Type": "elasticsearch",
"Class": "(any)",
"Params": "",
"Outputs": "host, password, port, username"
},
{
"Type": "kafka-topic",
"Class": "(any)",
"Params": "",
"Outputs": "host, name, num_partitions, port"
},
{
"Type": "mongodb",
"Class": "(any)",
"Params": "",
"Outputs": "connection, host, mongodb, password, port, username"
},
{
"Type": "mysql",
"Class": "(any)",
"Params": "",
"Outputs": "database, host, name, password, port, username"
},
{
"Type": "postgres",
"Class": "(any)",
"Params": "",
"Outputs": "database, host, name, password, port, username"
},
{
"Type": "redis",
"Class": "(any)",
"Params": "",
"Outputs": "host, password, port, username"
},
{
"Type": "route",
"Class": "(any)",
"Params": "host, path, port",
"Outputs": ""
},
{
"Type": "s3",
"Class": "(any)",
"Params": "",
"Outputs": "access_key_id, aws_access_key_id, aws_secret_key, bucket, endpoint, http, region, secret_key"
},
{
"Type": "service-port",
"Class": "(any)",
"Params": "port, workload",
"Outputs": "hostname, port"
},
{
"Type": "volume",
"Class": "(any)",
"Params": "",
"Outputs": "source, type"
}
]
|
Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
| return []string{} | ||
| } | ||
| re := regexp.MustCompile(`\w+:`) | ||
| matches := re.FindAllString(p.OutputsTemplate, -1) |
There was a problem hiding this comment.
@lekaf974 yeah this is looking good! just 2 comments now
Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
|
integrate last changes requested @mathieu-benoit last question what would be the better format {
"Type": "service-port",
"Class": "(any)",
"Params": "port, workload",
"Outputs": "hostname, port"
}or {
"Type": "service-port",
"Class": "(any)",
"Params": [
"port",
"workload"
],
"Outputs": [
"hostname",
"port"
]
} |
|
opening score-spec/docs#161 to update documentation accordingly to those changes |
Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
Signed-off-by: lekaf974 <matthieu.evrin@gmail.com>
|
I would vote for the 2nd which is more |
Yes, it makes sense to me and I changed it this way in the last implementation. |
mathieu-benoit
left a comment
There was a problem hiding this comment.
LGTM, impressive contribution, thanks @lekaf974!
astromechza
left a comment
There was a problem hiding this comment.
Yup, definitely array of strings please @lekaf974. Looks good!
|
Thank you for your contribution @lekaf974 |
Description
What does this PR do?
Fix #237
Types of changes
Checklist: