Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-04-06 Thread Steve Gordon 
- Original Message -
> From: "Monty Taylor" <mord...@inaugust.com>
> To: openstack-dev@lists.openstack.org
> Sent: Sunday, April 2, 2017 4:16:44 PM
> Subject: Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud 
> Provider for Kubernetes
> 
> On 04/02/2017 02:53 PM, Chris Hoge wrote:
> > Now that the provider has a repository in the OpenStack project
> > namespace, we need to move over the existing set of issues and pull
> > requests and create an initial work list for migrating patches and
> > fixing existing issues.
> > 
> > I've started up an etherpad where we can track that work[1]. In the longer
> > run we should migrate over to Launchpad or Storyboard. One question,
> > to help preserve continuity with the K8S community workflow: do we want
> > to investigate ways to allow for issue creation in the OpenStack
> > namespace on GitHub?
> 
> I do not think this is a thing we want to do. While I understand the
> urge, a project needs to live somewhere (in this case we've chosen
> OpenStack) and should behave as projects do in that location. When I
> work on Ansible, I do issues on github. When I deal with tox, I file
> issues on bitbucket. Back when I dealt with Jenkins I filed issues in
> their Jira. I do not think that filing an issue in the issue tracker for
> a project is too onerous of a request to make of someone.
> 
> We have issues turned off in all of our github mirrors, so it's highly
> unlikely someone will accidentally attempt to file an issue like the.
> (it's too bad we can't similarly turn off pull requests, but oh well)

I agree with the above comments w.r.t. tooling, but I think we will still need 
to determine what I think is at the core of Chris's concern which is in a world 
where we have extracted the cloud provider implementation from Kube (and 
externalizing these from Kube has indeed been on the table for some time, so 
thanks Dims for taking the initiative) how do we continue to work on it in the 
OpenStack community while also still maintaining - if not extending - our level 
of interop and visibility with the Kubernetes community. I think the focus of 
concern here should be less on the tools though - as you note each community 
has its own tools and that is unlikely to change - and more on communication 
but it can be difficult to decouple the two (IRC versus Slack, Zoom, etc.).

Thus far discussion of open PRs/Issues and ongoing work w.r.t. the provider 
implementation has primarily focused on the Kubernetes OpenStack SIG (the scope 
of which was recently extended to allow space for discussions/collaboration 
between the various OpenStack deployment projects and folks anchored in the 
Kubernetes side of things, specifically w.r.t. Helm. It's not immediately clear 
to me how we would prefer to maintain visibility on the Kubernetes side of the 
fence going forward because a natural progression of "this is developed, 
tested, and served up on OpenStack infra" would of course also be to move most 
of these discussions to IRC.

Thanks,

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-04-04 Thread Clint Byrum 
Excerpts from Chris Hoge's message of 2017-04-04 17:09:11 -0400:
> 
> > On Apr 2, 2017, at 4:29 PM, Monty Taylor <mord...@inaugust.com> wrote:
> > 
> > On 03/29/2017 03:39 PM, Steve Gordon wrote:
> >> - Original Message -
> >>> From: "Davanum Srinivas" <dava...@gmail.com>
> >>> To: "Chris Hoge" <ch...@openstack.org>
> >>> Cc: "OpenStack Development Mailing List (not for usage questions)" 
> >>> <openstack-dev@lists.openstack.org>,
> >>> "kubernetes-sig-openstack" <kubernetes-sig-openst...@googlegroups.com>
> >>> Sent: Wednesday, March 29, 2017 2:28:29 PM
> >>> Subject: Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud 
> >>> Provider for Kubernetes
> >>> 
> >>> Team,
> >>> 
> >>> Repo is ready:
> >>> http://git.openstack.org/cgit/openstack/k8s-cloud-provider
> >>> 
> >>> I've taken the liberty of updating it with the latest changes in the
> >>> kubernetes/kubernetes repo:
> >>> https://review.openstack.org/#/q/project:openstack/k8s-cloud-provider is
> >>> ready
> >>> 
> >>> So logical next step would be to add CI jobs to test in OpenStack
> >>> Infra. Anyone interested?
> >> 
> >> One question I have around this - do we have a shared view of what the 
> >> ideal matrix of tested combinations would like? E.g. kubernetes master on 
> >> openstack project's master, kubernetes master on openstack project's 
> >> stable branches (where available), do we also need/want to test kubernetes 
> >> stable milestones, etc.
> >> 
> >> At a high level my goal would be the same as Chris's "k8s gating on 
> >> OpenStack in the same ways that it does on AWS and GCE." which would imply 
> >> reporting results on PRs proposed to K8S master *before* they merge but 
> >> not sure we all agree on what that actually means testing against in 
> >> practice on the OpenStack side of the equation?
> > 
> > I think we want to have jobs that have the ability to test:
> > 
> > 1) A proposed change to k8s-openstack-provider against current master of
> > OpenStack
> > 2) A proposed change to k8s-openstack-provider against a stable release
> > of OpenStack
> > 3) A proposed change to OpenStack against current master of
> > k8s-openstack-provider
> > 4) A proposed change to OpenStack against stable release of
> > k8s-openstack-provider
> > 
> > Those are all easy now that the code is in gerrit, and it's well defined
> > what triggers and where it reports.
> > 
> > Additionally, we need to test the surface area between
> > k8s-openstack-provider and k8s itself. (if we wind up needing to test
> > k8s against proposed changes to OpenStack then we've likely done
> > something wrong in life)
> > 
> > 5) A proposed change to k8s-openstack-provider against current master of k8s
> > 6) A proposed change to k8s-openstack-provider against a stable release
> > of k8s
> > 7) A proposed change to k8s against current master of k8s-openstack-provider
> > 8) A proposed change to k8s against stable release of k8s-openstack-provider
> > 
> > 5 and 6 are things we can do right now. 7 and 8 will have to wait for GH
> > support to land in zuul (without which we can neither trigger test jobs
> > on proposed changes to k8s nor can we report the results back to anyone)
> 
> 7 and 8 are going to be pretty important for integrating into the K8S
> release process. At the risk of having a work item thrown at me,
> is there a target for when that feature will land?
> 

