On Wed, Oct 12, 2016 at 9:57 AM, Tomas Kral <tk...@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:

import "github.com/openshift/origin/pkg/cmd/util/clientcmd"
​
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 (
  “k8s.io/kubernetes/pkg/client/restclient"
  “github.com/openshift/origin/pkg/cmd/util/clientcmd"
)
config, err = restclient.InClusterConfig()
client, err = osclient.New(config)

Hope this helps.

On Tue, Oct 11, 2016 at 9:05 PM, Clayton Coleman <ccole...@redhat.com>
> wrote:
> > Once it settles, yes.
> >
> >> On Oct 11, 2016, at 9:34 AM, Jimmi Dyson <jdy...@redhat.com> wrote:
> >>
> >>> On 11 October 2016 at 17:23, Tomas Kral <tk...@redhat.com> wrote:
> >>>> On Tue, Oct 11, 2016 at 3:26 PM, Dan Mace <dm...@redhat.com> wrote:
> >>>>> On Tue, Oct 11, 2016 at 9:12 AM, Andy Goldstein <agold...@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
>
_______________________________________________
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Reply via email to