Re: [openstack-dev] [horizon][neutron][kolla] tools/tox_install changes - breakage with constraints

2018-03-16 Thread Jeffrey Zhang 
kolla install openstack packages through master tarball file on kolla
master branch[0]. like

  pip install -c upper-constraints.txt neutron-master.tar.gz

On stable branch, kolla install through neutron tag tarball. so it should
work.
But i think there will be also some issue here. How about i want to install
neutron-12.0.1.tar.gz, whereas neutron===12.0.0 exist in the
upper-constraints.txt file?

[0] http://tarballs.openstack.org/neutron/neutron-master.tar.gz


On Fri, Mar 16, 2018 at 6:57 PM, Andreas Jaeger  wrote:

> On 2018-03-16 11:49, Jeffrey Zhang wrote:
> > Now it breaks the kolla's master branch jobs. And have to remove the
> > "horizon"
> > and "neutron" in the upper-constraints.txt file. check[1][2].
> >
> > i wanna know what's the correct way to install horizon develop
> > branch with upper-constraints.txt file?
> >
> >
> > [1] https://review.openstack.org/#/c/549456/4/docker/
> neutron/neutron-base/Dockerfile.j2
> >  neutron-base/Dockerfile.j2>
> > [2] https://review.openstack.org/#/c/549456/4/docker/
> horizon/Dockerfile.j2
> > 
>
> Sorry, that is too much magic for me to be able to help you.
>
> What are those doing? How do you install today? Please give me some
> instructions
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [horizon][neutron][kolla] tools/tox_install changes - breakage with constraints

2018-03-16 Thread Andreas Jaeger 
On 2018-03-16 11:49, Jeffrey Zhang wrote:
> Now it breaks the kolla's master branch jobs. And have to remove the
> "horizon"
> and "neutron" in the upper-constraints.txt file. check[1][2]. 
> 
> i wanna know what's the correct way to install horizon develop
> branch with upper-constraints.txt file?
> 
> 
> [1] 
> https://review.openstack.org/#/c/549456/4/docker/neutron/neutron-base/Dockerfile.j2
> 
> [2] https://review.openstack.org/#/c/549456/4/docker/horizon/Dockerfile.j2
> 

Sorry, that is too much magic for me to be able to help you.

What are those doing? How do you install today? Please give me some
instructions

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] [horizon][neutron][kolla] tools/tox_install changes - breakage with constraints

2018-03-16 Thread Jeffrey Zhang 
Now it breaks the kolla's master branch jobs. And have to remove the
"horizon"
and "neutron" in the upper-constraints.txt file. check[1][2].

i wanna know what's the correct way to install horizon develop
branch with upper-constraints.txt file?


[1] https://review.openstack.org/#/c/549456/4/docker/neutron/neutron-base/
Dockerfile.j2
[2] https://review.openstack.org/#/c/549456/4/docker/horizon/Dockerfile.j2



On Thu, Mar 15, 2018 at 9:28 PM, Doug Hellmann 
wrote:

> Excerpts from Thomas Morin's message of 2018-03-15 10:15:38 +0100:
> > Hi Doug,
> >
> > Doug Hellmann, 2018-03-14 23:42:
> > > We keep doing lots of infra-related work to make it "easy" to do
> > >  when it comes to
> > > managing dependencies.  There are three ways to address the issue
> > > with horizon and neutron, and none of them involve adding features
> > > to pbr.
> > >
> > > 1. Things that are being used like libraries need to release like
> > >libraries. Real releases. With appropriate version numbers. So
> > >that other things that depend on them can express valid
> > > dependencies.
> > >
> > > 2. Extract the relevant code into libraries and release *those*.
> > >
> > > 3. Things that are not stable enough to be treated as a library
> > >shouldn't be used that way. Move the things that use the
> > > application
> > >code as library code back into the repo with the thing that they
> > >are tied to but that we don't want to (or can't) treat like a
> > >library.
> >
> > What about the case where there is co-development of features across
> > repos ? One specific case I have in mind is the Neutron stadium where
>
> We do that all the time with the Oslo libraries. It's not as easy as
> having everything in one repo, but we manage.
>
> > we sometimes have features in neutron repo that are worked on as a pre-
> > requisite for things that will be done in a neutron-* or networking-*
> > project. Another is a case for instance where we need to add in project
> > X a tempest test to validate the resolution of a bug for which the fix
> > actually happened in project B (and where B is not a library).
>
> If the tempest test can't live in B because it uses part of X, then I
> think X and B are really one thing and you're doing more work than you
> need to be doing to keep them in separate libraries.
>
> > My intuition is that it is not illegitimate to expect this kind of
> > development workflow to be feasible; but at the same time I read your
> > suggestion above as meaning that it belongs to the real of "things we
> > shouldn't be doing in the first place".  The only way I can reconcile
>
> You read me correctly.
>
> We install a bunch of components from source for integration tests
> in devstack-gate because we want the final releases to work together.
> But those things only interact via REST APIs, and don't import each
> other.  The cases with neutron and horizon are different. Even the
> *unit* tests of the add-ons require code from the "parent" app. That
> indicates a level of coupling that is not being properly addressed by
> the release model and code management practices for the parent apps.
>
> > the two would be to conclude we should collapse all the module in
> > neutron-*/networking-* into neutron, but doing that would have quite a
> > lot of side effects (yes, this is an understatement).
>
> That's not the only way to do it. The other way would be to properly
> decompose the shared code into a library and then provide *stable
> APIs* so code can be consumed by the add-on modules. That will make
> evolving things a little more difficult because of the stability
> requirement. So it's a trade off. I think the teams involved should
> make that trade off (in one direction or another), instead of
> building tools to continue to avoid dealing with it.
>
> So let's start by examining the root of the problem: Why are the things
> that need to import neutron/horizon not part of the neutron/horizon
> repositories in the first place?
>
> Doug
>
> __
> 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
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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