Re: [openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option

2017-06-18 Thread Kaz Shinohara 
Hi team,


>> Free advice: whatever reason you have for not enabling trusts, storing
>> user passwords in the Heat database is 100x worse.
Thank you, your point sounds reasonable.
Of course we don't like to store our customer's credentials in Heat
DB, event though those are encrypted.
This is one of the reason why I agree Rabi's option2.
We are seriously thinking to change it  to the trusts now.


>> Why aren't those upstream?
One of them already in review as Rabi attached.  My colleague raised :)
https://review.openstack.org/435213
If the discussion here will have a conclusion to keep the password auth,
it's pleasure for us to have any further contribution on this point.

Regards,
Kaz

2017-06-17 0:19 GMT+09:00 Pavlo Shchelokovskyy :
> HI all,
>
> On Fri, Jun 16, 2017 at 4:33 PM, Zane Bitter  wrote:
>>
>> On 16/06/17 05:09, Kaz Shinohara wrote:
>>>
>>> I still takes `deferred _auth_method=password` behalf of trusts because
>>> we don't enable trusts in the Keystone side due to some internal reason.
>>
>>
>> Free advice: whatever reason you have for not enabling trusts, storing
>> user passwords in the Heat database is 100x worse.
>>
>>> The issues what you pointed are correct(e.g. user_domain_id), we don't
>>> use the domain well and also added some patches to skip those issues.
>>
>>
>> Why aren't those upstream?
>>
>>> But I guess that the majority of heat users already moved to trusts and
>>> it is obviously better solution in terms of security and granular role
>>> control.
>>> As the edge case(perhaps), if a user want to take password auth, it would
>>> be too tricky for them to introduce it, therefore I agree your 2nd option.
>>>
>>> If we will remove the `deferred_auth_method=password` from heat.conf,
>>> should we keep `deferred_auth_method` self or will replace it to a new
>>> config option just to specify the trusts enable/disable ?  Do you have any
>>> idea on this?
>>> Also I'm thinking that `reauthentication_method` also might be
>>> changed/merged ?
>>>
>>> Regards,
>>> Kaz Shinohara
>>>
>>>
>>> 2017-06-16 14:11 GMT+09:00 Rabi Mishra >> >:
>>
>>
>> [snip]
>>
>>> I'm not sure whether this works with keystone v2 and anyone is using
>>> it or not. Keeping in mind that heat-cli is deprecated and keystone
>>> v3 is now the default, we've 2 options
>>>
>>> 1. Continue to support 'deferred_auth_method=passsword' option and
>>> fix all the above issues.
>>>
>>> 2. Remove/deprecate the option in pike itlsef.
>>>
>>> I would prefer option 2, but probably I miss some history and use
>>> cases for it.
>>
>>
>> Am I right in thinking that any user (i.e. not just the [heat] service
>> user) can create a trust? I still see occasional requests about 'standalone
>> mode' for clouds that don't have Heat available to users (which I suspect is
>> broken, otherwise people wouldn't be asking), and I'm guessing that
>> standalone mode has heretofore required deferred_auth_method=password.
>
>
> When trusts are enabled, generally any user can create a trust to any other
> user, but only with itself as trustor  - there's a strict rule for that in
> default keystone policy.json [0]. The only other reason that might block
> this is when the user is already a trustee, and trust chaining is disabled
> or already exhausted for this trustee. A tiny problem might be that it seems
> you need to know both the user_id/project_id of trustor (can be resolved by
> trustor itself) and the user_id of trustee - which is generally impossible
> for non-admin users, so a trustee must give the trustor its id.
>
> [0]
> http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json#n138
>
>>
>> So if we're going to remove the option then we should probably either
>> officially disown standalone mode or rewrite the instructions such that it
>> can be used with the trusts method.
>>
>> cheers,
>> Zane.
>>
>>
>> __
>> 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
>
>
>
> Cheers,
> --
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
>
> __
> 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] [devstack] etcd v3.2.0?

2017-06-18 Thread Tony Breeds 
On Sun, Jun 18, 2017 at 08:19:16PM -0400, Davanum Srinivas wrote:

> Awesome! thanks Tony, some kolla jobs do that for example, but i think
> this job is a better one to key off of:
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/infra.yaml#n381
> 
> Outline of the work is - check if there are any new releases in github
> downloads, if so download them using wget and then delegate to the scp
> publisher (with keep-hierarchy) to create the new directories and
> upload the file(s).

