bwsw / cs-vault-server Goto Github PK

You defined the scope: Zookeeper, but inside the scope you use zooKeeperRootNode, why not to use just rootNode. Change everywhere to be logically motivited. Environment variables should be built like <SCOPE>_<VAR>_<NAME>, e.g. ZOOKEEPER_ROOT_NODE.

Change everywhere!

"Tags were got" is a wrong phrase, use something like "Tags retrieved". I don't think that passive voice in the past are best way to express such great outcome. If you DO debug, why don't you debug actual TAGS that retrieved. What is the case to use such useless debug information??? FIX everywhere.

Right now it uses: vault.ro, vault.rw, but we should be able to configure prefix, like [csext.]vault.ro to reflect external requirements. It should be configured in an config variable like:

TAGNAME_PREFIX=csext

"." (dot) symbol should be appended automatically if trailing dot is missing. By default TAGNAME_PREFIX is just empty.

Which components should be replaced by components from others projects.
Try to divide into tasks.

1. Use Curator for ZooKeeper client wrapping

Accounts and VMs reside in domains, when you request something domain must be specified because without the domain you implicitly work in root domain (ask Elena Ershova if required about domains).

Affected:
https://github.com/bwsw/cs-vault-server/blob/develop/src/main/scala/com/bwsw/cloudstack/vault/server/cloudstack/CloudStackService.scala#L117

Two accounts with the same names might exist in different domains, e.g. root domain and room-1 domain.

1. Create dockerfile for creation docker container by Travis CI, and pushing it to DockerHub

a) Make a test plan
b) Prepare mocks
c) Implement test's cases

May be move even more and add "UUID"? Remove it.

1. Create zookeeper service for write and read znodes with tags from Apache Zookeeper

If there is a reason, comment and describe why it's required.

Add vault.path to place also a keyspace (host, prefix) which is affected by ro/rw keys both to user and vm. See #29 first as it's affected too.

a) Implement negative tests for services
b) Implement negative and positive tests for taskCreators of services

a) Implement the creation and receive of a Token using the vault scala library

1. Create a kafka consumer
2. Implement multi-threaded launch of kafka consumer

Create the application architecture and describe it through UML class diagram.

Why do token period reside inside "app" scope if it relates to vault scope? Fix it.

1. Events: VMCreate, VMDelete, AccountCreate, AccountDelete, UserCreate must be handle by controller

I believe Idea should warn you against use of boolean constant as a in-place argument. Either do

val meaningfulName = true
fun(meaningfulName)

or

fun(funArgument = true)

because tags are unique, List is error prone. Use set.

1. Exclude processing of UserCreate and UserDelete events from EventHandler
2. CloudStackTaskCreator won't be changed
3. CloudStackService — all methods using User should be replaced by "getAccountTags" method
4. CloudStackVaultController — remove "handleUserCreate" method. "handleAccountCreate" method should be implemented as handleVmCreate excluding a part that retrieves "accountId" by "vmId"
5. Remove UserResponse

see #83

see #83 and #84 (#84 is required to be completed)

If the param allows adding more than one server, then the name should be list. Basically, I beliave all where we use list, we should use endpoints, if use one - endpoint

So

Zookeeper {
  endpoints = "zk://127.0.0.1:2181/"
  endpoints = ${ZOOKEEPER_ENDPOINTS}
}

looks fine. Change everywhere. Change environment variables.

1. Create a list of all possible events which can be processed with Vault.
2. Make all actions from the list and study how events are recorded to Kafka and how to read out events from Kafka.

Fix it.

Why it's "var" not "val" btw. Why the name is "threadLocalClientList" is it means something, do you think "clientList" is a bad name for it?

a) Implement the request in ACS to receive all users and their tags for the account
b) Implement the creation of a tags in ACS for token saving

What is the purpose to accept by

class ConsumerManager(topic: String, brokers: String, components: Components)

topic, brokers, components parameters. I don't see the purpose. You are mixing levels of abstraction. Fix it.

Sometimes "StrictLogging" trait is used, sometimes just

  private val logger = LoggerFactory.getLogger(this.getClass)

Is it for a reason? Unify. Don't do the mess.

1. Create Scala application
2. Create application.conf with needed settings
3. Create singleton object for reading settings from application.conf when others objects will apply to get settings