Vendor registry packages differently to enable GCS #9211
Conversation
|
😿😿😿 I think what we're having to do here deserves some crying cats 😿😿😿 |
|
Surprisingly, it's not as bad as I thought. With some scripting it would On Jun 7, 2016, at 8:34 PM, Andy Goldstein [email protected] wrote: 😿😿😿 I think what we're having to do here deserves some crying cats 😿😿😿 — |
|
Sure, but it's ~25k LOC that we'd ideally not have to carry along |
|
I'm starting to change my mind a bit here - I would rather use their On Jun 7, 2016, at 8:37 PM, Andy Goldstein [email protected] wrote: Sure, but it's ~25k LOC that we'd ideally not have to carry along — |
|
We also discussed splitting the registry into a separate repo and having it vendor in all the deps it needs. Maybe we wouldn't have conflicting versions then, since what the registry would need to pull in from Kube and Origin should be relatively small. I'm not saying I want to go this route, but it's maybe starting to sound a bit better? |
|
Today it would not be relatively small, but once we have a client library, On Jun 7, 2016, at 8:46 PM, Andy Goldstein [email protected] wrote: We also discussed splitting the registry into a separate repo and having it — |
smarterclayton
force-pushed
the
enable_gcs_registry
branch
from
4b57377 to
afa3a1a
Compare
smarterclayton
changed the title
|
Alright, this is now updated with build and test. |
|
I cut the package imports down a bit and will push once I see a jenkins run. |
smarterclayton
force-pushed
the
enable_gcs_registry
branch
from
afa3a1a to
c2e0373
Compare
|
[test] |
smarterclayton
force-pushed
the
enable_gcs_registry
branch
from
c2e0373 to
c0b9319
Compare
|
[test] |
smarterclayton
force-pushed
the
enable_gcs_registry
branch
from
c0b9319 to
005c45d
Compare
|
@legionus FYI (this is not affecting you yet ;-) |
|
also, @miminar |
|
When we land distribution 2.4 we'd need to do the same thing here, ping me On Wed, Jun 8, 2016 at 8:45 AM, Paul Weil [email protected] wrote:
|
|
[test] On Wed, Jun 8, 2016 at 10:24 AM, Clayton Coleman [email protected]
|
|
Evaluated for origin test up to 005c45d |
|
continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/4623/) |
|
Ready for review - once we merge this I'll do a backport. On Jun 8, 2016, at 5:50 PM, OpenShift Bot [email protected] wrote: continuous-integration/openshift-jenkins/test SUCCESS ( — |
|
I don't think this will work with go 1.5 without exporting |
|
The change in that PR should adopt this pattern. Go vendor experiment
should not be required, we only build on 1.6. For backport the fix
will involve GOPATH, not vendor.
|
|
We don't support go 1.5.
|
|
@smarterclayton can you and @legionus talk about merging the efforts so @legionus don't have to rework his PR from scratch? |
|
His PR only has to handle the parts that this handles - specifically, the GCS changes. His PR doesn't have to change dramatically. I need this in - is there any feedback on this approach at this point? |
|
@mfojtik this is going to go in before the rebase. |
|
LGTM |
|
[merge] |
|
@smarterclayton I think this will break me terribly, but rebase made me stronger and I can survive... so I'm sending you the rage face: |
|
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/4623/) (Image: devenv-rhel7_4342) |
|
Evaluated for origin merge up to 005c45d |
|
You should just be able to grab the carry in - unless you changed Docker On Thu, Jun 9, 2016 at 11:19 AM, Michal Fojtik [email protected]
|
|
@smarterclayton i don't think I did, but I think you're right. |
Allows registry to have different packages than Kube.