So perhaps I'm dense but I can't see an easy way to get a list of
release artefacts from github in a form that wget can consume.  The best
I can see is via the API.  I've knocked up a quick'n'dirty mirror
script[1] but I really feel like I've gone off into the weeds.

You basically need to do:

git clone  && cd
virtualenv .venv
.venv/bin/pip install -U pip setuptools wheel
.venv/bin/pip install -r ./requirements.txt   # [2]
.venv/bin/python ./mirror-github-releases.py \
'coreos/etcd::.*linux.*gz:etcd' \
'coreos/etcd:6225411:.*linux.*gz:etcd'

This will in theory from the 3.2.0 (latest) release and look at the
3.1.7 release, see that it's already publically mirrored and move on.

It wouldn't be too hard to incorporate into a job.  Thoughts?

Yours Tony.

[1]  https://github.com/tbreeds/mirror-github-releases
[2] Yes of course I could publish it on pypi if we want to go down this
path


signature.asc
Description: PGP signature
__
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] [Mogan]Tasks update of Mogan Project

2017-06-18 Thread hao wang 
Hi,

We are glad to present this week's tasks update of Mogan.


Essential Priorities


1. New flavors (zhenguo, liusheng)
--

bluepring: https://blueprints.launchpad.net/mogan/+spec/new-flavor

spec: https://review.openstack.org/#/c/454113/


2.Node aggregates (liudong, zhangyang, zhenguo)
---

blueprint: https://blueprints.launchpad.net/mogan/+spec/node-aggregate

spec: https://review.openstack.org/#/c/470927/

code:  expose admin node list API
https://review.openstack.org/#/c/470183/ [merged]


3.Server groups and scheduler hints(liudong, liusheng)
-

blueprint: 
https://blueprints.launchpad.net/mogan/+spec/server-group-api-extension

https://blueprints.launchpad.net/mogan/+spec/support-schedule-hints

spec:

code: scheduler hints: https://review.openstack.org/#/c/463534/


4. Adopt servers (wanghao, litao)


blueprint: https://blueprints.launchpad.net/mogan/+spec/manage-existing-bms

spec: https://review.openstack.org/#/c/459967/ under review

Change the spec according to the review comments, need more review


5. Valence integration (zhenguo, shaohe, luyao, Xinran)
--

blueprint: https://blueprints.launchpad.net/mogan/+spec/valence-integration

spec: 
https://review.openstack.org/#/c/441790/3/specs/pike/approved/valence-integration.rst

code: No updates

__
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] [devstack] etcd v3.2.0?

2017-06-18 Thread Davanum Srinivas 
On Sun, Jun 18, 2017 at 7:36 PM, Tony Breeds  wrote:
> On Fri, Jun 16, 2017 at 03:59:22PM -0400, Davanum Srinivas wrote:
>> Mikhail,
>>
>> I have a TODO on my list - " adding a job that looks for new releases
>> and uploads them to tarballs periodically "
>
> If you point me to how things are added to that mirror I can work
> towards that.

Awesome! thanks Tony, some kolla jobs do that for example, but i think
this job is a better one to key off of:
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/infra.yaml#n381

Outline of the work is - check if there are any new releases in github
downloads, if so download them using wget and then delegate to the scp
publisher (with keep-hierarchy) to create the new directories and
upload the file(s).

Thanks,
Dims

>
> Tony.
>
> __
> 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
>



-- 
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] [devstack] etcd v3.2.0?

2017-06-18 Thread Tony Breeds 
On Fri, Jun 16, 2017 at 03:59:22PM -0400, Davanum Srinivas wrote:
> Mikhail,
> 
> I have a TODO on my list - " adding a job that looks for new releases
> and uploads them to tarballs periodically "

If you point me to how things are added to that mirror I can work
towards that.

Tony.


signature.asc
Description: PGP signature
__
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] [all][stable][ptls] Tagging mitaka as EOL

2017-06-18 Thread Tony Breeds 
On Fri, Jun 16, 2017 at 02:14:59PM +, Jeremy Stanley wrote:
> On 2017-06-16 15:12:36 +1000 (+1000), Tony Breeds wrote:
> [...]
> > It seeems a little odd to be following up so long after I first started
> > this thread  but can someone on infra please process the EOLs as
> > described in [1].
> [...]
> 
> I thought in prior discussions it had been determined that the
> Stable Branch team was going to start taking care of abandoning open
> changes and tagging branch tips (and eventually deleting the
> branches once we upgrade to a newer Gerrit release).

