add BuildConfig support to kompose down

[procrypt]

kompose --provider openshift up
INFO Successfully created Service: foo            
INFO Successfully created DeploymentConfig: foo   
INFO Successfully created ImageStream: foo        
INFO Successfully created BuildConfig: foo 

kompose --provider openshift down
INFO Buildconfig using https://github.com/kubernetes-incubator/kompose.git::master as source. 
INFO Successfully deleted service: foo            
INFO Successfully deleted DeploymentConfig: foo   
INFO Successfully deleted ImageStream: foo        
INFO Successfully deleted BuildConfig: foo   

docker-compose file used is docker-compose.yml

@kadel @cdrage @containscafeine Review please.
Fixes #382

[concaf]

@procrypt mind adding unit tests for this?

[kadel]

@procrypt mind adding unit tests for this?

I'm afraid that we still don't have a way how to test this. :-(
As it will require running or mocking cluster :-(

[procrypt]

@kadel I'm trying something don't know if it the right thing to do, will update the WIP later today.

[concaf]

@procrypt - @kadel is correct, we will need to mock out the entire OpenShift client for this :(

I can think of a couple of ways to go about this -

• mock out just the parts we are testing?
• see in openshift/origin upstream about how are they mocking out the client, and if possible just use that?
• not unit test the deploy bits at all, and rely on functional tests to deploy on the cluster?

I don't know what is the right way forward, but yep, mocking out the entire client might take a sprint or two :)

Thoughts on this? - @surajssd @kadel @cdrage @rtnpro

[pradeepto]

I would recommend either mock required bits of API or see if we can use/reuse bits from openshift.

[cdrage]

@pradeepto @containscafeine no need to "mock" it, you can run an Openshift cluster within TravisCI.

[surajssd]

@pradeepto @containscafeine no need to "mock" it, you can run an Openshift cluster within TravisCI.

@cdrage then that won't be called unit tests right? If we are planning on doing complete e2e test with kompose in golang, which involves bringing up clusters then that should be a complete new thing.
So that will also require writing all the harness code of bringing up clusters.

[pradeepto]

@cdrage What @surajssd said. If we are bringing up oc cluster, then we are adding a dependency on the unit tests which doesn't sound right to me. If the cluster doesn't come up anytime, then the tests will fail which is technically not a test failure but an infrastructure failure.

[cdrage]

@pradeepto Using versioned containers, it's unlikely to fail coming up (from my experience "mocking" the cluster)

[kadel]

I think that we can discuss this elsewhere.

I don't think we have block this PR on tests.
We currently don't have any solution for testing this and this is not adding any new functionality just fixing what was missing so I would say we can merge this. What do you think?

[surajssd]

@kadel +1