Hi! Github support is happening basically as "zuulv3+1". We're working
on it in parallel with the v3 effort, so it should be a relatively quick
+1, but I'd expect infra will need a couple months of shaking out v3
bugs and getting everything ported before we can start talking about
hooking infra's zuul up to Github.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-04-04 Thread Chris Hoge 

> On Apr 2, 2017, at 4:29 PM, Monty Taylor <mord...@inaugust.com> wrote:
> 
> On 03/29/2017 03:39 PM, Steve Gordon wrote:
>> - Original Message -
>>> From: "Davanum Srinivas" <dava...@gmail.com>
>>> To: "Chris Hoge" <ch...@openstack.org>
>>> Cc: "OpenStack Development Mailing List (not for usage questions)" 
>>> <openstack-dev@lists.openstack.org>,
>>> "kubernetes-sig-openstack" <kubernetes-sig-openst...@googlegroups.com>
>>> Sent: Wednesday, March 29, 2017 2:28:29 PM
>>> Subject: Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud 
>>> Provider for Kubernetes
>>> 
>>> Team,
>>> 
>>> Repo is ready:
>>> http://git.openstack.org/cgit/openstack/k8s-cloud-provider
>>> 
>>> I've taken the liberty of updating it with the latest changes in the
>>> kubernetes/kubernetes repo:
>>> https://review.openstack.org/#/q/project:openstack/k8s-cloud-provider is
>>> ready
>>> 
>>> So logical next step would be to add CI jobs to test in OpenStack
>>> Infra. Anyone interested?
>> 
>> One question I have around this - do we have a shared view of what the ideal 
>> matrix of tested combinations would like? E.g. kubernetes master on 
>> openstack project's master, kubernetes master on openstack project's stable 
>> branches (where available), do we also need/want to test kubernetes stable 
>> milestones, etc.
>> 
>> At a high level my goal would be the same as Chris's "k8s gating on 
>> OpenStack in the same ways that it does on AWS and GCE." which would imply 
>> reporting results on PRs proposed to K8S master *before* they merge but not 
>> sure we all agree on what that actually means testing against in practice on 
>> the OpenStack side of the equation?
> 
> I think we want to have jobs that have the ability to test:
> 
> 1) A proposed change to k8s-openstack-provider against current master of
> OpenStack
> 2) A proposed change to k8s-openstack-provider against a stable release
> of OpenStack
> 3) A proposed change to OpenStack against current master of
> k8s-openstack-provider
> 4) A proposed change to OpenStack against stable release of
> k8s-openstack-provider
> 
> Those are all easy now that the code is in gerrit, and it's well defined
> what triggers and where it reports.
> 
> Additionally, we need to test the surface area between
> k8s-openstack-provider and k8s itself. (if we wind up needing to test
> k8s against proposed changes to OpenStack then we've likely done
> something wrong in life)
> 
> 5) A proposed change to k8s-openstack-provider against current master of k8s
> 6) A proposed change to k8s-openstack-provider against a stable release
> of k8s
> 7) A proposed change to k8s against current master of k8s-openstack-provider
> 8) A proposed change to k8s against stable release of k8s-openstack-provider
> 
> 5 and 6 are things we can do right now. 7 and 8 will have to wait for GH
> support to land in zuul (without which we can neither trigger test jobs
> on proposed changes to k8s nor can we report the results back to anyone)