That was the plan but as you point out the removal of branches is
blocked on a new gerrit release.  The stable team is lacking permissions
to abandon reviews on several projects so it's the infra script needs to
handle the abandoning of open reviews and the tagging anyway so I
stopped doing those bits until we can progress the whole thing.  Perhaps
that's a poor choice and I'd be very happy to re-visit it.

>  Looks like some
> of these still have open changes and nothing has been tagged, so you
> want the Infra team to take those tasks back over for this round?
> Did you have any scripts you wanted used for this, or should I just
> wing it for now like I did in the past?

Josh wrote a script[1] to do it which IMO has worked well in the last 2
cycles.  You can do something like:

URL='https://gist.githubusercontent.com/tbreeds/c99e62bf8da19380e4eb130be8783be7/raw/6d02deb40e07516ce8fc529d2ba8c74af11a5a6b/mitaka_eol_data.txt'
eol_branch.sh stable/mitaka mitaka-eol $( curl -s "$URL" | awk '/Please EOL/ 
{print $1}' )

Yours Tony.

[1] 
http://git.openstack.org/cgit/openstack-infra/release-tools/tree/eol_branch.sh


signature.asc
Description: PGP signature
__
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] [Keystone] Cockroachdb for Keystone Multi-master

2017-06-18 Thread Matthieu Simonin 


- Mail original -
> De: "Thierry Carrez" 
> À: openstack-dev@lists.openstack.org
> Envoyé: Lundi 22 Mai 2017 11:02:21
> Objet: Re: [openstack-dev] [Keystone] Cockroachdb for Keystone Multi-master
> 
> Mike Bayer wrote:
> > On 05/18/2017 06:13 PM, Adrian Turjak wrote:
> >>
> >> So, specifically in the realm of Keystone, since we are using sqlalchemy
> >> we already have Postgresql support, and since Cockroachdb does talk
> >> Postgres it shouldn't be too hard to back Keystone with it. At that
> >> stage you have a Keystone DB that could be multi-region, multi-master,
> >> consistent, and mostly impervious to disaster. Is that not the holy
> >> grail for a service like Keystone? Combine that with fernet tokens and
> >> suddenly Keystone becomes a service you can't really kill, and can
> >> mostly forget about.
> > 
> > So this is exhibit A for why I think keeping some level of "this might
> > need to work on other databases" within a codebase is always a great
> > idea even if you are not actively supporting other DBs at the moment.
> > Even if Openstack dumped Postgresql completely, I'd not take the
> > rudimental PG-related utilities out of oslo.db nor would I rename all
> > the "mysql_XYZ" facilities to be "XYZ".
> > [...]
> Yes, that sounds like another reason why we'd not want to aggressively
> contract to the MySQL family of databases. At the very least, before we
> do that, we should experiment with CockroachDB and see how reasonable it
> would be to use in an OpenStack context. It might (might) hit a sweet
> spot between performance, durability, database decentralization and
> keeping SQL advanced features -- I'd hate it if we discovered that too late.

The FEDMC working group[1] seems like a good place to have deeper discussion 
and collaboration about CockroachDB in OpenStack.
Some discussions about CockroachDB already occured there and some people are 
ready to dive into it.

This would be great if some Keystone/SQLAlchemy/interested people 
could join to help in bootstraping the project.

[1]: https://wiki.openstack.org/wiki/Fog_Edge_Massively_Distributed_Clouds

--
Matt (msimonin)

ps: next meeting is next wed. 06/21 15:00UTC (#openstack-meeting).

> 
> --
> Thierry Carrez (ttx)
> 
> __
> 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] [Product] PTG attendance

2017-06-18 Thread Kunzmann, Gerald 
Hi,

Most likely I will not be able to attend the PTG in Denver.

Gerald

From: Rochelle Grober [mailto:rochelle.gro...@huawei.com]
Sent: Donnerstag, 15. Juni 2017 02:35
To: OpenStack Development Mailing List (not for usage questions) 
; user-commit...@lists.openstack.org
Subject: Re: [User-committee] [Product] PTG attendance

