kitura / cloudenvironment Goto Github PK

Kubernetes deployments use configuration maps to store credentials or other configuration information to the nodes. We should allow CloudConfiguration to pull information from that source, if on K8 and available.

@rolivieri

We can use a guard as a way to consolidate the code (similar to what a try/catch block does).

Note that this is an API change (requires bumping up the major number).

In other words, instead of:

if let psqlService = ConfigurationManager.getPostgreSQLService("MyPostgreSQLService") {}

You can simply do:

if let psqlService = ConfigurationManager.getPostgreSQLService() {}

The rationale is that the majority of projects will only have a single database of that given type in the application that has been configured. So we should have this option available to them.

If both modules CoudEnvirnment and Kitura-Credentials (Credentials) is imported, the type Credentials is ambiguous for the compiler. It looks like it's a compiler limitation https://bugs.swift.org/browse/SR-6705 so It may be a good idea to address the issue on the source level. Since CloudEnvironment is often used with the Kitura framework, it may be a good idea to clarify the Credentials type.

Kitura-Credentials report: Kitura/Kitura-Credentials#36

import CloudEnvironment
import Credentials

public class App {
    let credentials: Credentials.Credentials
}

Application.swift:18:22: error: 'Credentials' is ambiguous for type lookup in this context
    var credentials: Credentials.Credentials
                     ^~~~~~~~~~~
CloudEnvironment.Credentials:4:14: note: found this candidate
public class Credentials {
             ^
Credentials.Credentials:2:14: note: found this candidate
public class Credentials : RouterMiddleware {
             ^

In some places, bluemix.net is hardcoded. At the minimum, this must be upgraded to cloud.ibm.com, if not removed entirely.

PushSDKCredentials.swift - CloudEnvironment can be used on other cloud providers (esp given OpenShift will be coming…) but in this code I see “bluemix.net” hardcoded - is that supposed to be there?

   guard let host = url.host,
     host.hasSuffix(“.bluemix.net”)
   else{
     return nil
   }
   let parts = host.split(separator: “.”).suffix(3)
   guard parts.count > 2 && parts.first != “imfpush” else {
     return nil
   }
   return parts.joined(separator: “.”)
 }```

There are currently no tests for either cloudEnv.getDictionary(name: String) or cloudEnv.getString(name: String) we should add these in.

It would be nice if CloudConfiguration maintained some level of back-compatibility with Swift. For example, Kitura 1.7 works with Swift 3.0.2 and Swift 3.1.1.

Currently I am seeing the following error when compiling my project on Swift 3.0.2 when using CloudConfiguration 2.x:

/tmp/041ffec28bc23291ae0b059c3a2123aa393d3991/swiftserver/Packages/CloudFoundryEnv-4.0.2/Sources/CloudFoundryEnv/AppEnv.swift:184:23: error: use of unresolved identifier 'NSRegularExpression'
      let regex = try NSRegularExpression(pattern: spec, options: NSRegularExpression.Options.caseInsensitive)
                      ^~~~~~~~~~~~~~~~~~~
Foundation.RegularExpression:1:12: note: did you mean 'RegularExpression'?
open class RegularExpression : Foundation.NSObject, NSCopying, NSCoding {
           ^
/tmp/041ffec28bc23291ae0b059c3a2123aa393d3991/swiftserver/Packages/CloudFoundryEnv-4.0.2/Sources/CloudFoundryEnv/AppEnv.swift:184:67: error: use of unresolved identifier 'NSRegularExpression'
      let regex = try NSRegularExpression(pattern: spec, options: NSRegularExpression.Options.caseInsensitive)
                                                                  ^~~~~~~~~~~~~~~~~~~
Foundation.RegularExpression:1:12: note: did you mean 'RegularExpression'?
open class RegularExpression : Foundation.NSObject, NSCopying, NSCoding {
           ^
<unknown>:0: error: build had 1 command failures

Right now, CloudConfiguration relies very heavily on the conventions of VCAP_SERVICES. We should allow the configuration information to come from not only a path inside VCAP_SERVICES, and instead multiple paths that could be compatible with other platforms like Heroku, Amazon AWS, and our Docker deployment.

In other words, we should should support loading files with data that has been the result of something like this:

cf env MyApp > config.json

But often times, the user will want something even easier, especially the Docker case:

Some examples:

I think that a typical config.yml used for a Docker deployment could look like:

- port: 8080
- services:
    - postgresql
        - username: robert
        - password: pa55w0rd
        - hostname: postgresql.bluemix.net 

• Add AppID to CloudConfiguration
• Add AppID partial to the generator-swiftserver
• Add AppID partial to generator-web

Hello @youming-lin, do you have bandwidth to tackle this work item this week?

Configuration allows for a very rich way to specify multiple sources for configuration information with priority ordering. However, for many applications, a convention that does the equivalent of:

let config = ConfigurationManager
                                 .load(file: "config.json")
                                 .load(.environmentFiles)
                                 .load(.commandLineArguments)

So that the user simply has to do:

let config = ConfigurationManager.default()

Kitura-Redis expects Int32 for the port and as a result using the service and getting the port from it causes a compilation error:

redis?.connect(host: redisService.host, port: redisService.port) { (redisError: NSError?) in