7 and 8 are going to be pretty important for integrating into the K8S
release process. At the risk of having a work item thrown at me,
is there a target for when that feature will land?

It's not critical though, sorting out every other item is a pretty
cool set of initial tests.

Of note, e2e tests have some unreliability because of things like
hard sleeps[1]. It sounds like the K8S community is trying to address
these issues, but initially we should be expecting quite a few false
negatives (where negative means test failure).

[1] https://groups.google.com/forum/#!topic/kubernetes-sig-testing/a3XUvUVmxWU

> 
> I would recommend that we make 5 and 6 non-voting until such a time as
> we are reporting on 7 and 8 back to k8s and have a reasonable
> expectation someone will pay attention to failures - otherwise k8s will
> be able to wedge the k8s-openstack-provider gate.
> 
>>> On Sat, Mar 25, 2017 at 12:10 PM, Chris Hoge <ch...@openstack.org> wrote:
>>>> 
>>>> 
>>>> On Friday, March 24, 2017 at 8:46:42 AM UTC-7, Antoni Segura Puimedon
>>>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On Friday, March 24, 2017 at 3:59:18 PM UTC+1, Graham Hayes wrote:
>>>>>> 
>>>>>> On 24/03/17 10:27 -0400, Davanum Srinivas wrote:
>>>>>>> Folks,
>>>>>>> 
>>>>>>> As discussed in the etherpad:
>>>>>>> http

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-04-04 Thread Chris Hoge 

> On Apr 2, 2017, at 4:16 PM, Monty Taylor  wrote:
> 
> On 04/02/2017 02:53 PM, Chris Hoge wrote:
>> Now that the provider has a repository in the OpenStack project
>> namespace, we need to move over the existing set of issues and pull
>> requests and create an initial work list for migrating patches and
>> fixing existing issues.
>> 
>> I've started up an etherpad where we can track that work[1]. In the longer
>> run we should migrate over to Launchpad or Storyboard. One question,
>> to help preserve continuity with the K8S community workflow: do we want
>> to investigate ways to allow for issue creation in the OpenStack
>> namespace on GitHub?
> 
> I do not think this is a thing we want to do. While I understand the
> urge, a project needs to live somewhere (in this case we've chosen
> OpenStack) and should behave as projects do in that location. When I
> work on Ansible, I do issues on github. When I deal with tox, I file
> issues on bitbucket. Back when I dealt with Jenkins I filed issues in
> their Jira. I do not think that filing an issue in the issue tracker for
> a project is too onerous of a request to make of someone.

Sounds reasonable.

I still want to think about how to communicate efficiently across
projects. This thread, for example, was cross posted across communities,
and has now forked as a result.

I’m personally not thrilled with cross posting. My proposal would be to
consider the openstack-dev mailing list to be the source for development
related discussions, and I can feed highlights of discussions to the
sig-k8s-openstack, and relay and relevant discussions from there back
to this list.