In many ways, having the PWG at the PTG is a great idea.  The only problem with 
that is that the PWG and the InteropWG would overlap in the current way the PTG 
is arranged.  Having both at the same place is great for synergy, but having 
them at the same times is not :(  We actually have a chance to grow both teams 
through cross-pollination if we could arrange them not to overlap.

--Rocky

From: UKASICK, ANDREW [mailto:au3...@att.com]
Sent: Wednesday, June 14, 2017 4:29 PM
To: OpenStack Development Mailing List (not for usage questions) 
>; 
user-commit...@lists.openstack.org; 
'Arkady Kanevsky (arkady.kanev...@dell.com)' 
>
Subject: Re: [User-committee] [Product] PTG attendance

Hi Arkady/Leong/Shamail

I don't know yet if I'll be attending the PTG in Denver, but at present, I 
think that it's unlikely.  If the PWG mid-cycle was co-located with the PTG, 
then I expect that I'd be able to attend at least the PWG days.

That said, contrary to what I thought in our meeting on Monday, it would work 
out better for me to have our PWG mid-cycle collocated with the Ops Meetup.

Thanks,

-Andy

Andrew Ukasick
Principal Systems Engineer
AT Integrated Cloud (AIC),  Openstack Community Coordination

From: arkady.kanev...@dell.com 
[mailto:arkady.kanev...@dell.com]
Sent: Tuesday, June 13, 2017 9:05 PM
To: openstack-dev@lists.openstack.org
Cc: 
user-commit...@lists.openstack.org
Subject: Re: [openstack-dev] [Product] PTG attendance

Fellow Product WG members,
We are taking informal poll on how many of us plan to attend
PTG meeting in Denver?

Second question should we have mid-cycle meeting co-located with PTG or with 
operator summit in Mexico city?

Please, respond to this email so Shamail and Leong can tally the results.
Thanks,
Arkady

Arkady Kanevsky, Ph.D.
Director of SW Development
Dell EMC CPSD
Dell Inc. One Dell Way, MS PS2-91
Round Rock, TX 78682, USA
Phone: 512 723 5264

__
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] [neutron] security group OVO change

2017-06-18 Thread Gary Kotton 
Hi,
That patch looks good. We still have an issue in that the create security 
groups does not return the list of the default rules.
Thanks
Gary

On 6/17/17, 2:33 AM, "Isaku Yamahata"  wrote:

It also broke networking-odl.
The patch[1] is needed to unbreak.
[1] https://review.openstack.org/#/c/448420/

necessary db info is taken from context.session.new.
But with OVO, those expunge themselves with create method.
Those info needs to be passed as callback argument.

Thanks,

On Fri, Jun 16, 2017 at 01:25:28PM -0700,
Ihar Hrachyshka  wrote:

> To close the loop here,
> 
> - this also broke heat py3 job (https://launchpad.net/bugs/1698355)
> - we polished https://review.openstack.org/474575 to fix both
> vmware-nsx and heat issues
> - I also posted a patch for oslo.serialization for the bug that
> triggered MemoryError in heat gate:
> https://review.openstack.org/475052
> - the vmware-nsx adoption patch is at:
> https://review.openstack.org/#/c/474608/ and @boden is working on it,
> should be ready to go in due course.
> 
> Thanks and sorry for inconveniences,
> Ihar
> 
> On Thu, Jun 15, 2017 at 6:17 AM, Gary Kotton  wrote:
> > Hi,
> >
> > The commit https://review.openstack.org/284738 has broken decomposed 
plugins
> > (those that extend security groups and rules). The reason for this is 
that
> > there is a extend callback that we use which expects to get a database
> > object and the aforementioned patch passes a new neutron object.
> >
> > I have posted [i] to temporarily address the issue. An alternative is to
> > revert the patch until the decomposed plugins can figure out how to
> > correctly address this.
> >
> > Thanks
> >
> > Gary
> >
> > [i] https://review.openstack.org/474575
> >
> >
> > 
__
> > 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

-- 
Isaku Yamahata 

__
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] [trove][all][tc] A proposal to rearchitect Trove

2017-06-18 Thread Amrith Kumar 
Trove has evolved rapidly over the past several years, since integration in
IceHouse when it only supported single instances of a few databases. Today
it supports a dozen databases including clusters and replication.

The user survey [1] indicates that while there is strong interest in the
project, there are few large production deployments that are known of (by
the development team).

Recent changes in the OpenStack community at large (company realignments,
acquisitions, layoffs) and the Trove community in particular, coupled with
a mounting burden of technical debt have prompted me to make this proposal
to re-architect Trove.

