Re: [3.x]: openshift router and its own metrics

2019-08-15 Thread Dan Mace
On Thu, Aug 15, 2019 at 10:03 AM Daniel Comnea 
wrote:

> Hi,
>
> Would appreciate if anyone can please confirm that my understanding is
> correct w.r.t the way the router haproxy image [1] is built.
> Am i right to assume that the image [1] is is built as it's seen without
> any other layer being added to include [2] ?
> Also am i right to say the haproxy metrics [2] is part of the origin
> package ?
>
>
> A bit of background/ context:
>
> a while back on OKD 3.7 we had to swap the openshift 3.7.2 router image
> with 3.10 because we were seeing some problems with the reload and so we
> wanted to take the benefit of the native haproxy 1.8 reload feature to stop
> affecting the traffic.
>
> While everything was nice and working okay we've noticed recently that the
> haproxy stats do slowly increase and we do wonder if this is an
> accumulation or not cause (maybe?) by the reloads. Now i'm aware of a
> change made [3] however i suspect that is not part of the 3.10 image hence
> my question to double check if my understanding is wrong or not.
>
>
> Cheers,
> Dani
>
> [1]
> https://github.com/openshift/origin/tree/release-3.10/images/router/haproxy
> [2]
> https://github.com/openshift/origin/tree/release-3.10/pkg/router/metrics
> [3]
> https://github.com/openshift/origin/commit/8f0119bdd9c3b679cdfdf2962143435a95e08eae#diff-58216897083787e1c87c90955aabceff
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>

I think Clayton (copied) has the history here, but the nature of the
metrics commit you referenced is that many of the exposed metrics points
are counters which were being reset across reloads. The patch was (I think)
to enable counter metrics to correctly aaccumulate across reloads.

As to how the image itself is built, the pkg directly is part of the router
controller code included with the image. Not sure if that answers your
question.

-- 

Dan Mace

Principal Software Engineer, OpenShift

Red Hat

dm...@redhat.com
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


Re: [aos-devel] optimizing go guru

2017-12-05 Thread Dan Mace
On Tue, Dec 5, 2017 at 10:43 AM, Luke Meyer <lme...@redhat.com> wrote:

> In the context of the vim-go plugin. However behavior seems much the same
> if I run the same command at the command line (I pulled it out of ps -ef).
>
> On Tue, Dec 5, 2017 at 10:40 AM, Sebastian Jug <se...@redhat.com> wrote:
>
>> Are you using guru in some sort of editor/IDE or just standalone?
>>
>> On Dec 5, 2017 9:40 AM, "Luke Meyer" <lme...@redhat.com> wrote:
>>
>>>
>>>
>>> On Tue, Dec 5, 2017 at 9:36 AM, Sebastian Jug <se...@redhat.com> wrote:
>>>
>>>> Sounds like you have got auto compile still on?
>>>>
>>>>
>>> What does this mean in the context of go guru? Is there an env var to
>>> set, an option to add, a config file to change to control this behavior?
>>>
>>>
>>
>
​The same query:

guru -scope github.com/openshift/origin/cmd/oc whicherrs
./pkg/oc/admin/diagnostics/diagnostics.go:#7624

was taking long enough for me (go1.8.3 darwin/amd64) that I killed it. It's
hard to say without doing a deeper profile of that guru command. Even with
your relatively narrow pointer analysis scope ​it seems really slow, but
then again it's hard to gauge exactly how narrow that scope is without
looking at a full import dependency graph...

Guru has always been really slow for lots of useful pointer analysis
queries, so I'm not entirely surprised. This is why vscode-go uses a
variety of more optimized special purpose tools for most analysis[1].

[1]
https://github.com/Microsoft/vscode-go/blob/master/src/goInstallTools.ts#L21

-- 

Dan Mace

Principal Software Engineer, OpenShift

Red Hat

dm...@redhat.com
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


Re: OpenShift go client library

2016-10-12 Thread Dan Mace
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

Re: OpenShift go client library

2016-10-11 Thread Dan Mace
On Tue, Oct 11, 2016 at 9:12 AM, Andy Goldstein  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

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




> On Tue, Oct 11, 2016 at 8:15 AM, Tomas Kral  wrote:
>
>> Hi all,
>> is there standalone OpenShift client library for Go?
>> Or what is the best way for writing programs calling OpenShift api.
>>
>> Currently I'm creating OpenShift client and using it like this:
>>
>> import (
>>   github.com/openshift/origin/pkg/client
>>   github.com/openshift/origin/pkg/cmd/util/clientcmd
>> )
>>
>> factory := clientcmd.NewFactory(nil)
>> clientConfig, err := factory.ClientConfig()
>> client := client.NewOrDie(clientConfig)
>>   client.DeploymentConfigs(namespace).Create(dc)
>>
>>
>> But I have problem with
>> github.com/openshift/origin/pkg/cmd/util/clientcmd and
>> github.com/openshift/origin/pkg/client.
>> It looks like they both have
>> github.com/docker/docker/pkg/term/winconsole in their dependency
>> chain.
>> This is creating conflict between github.com/docker/docker versions,
>> because my applications requires newer version of docker, and is no
>> winconsole pkg :(
>>
>>
>>
>> --
>> Tomas
>>
>> ___
>> 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