> We have issues turned off in all of our github mirrors, so it's highly
> unlikely someone will accidentally attempt to file an issue like the.
> (it's too bad we can't similarly turn off pull requests, but oh well)
> 
> 
>> [1] https://etherpad.openstack.org/p/k8s-provider-issue-migration
>> 
>> On Friday, March 24, 2017 at 7:27:09 AM UTC-7, Davanum Srinivas wrote:
>> 
>>Folks,
>> 
>>As discussed in the etherpad:
>>https://etherpad.openstack.org/p/go-and-containers
>>
>> 
>>Here's a request for a repo in OpenStack:
>>https://review.openstack.org/#/c/449641/
>>
>> 
>>This request pulls in the existing code from kubernetes/kubernetes
>>repo and preserves the git history too
>>https://github.com/dims/k8s-cloud-provider
>>
>> 
>>Anyone interested? please ping me on Slack or IRC and we can
>>continue this work.
>> 
>>Thanks,
>>Dims
>> 
>>-- 
>>Davanum Srinivas :: https://twitter.com/dims
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-04-02 Thread Monty Taylor 
On 03/29/2017 03:39 PM, Steve Gordon wrote:
> - Original Message -
>> From: "Davanum Srinivas" <dava...@gmail.com>
>> To: "Chris Hoge" <ch...@openstack.org>
>> Cc: "OpenStack Development Mailing List (not for usage questions)" 
>> <openstack-dev@lists.openstack.org>,
>> "kubernetes-sig-openstack" <kubernetes-sig-openst...@googlegroups.com>
>> Sent: Wednesday, March 29, 2017 2:28:29 PM
>> Subject: Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud 
>> Provider for Kubernetes
>>
>> Team,
>>
>> Repo is ready:
>> http://git.openstack.org/cgit/openstack/k8s-cloud-provider
>>
>> I've taken the liberty of updating it with the latest changes in the
>> kubernetes/kubernetes repo:
>> https://review.openstack.org/#/q/project:openstack/k8s-cloud-provider is
>> ready
>>
>> So logical next step would be to add CI jobs to test in OpenStack
>> Infra. Anyone interested?
> 
> One question I have around this - do we have a shared view of what the ideal 
> matrix of tested combinations would like? E.g. kubernetes master on openstack 
> project's master, kubernetes master on openstack project's stable branches 
> (where available), do we also need/want to test kubernetes stable milestones, 
> etc.
> 
> At a high level my goal would be the same as Chris's "k8s gating on OpenStack 
> in the same ways that it does on AWS and GCE." which would imply reporting 
> results on PRs proposed to K8S master *before* they merge but not sure we all 
> agree on what that actually means testing against in practice on the 
> OpenStack side of the equation?

I think we want to have jobs that have the ability to test:

1) A proposed change to k8s-openstack-provider against current master of
OpenStack
2) A proposed change to k8s-openstack-provider against a stable release
of OpenStack
3) A proposed change to OpenStack against current master of
k8s-openstack-provider
4) A proposed change to OpenStack against stable release of
k8s-openstack-provider

Those are all easy now that the code is in gerrit, and it's well defined
what triggers and where it reports.

Additionally, we need to test the surface area between
k8s-openstack-provider and k8s itself. (if we wind up needing to test
k8s against proposed changes to OpenStack then we've likely done
something wrong in life)

5) A proposed change to k8s-openstack-provider against current master of k8s
6) A proposed change to k8s-openstack-provider against a stable release
of k8s
7) A proposed change to k8s against current master of k8s-openstack-provider
8) A proposed change to k8s against stable release of k8s-openstack-provider

5 and 6 are things we can do right now. 7 and 8 will have to wait for GH
support to land in zuul (without which we can neither trigger test jobs
on proposed changes to k8s nor can we report the results back to anyone)

I would recommend that we make 5 and 6 non-voting until such a time as
we are reporting on 7 and 8 back to k8s and have a reasonable
expectation someone will pay attention to failures - otherwise k8s will
be able to wedge the k8s-openstack-provider gate.

>> On Sat, Mar 25, 2017 at 12:10 PM, Chris Hoge <ch...@openstack.org> wrote:
>>>
>>>
>>> On Friday, March 24, 2017 at 8:46:42 AM UTC-7, Antoni Segura Puimedon
>>> wrote:
>>>>
>>>>
>>>>
>>>> On Friday, March 24, 2017 at 3:59:18 PM UTC+1, Graham Hayes wrote:
>>>>>
>>>>> On 24/03/17 10:27 -0400, Davanum Srinivas wrote:
>>>>>> Folks,
>>>>>>
>>>>>> As discussed in the etherpad:
>>>>>> https://etherpad.openstack.org/p/go-and-containers
>>>>>>
>>>>>> Here's a request for a repo in OpenStack:
>>>>>> https://review.openstack.org/#/c/449641/
>>>>>>
>>>>>> This request pulls in the existing code from kubernetes/kubernetes
>>>>>> repo and preserves the git history too
>>>>>> https://github.com/dims/k8s-cloud-provider
>>>>>>
>>>>>> Anyone interested? please ping me on Slack or IRC and we can continue
>>>>>> this work.
>>>>>
>>>>> Yeah - I would love to continue the provider work on gerrit :)
>>>>>
>>>>> Is there a way for us to make sure changes in the k8 master don't
>>>>> break our plugin? Or do we need to periodic jobs on the provider repo
>>>>> to catch breakages in the plugin interface?
>>>>
>>>>
>>>> I suppose the options are either:
>>>>
>>>&

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-04-02 Thread Monty Taylor 
On 04/02/2017 02:53 PM, Chris Hoge wrote:
> Now that the provider has a repository in the OpenStack project
> namespace, we need to move over the existing set of issues and pull
> requests and create an initial work list for migrating patches and
> fixing existing issues.
> 
> I've started up an etherpad where we can track that work[1]. In the longer
> run we should migrate over to Launchpad or Storyboard. One question,
> to help preserve continuity with the K8S community workflow: do we want
> to investigate ways to allow for issue creation in the OpenStack
> namespace on GitHub?