This email summarizes several of the issues that face the project, both
structurally and architecturally. This email does not claim to include a
detailed specification for what the new Trove would look like, merely the
recommendation that the community should come together and develop one so
that the project can be sustainable and useful to those who wish to use it
in the future.

TL;DR

Trove, with support for a dozen or so databases today, finds itself in a
bind because there are few developers, and a code-base with a significant
amount of technical debt.

Some architectural choices which the team made over the years have
consequences which make the project less than ideal for deployers.

Given that there are no major production deployments of Trove at present,
this provides us an opportunity to reset the project, learn from our v1 and
come up with a strong v2.

An important aspect of making this proposal work is that we seek to
eliminate the effort (planning, and coding) involved in migrating existing
Trove v1 deployments to the proposed Trove v2. Effectively, with work
beginning on Trove v2 as proposed here, Trove v1 as released with Pike will
be marked as deprecated and users will have to migrate to Trove v2 when it
becomes available.

While I would very much like to continue to support the users on Trove v1
through this transition, the simple fact is that absent community
participation this will be impossible. Furthermore, given that there are no
production deployments of Trove at this time, it seems pointless to build
that upgrade path from Trove v1 to Trove v2; it would be the proverbial
bridge from nowhere.

This (previous) statement is, I realize, contentious. There are those who
have told me that an upgrade path must be provided, and there are those who
have told me of unnamed deployments of Trove that would suffer. To this,
all I can say is that if an upgrade path is of value to you, then please
commit the development resources to participate in the community to make
that possible. But equally, preventing a v2 of Trove or delaying it will
only make the v1 that we have today less valuable.

We have learned a lot from v1, and the hope is that we can address that in
v2. Some of the more significant things that I have learned are:

- We should adopt a versioned front-end API from the very beginning; making
the REST API versioned is not a ‘v2 feature’

- A guest agent running on a tenant instance, with connectivity to a shared
management message bus is a security loophole; encrypting traffic,
per-tenant-passwords, and any other scheme is merely lipstick on a security
hole

- Reliance on Nova for compute resources is fine, but dependence on Nova VM
specific capabilities (like instance rebuild) is not; it makes things like
containers or bare-metal second class citizens

- A fair portion of what Trove does is resource orchestration; don’t
reinvent the wheel, there’s Heat for that. Admittedly, Heat wasn’t as far
along when Trove got started but that’s not the case today and we have an
opportunity to fix that now

- A similarly significant portion of what Trove does is to implement a
state-machine that will perform specific workflows involved in implementing
database specific operations. This makes the Trove taskmanager a stateful
entity. Some of the operations could take a fair amount of time. This is a
serious architectural flaw

- Tenants should not ever be able to directly interact with the underlying
storage and compute used by database instances; that should be the default
configuration, not an untested deployment alternative

- The CI should test all databases that are considered to be ‘supported’
without excessive use of resources in the gate; better code modularization
will help determine the tests which can safely be skipped in testing changes

- Clusters should be first class citizens not an afterthought, single
instance databases may be the ‘special case’, not the other way around

- The project must provide guest images (or at least complete tooling for
deployers to build these); while the project can’t distribute operating
systems and database software, the current deployment model merely impedes
adoption

- Clusters spanning OpenStack deployments are a real thing that must be
supported

This might sound harsh, that isn’t the intent. Each of these is the

Re: [openstack-dev] [infra][deb-packaging] Stop using track-upstream for deb projects

2017-06-18 Thread Andreas Jaeger 
On 2017-06-13 15:01, Paul Belanger wrote:
> Greetings,
> 
> I'd like to propose we stop using track-upstream for project-config on
> deb-packaging projects. It seems there is no active development on these
> projects currently and by using track-upstream we currently wasting both CI
> resources and HDD space keeping their projects in sync with there upstream
> openstack projects.
> 
> Long term, we don't actually want to support the behavior. I propose we stop
> doing this today, and if somebody steps up to continue the effort on packaging
> our release we then progress forward with out the need of track-upstream.
> 
> Effectively, track-upstream duplicates the size of a projects git repo. For
> example, if deb-nova is setup to track-upstream of nova, we copy all commits 
> and
> import them into deb-nova. This puts unneeded pressure on our infrastructure
> moving forward, the git overlay option for gbp is likely the solution we could
> use.

Indeed ;(

Do you have a patch ready or was there some alternative proposal?

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