[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: OpenShift go client library





On Wed, Oct 12, 2016 at 9:57 AM, Tomas Kral <tkral redhat com> wrote:
Thank you all for help with this. I managed to get all the
dependencies to fit together.

Now I'm having problem with my code :-(

I've created small program to test it. My goal is to create OpenShift
client configured according to `~/.kube/config` (same as oc).
My test code looks like this:

package main
import (
    "fmt"
    kapi "k8s.io/kubernetes/pkg/api"
    "github.com/openshift/origin/pkg/client"
    "github.com/openshift/origin/pkg/cmd/util/clientcmd"
)

func main() {
    factory := clientcmd.NewFactory(nil)
    clientConfig, err := factory.ClientConfig()
    if err != nil {
        panic(err)
    }
    client := client.NewOrDie(clientConfig)
    dcs, err := client.DeploymentConfigs("asdf").List(kapi.ListOptions{})
    if err != nil {
        panic(err)
    }
    fmt.Printf("%#v", dcs)
}


When I run this I get:
panic: the server could not find the requested resource

I've intercepted traffic to OpenShift server and i can see that this
client is connecting to k8s api (/api) instead of OpenShifts (/oapi).
I expect that I'm doing something wrong,  but don't have any idea what :-)


​Try instantiating a client like this:

config, err := clientcmd.DefaultClientConfig(pflag.NewFlagSet("empty", pflag.ContinueOnError)).ClientConfig()
client, err := osclient.New(config)

This method will honor KUBECONFIG if present, and is also capable of creating a client using whatever oc client context is currently in use within the program’s environment. This is very useful for testing as you can `oc login` in the shell, run your program, and your program will use the context established by `oc login`.

If your program ever needs to run inside a pod in a container in OpenShift connecting via a service account, you can use this to create the client:

import (
)
config, err = restclient.InClusterConfig()
client, err = osclient.New(config)

Hope this helps.

On Tue, Oct 11, 2016 at 9:05 PM, Clayton Coleman <ccoleman redhat com> wrote:
> Once it settles, yes.
>
>> On Oct 11, 2016, at 9:34 AM, Jimmi Dyson <jdyson redhat com> wrote:
>>
>>> On 11 October 2016 at 17:23, Tomas Kral <tkral redhat com> wrote:
>>>> On Tue, Oct 11, 2016 at 3:26 PM, Dan Mace <dmace redhat com> wrote:
>>>>> On Tue, Oct 11, 2016 at 9:12 AM, Andy Goldstein <agoldste redhat com> wrote:
>>>>>
>>>>> We don't currently have a standalone go client library. Your best bet, for
>>>>> now, is to use Godeps to vendor in the same versions of dependencies that
>>>>> OpenShift currently uses.
>>>>>
>>>>> Andy
>>>>
>>>>
>>>> The way we handle this for various OpenShift Online components (which use
>>>> not only the client libraries but also other supporting data structures,
>>>> controller framework pieces, etc) is to use godep to restore origin’s
>>>> dependency tree into GOPATH and then vendor things back into our own
>>>> project. It’s pretty involved, but the overall steps are:
>>>>
>>>> 0. Using a clean GOPATH…
>>>> 1. Clone origin to $GOPATH/src/github.com/openshift/origin
>>>> 2. Clone kubernetes to $GOPATH/src/k8s.io/kubernetes
>>>> 3. Add and fetch a kubernetes Git remote at
>>>> https://github.com/openshift/kubernetes
>>>> 4. Use the origin `hack/move-upstream.sh` script to apply patches that
>>>> Origin carries to its various dependencies
>>>> 5. Use the origin `hack/godep-restore.sh` script to reconstitute all of
>>>> Origin’s dependencies within GOPATH
>>>> 6. Update any packages within GOPATH whose versions we want to override from
>>>> Origin
>>>> 7. Use `godep save ./…` in our own package within GOPATH to vendor our
>>>> dependencies from GOPATH
>>>
>>> This is really far from ideal :-(
>>> It forces me to use other libs that are forked by OpenShift, like
>>> github.com/openshift/glog :-(
>>> I have to manage my own godep-restore.sh for my project :(
>>
>> We use https://glide.sh/ for vendor management which works great with
>> forks - using godep was such a pita for the many forked repos that
>> openshift requires.
>>
>> I believe there are plans upstream to switch from godep to glide so
>> assume openshift will do the same in future?
>>
>>>
>>>>
>>>> Obviously this is far from ideal, but works and ensures our code is
>>>> compatible with a specific of origin and all its transitive dependencies.
>>>> There are some finer details omitted here (especially around
>>>> `hack/move-upstream.sh`). Feel free to reach out if I can provide further
>>>> clarifications. Good luck!
>>>>
>>>> —Dan
>>>>
>>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev lists openshift redhat com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>> _______________________________________________
>> dev mailing list
>> dev lists openshift redhat com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]