I do not think this is a thing we want to do. While I understand the
urge, a project needs to live somewhere (in this case we've chosen
OpenStack) and should behave as projects do in that location. When I
work on Ansible, I do issues on github. When I deal with tox, I file
issues on bitbucket. Back when I dealt with Jenkins I filed issues in
their Jira. I do not think that filing an issue in the issue tracker for
a project is too onerous of a request to make of someone.

We have issues turned off in all of our github mirrors, so it's highly
unlikely someone will accidentally attempt to file an issue like the.
(it's too bad we can't similarly turn off pull requests, but oh well)


> [1] https://etherpad.openstack.org/p/k8s-provider-issue-migration
> 
> On Friday, March 24, 2017 at 7:27:09 AM UTC-7, Davanum Srinivas wrote:
> 
> Folks,
> 
> As discussed in the etherpad:
> https://etherpad.openstack.org/p/go-and-containers
> 
> 
> Here's a request for a repo in OpenStack:
> https://review.openstack.org/#/c/449641/
> 
> 
> This request pulls in the existing code from kubernetes/kubernetes
> repo and preserves the git history too
> https://github.com/dims/k8s-cloud-provider
> 
> 
> Anyone interested? please ping me on Slack or IRC and we can
> continue this work.
> 
> Thanks,
> Dims
> 
> -- 
> Davanum Srinivas :: https://twitter.com/dims
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-04-02 Thread Chris Hoge 
Now that the provider has a repository in the OpenStack project
namespace, we need to move over the existing set of issues and pull
requests and create an initial work list for migrating patches and
fixing existing issues.

I've started up an etherpad where we can track that work[1]. In the longer
run we should migrate over to Launchpad or Storyboard. One question,
to help preserve continuity with the K8S community workflow: do we want
to investigate ways to allow for issue creation in the OpenStack
namespace on GitHub?

-Chris

[1] https://etherpad.openstack.org/p/k8s-provider-issue-migration

On Friday, March 24, 2017 at 7:27:09 AM UTC-7, Davanum Srinivas wrote:
>
> Folks, 
>
> As discussed in the etherpad: 
> https://etherpad.openstack.org/p/go-and-containers 
>
> Here's a request for a repo in OpenStack: 
> https://review.openstack.org/#/c/449641/ 
>
> This request pulls in the existing code from kubernetes/kubernetes 
> repo and preserves the git history too 
> https://github.com/dims/k8s-cloud-provider 
>
> Anyone interested? please ping me on Slack or IRC and we can continue this 
> work. 
>
> Thanks, 
> Dims 
>
> -- 
> Davanum Srinivas :: https://twitter.com/dims 
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-03-29 Thread Steve Gordon 
- Original Message -
> From: "Davanum Srinivas" <dava...@gmail.com>
> To: "Chris Hoge" <ch...@openstack.org>
> Cc: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>,
> "kubernetes-sig-openstack" <kubernetes-sig-openst...@googlegroups.com>
> Sent: Wednesday, March 29, 2017 2:28:29 PM
> Subject: Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud 
> Provider for Kubernetes
> 
> Team,
> 
> Repo is ready:
> http://git.openstack.org/cgit/openstack/k8s-cloud-provider
> 
> I've taken the liberty of updating it with the latest changes in the
> kubernetes/kubernetes repo:
> https://review.openstack.org/#/q/project:openstack/k8s-cloud-provider is
> ready
> 
> So logical next step would be to add CI jobs to test in OpenStack
> Infra. Anyone interested?

One question I have around this - do we have a shared view of what the ideal 
matrix of tested combinations would like? E.g. kubernetes master on openstack 
project's master, kubernetes master on openstack project's stable branches 
(where available), do we also need/want to test kubernetes stable milestones, 
etc.

