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