At a high level my goal would be the same as Chris's "k8s gating on OpenStack 
in the same ways that it does on AWS and GCE." which would imply reporting 
results on PRs proposed to K8S master *before* they merge but not sure we all 
agree on what that actually means testing against in practice on the OpenStack 
side of the equation?

Thanks,

Steve

> On Sat, Mar 25, 2017 at 12:10 PM, Chris Hoge <ch...@openstack.org> wrote:
> >
> >
> > On Friday, March 24, 2017 at 8:46:42 AM UTC-7, Antoni Segura Puimedon
> > wrote:
> >>
> >>
> >>
> >> On Friday, March 24, 2017 at 3:59:18 PM UTC+1, Graham Hayes wrote:
> >>>
> >>> On 24/03/17 10:27 -0400, Davanum Srinivas wrote:
> >>> >Folks,
> >>> >
> >>> >As discussed in the etherpad:
> >>> >https://etherpad.openstack.org/p/go-and-containers
> >>> >
> >>> >Here's a request for a repo in OpenStack:
> >>> >https://review.openstack.org/#/c/449641/
> >>> >
> >>> >This request pulls in the existing code from kubernetes/kubernetes
> >>> >repo and preserves the git history too
> >>> >https://github.com/dims/k8s-cloud-provider
> >>> >
> >>> >Anyone interested? please ping me on Slack or IRC and we can continue
> >>> > this work.
> >>>
> >>> Yeah - I would love to continue the provider work on gerrit :)
> >>>
> >>> Is there a way for us to make sure changes in the k8 master don't
> >>> break our plugin? Or do we need to periodic jobs on the provider repo
> >>> to catch breakages in the plugin interface?
> >>
> >>
> >> I suppose the options are either:
> >>
> >> ask k8s to add select external cloud providers in the CI
> >> Have a webhook in the k8s repo that triggered CI on the OSt infra
> >
> >
> > Yes please to these. My preference is for the provider to remain upstream
> > in
> > k8s, but it's development has stalled out a bit. I want the best provider
> > possible, but also want to make sure it's tested and visible to the k8s
> > community that want to run on OpenStack. I've mentioned before that one of
> > my goals is to have k8s gating on OpenStack in the same ways that it does
> > on
> > AWS and GCE.
> >
> > -Chris
> >
> >
> >>>
> >>>
> >>> Thanks, Graham
> >>>
> >>>
> >>> > >__
> >>> >OpenStack Development Mailing List (not for usage questions)
> >>> >Unsubscribe:
> >>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "kubernetes-sig-openstack" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to kubernetes-sig-openstack+unsubscr...@googlegroups.com.
> > To post to this group, send email to
> > kubernetes-sig-openst...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/kubernetes-sig-openstack/a7b56756-7efe-4179-8467-6a689f1abe63%40googlegroups.com.
> >
> > For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> --
> Davanum Srinivas :: https://twitter.com/dims
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Steve Gordon,
Principal Product Manager,
Red Hat OpenStack Platform

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-03-29 Thread Davanum Srinivas 
Team,

Repo is ready:
http://git.openstack.org/cgit/openstack/k8s-cloud-provider

I've taken the liberty of updating it with the latest changes in the
kubernetes/kubernetes repo:
https://review.openstack.org/#/q/project:openstack/k8s-cloud-provider is ready

So logical next step would be to add CI jobs to test in OpenStack
Infra. Anyone interested?

Thanks,
Dims

On Sat, Mar 25, 2017 at 12:10 PM, Chris Hoge  wrote:
>
>
> On Friday, March 24, 2017 at 8:46:42 AM UTC-7, Antoni Segura Puimedon wrote:
>>
>>
>>
>> On Friday, March 24, 2017 at 3:59:18 PM UTC+1, Graham Hayes wrote:
>>>
>>> On 24/03/17 10:27 -0400, Davanum Srinivas wrote:
>>> >Folks,
>>> >
>>> >As discussed in the etherpad:
>>> >https://etherpad.openstack.org/p/go-and-containers
>>> >
>>> >Here's a request for a repo in OpenStack:
>>> >https://review.openstack.org/#/c/449641/
>>> >
>>> >This request pulls in the existing code from kubernetes/kubernetes
>>> >repo and preserves the git history too
>>> >https://github.com/dims/k8s-cloud-provider
>>> >
>>> >Anyone interested? please ping me on Slack or IRC and we can continue
>>> > this work.
>>>
>>> Yeah - I would love to continue the provider work on gerrit :)
>>>
>>> Is there a way for us to make sure changes in the k8 master don't
>>> break our plugin? Or do we need to periodic jobs on the provider repo
>>> to catch breakages in the plugin interface?
>>
>>
>> I suppose the options are either:
>>
>> ask k8s to add select external cloud providers in the CI
>> Have a webhook in the k8s repo that triggered CI on the OSt infra
>
>
> Yes please to these. My preference is for the provider to remain upstream in
> k8s, but it's development has stalled out a bit. I want the best provider
> possible, but also want to make sure it's tested and visible to the k8s
> community that want to run on OpenStack. I've mentioned before that one of
> my goals is to have k8s gating on OpenStack in the same ways that it does on
> AWS and GCE.
>
> -Chris
>
>
>>>
>>>
>>> Thanks, Graham
>>>
>>>
>>> > >__
>>> >OpenStack Development Mailing List (not for usage questions)
>>> >Unsubscribe:
>>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> You received this message because you are subscribed to the Google Groups
> "kubernetes-sig-openstack" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-sig-openstack+unsubscr...@googlegroups.com.
> To post to this group, send email to
> kubernetes-sig-openst...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-sig-openstack/a7b56756-7efe-4179-8467-6a689f1abe63%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-03-25 Thread Chris Hoge 


On Friday, March 24, 2017 at 8:46:42 AM UTC-7, Antoni Segura Puimedon wrote:
>
>
>
> On Friday, March 24, 2017 at 3:59:18 PM UTC+1, Graham Hayes wrote:
>>
>> On 24/03/17 10:27 -0400, Davanum Srinivas wrote: 
>> >Folks, 
>> > 
>> >As discussed in the etherpad: 
>> >https://etherpad.openstack.org/p/go-and-containers 
>> > 
>> >Here's a request for a repo in OpenStack: 
>> >https://review.openstack.org/#/c/449641/ 
>> > 
>> >This request pulls in the existing code from kubernetes/kubernetes 
>> >repo and preserves the git history too 
>> >https://github.com/dims/k8s-cloud-provider 
>> > 
>> >Anyone interested? please ping me on Slack or IRC and we can continue 
>> this work. 
>>
>> Yeah - I would love to continue the provider work on gerrit :) 
>>
>> Is there a way for us to make sure changes in the k8 master don't 
>> break our plugin? Or do we need to periodic jobs on the provider repo 
>> to catch breakages in the plugin interface? 
>>
>
> I suppose the options are either:
>
> ask k8s to add select external cloud providers in the CI
> Have a webhook in the k8s repo that triggered CI on the OSt infra 
>

Yes please to these. My preference is for the provider to remain upstream 
in k8s, but it's development has stalled out a bit. I want the best 
provider possible, but also want to make sure it's tested and visible to 
the k8s community that want to run on OpenStack. I've mentioned before that 
one of my goals is to have k8s gating on OpenStack in the same ways that it 
does on AWS and GCE.

-Chris

 

>
>> Thanks, Graham 
>>
>> >__ 
>>
>> >OpenStack Development Mailing List (not for usage questions) 
>> >Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>>
>__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-03-24 Thread Monty Taylor 
On 03/24/2017 11:22 AM, Graham Hayes wrote:
> On 24/03/17 08:46 -0700, Antoni Segura Puimedon wrote:
>>
>>
>> On Friday, March 24, 2017 at 3:59:18 PM UTC+1, Graham Hayes wrote:
>>
>>On 24/03/17 10:27 -0400, Davanum Srinivas wrote:
>>>Folks,
>>>
>>>As discussed in the etherpad:
>>>https://etherpad.openstack.org/p/go-and-containers
>>>
>>>Here's a request for a repo in OpenStack:
>>>https://review.openstack.org/#/c/449641/
>>>
>>>This request pulls in the existing code from kubernetes/kubernetes
>>>repo and preserves the git history too
>>>https://github.com/dims/k8s-cloud-provider
>>>
>>>Anyone interested? please ping me on Slack or IRC and we can
>> continue this
>>work.
>>
>>Yeah - I would love to continue the provider work on gerrit :)
>>
>>Is there a way for us to make sure changes in the k8 master don't
>>break our plugin? Or do we need to periodic jobs on the provider repo
>>to catch breakages in the plugin interface?
>>
>>
>> I suppose the options are either:
>>
>> ask k8s to add select external cloud providers in the CI
>> Have a webhook in the k8s repo that triggered CI on the OSt infra 
>>  
> 
> Yup - I just want to have us get our ducks in a row before we make a
> move.
> 
> From our side, we should look at the support matrix of what OpenStack
> versions we support, and how we plan on testing them in -infra.

We will have better first-class support for this in a few months as part
of rolling out zuul v3. Once the github branch lands and we get v3
rolled out for non-infra projects, we'll be able to cross-test things in
gerrit with things not in gerrit (we have a similar need to be able to
test that ansible PRs don't break zuul)

For now, if you can make sure that you have a test that can install the
k8s repo from source, and also that is structured such that if it
discovers that the k8s repo is there that it will not re-clone, we
should be able to upgrade that in the future to having zuul manage the
triggering and cloning.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-03-24 Thread Graham Hayes 

On 24/03/17 08:46 -0700, Antoni Segura Puimedon wrote:



On Friday, March 24, 2017 at 3:59:18 PM UTC+1, Graham Hayes wrote:

   On 24/03/17 10:27 -0400, Davanum Srinivas wrote:
   >Folks,
   >
   >As discussed in the etherpad:
   >https://etherpad.openstack.org/p/go-and-containers
   >
   >Here's a request for a repo in OpenStack:
   >https://review.openstack.org/#/c/449641/
   >
   >This request pulls in the existing code from kubernetes/kubernetes
   >repo and preserves the git history too
   >https://github.com/dims/k8s-cloud-provider
   >
   >Anyone interested? please ping me on Slack or IRC and we can continue this
   work.

   Yeah - I would love to continue the provider work on gerrit :)

   Is there a way for us to make sure changes in the k8 master don't
   break our plugin? Or do we need to periodic jobs on the provider repo
   to catch breakages in the plugin interface?


I suppose the options are either:

ask k8s to add select external cloud providers in the CI
Have a webhook in the k8s repo that triggered CI on the OSt infra 
 


Yup - I just want to have us get our ducks in a row before we make a
move.


From our side, we should look at the support matrix of what OpenStack

versions we support, and how we plan on testing them in -infra.



   Thanks, Graham

   >__
   >OpenStack Development Mailing List (not for usage questions)
   >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
   >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-03-24 Thread Antoni Segura Puimedon 


On Friday, March 24, 2017 at 3:59:18 PM UTC+1, Graham Hayes wrote:
>
> On 24/03/17 10:27 -0400, Davanum Srinivas wrote: 
> >Folks, 
> > 
> >As discussed in the etherpad: 
> >https://etherpad.openstack.org/p/go-and-containers 
> > 
> >Here's a request for a repo in OpenStack: 
> >https://review.openstack.org/#/c/449641/ 
> > 
> >This request pulls in the existing code from kubernetes/kubernetes 
> >repo and preserves the git history too 
> >https://github.com/dims/k8s-cloud-provider 
> > 
> >Anyone interested? please ping me on Slack or IRC and we can continue 
> this work. 
>
> Yeah - I would love to continue the provider work on gerrit :) 
>
> Is there a way for us to make sure changes in the k8 master don't 
> break our plugin? Or do we need to periodic jobs on the provider repo 
> to catch breakages in the plugin interface? 
>

I suppose the options are either:

ask k8s to add select external cloud providers in the CI
Have a webhook in the k8s repo that triggered CI on the OSt infra 
 

>
> Thanks, Graham 
>
> >__ 
>
> >OpenStack Development Mailing List (not for usage questions) 
> >Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-03-24 Thread Graham Hayes 

On 24/03/17 10:27 -0400, Davanum Srinivas wrote:

Folks,

As discussed in the etherpad:
https://etherpad.openstack.org/p/go-and-containers

Here's a request for a repo in OpenStack:
https://review.openstack.org/#/c/449641/

This request pulls in the existing code from kubernetes/kubernetes
repo and preserves the git history too
https://github.com/dims/k8s-cloud-provider

Anyone interested? please ping me on Slack or IRC and we can continue this work.


Yeah - I would love to continue the provider work on gerrit :)

Is there a way for us to make sure changes in the k8 master don't
break our plugin? Or do we need to periodic jobs on the provider repo
to catch breakages in the plugin interface?

Thanks, Graham


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-03-24 Thread Davanum Srinivas 
Folks,

As discussed in the etherpad:
https://etherpad.openstack.org/p/go-and-containers

Here's a request for a repo in OpenStack:
https://review.openstack.org/#/c/449641/

This request pulls in the existing code from kubernetes/kubernetes
repo and preserves the git history too
https://github.com/dims/k8s-cloud-provider

Anyone interested? please ping me on Slack or IRC and we can continue this work.

Thanks,
Dims

-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev