date:20160116

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

2016-01-16 Thread Thomas Goirand

On 01/16/2016 10:16 PM, Jeremy Stanley wrote:
> On 2016-01-16 12:14:20 +0800 (+0800), Thomas Goirand wrote:
> [...]
>> I've just asked this very point with the same example to the FTP
>> masters. Let's see what they say...
> 
> Please point them to the archive for this thread. Specifically it
> would be helpful for them to give _you_ feedback on your attempts to
> switch or remove a large free software project's declared
> contributor copyrights for your own packaging convenience. I
> particularly find it galling that you suggest we should switch from
> contributor-held copyright to a copyright assignment model because
> it would make your life as a package maintainer easier.

It isn't at all how I wrote things.

What I wrote is that I feel like the currently situation makes it very
blurry for one to tell who is the copyright holder(s). I'm seeking a way
to fix this. It looks like its another failed attempt, as some
(including you) are opposed to do any of the things I proposed, and
nobody has a better solution (and I don't see how writing to the legal
list will change anything). I suppose I can only give-up.

Cheers,

Thomas Goirand (zigo)

__
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] [kolla] kolla-mesos IRC meeting

2016-01-16 Thread Steven Dake (stdake)

Ryan,

I read your response and the idea of incubators is interesting, but the
risk there is we will end up with "two core teams" with different
objectives, purpose, focus, and most importantly a lack of coordinated
efforts and thinking.  I'd like to experiment with converting two of our
meetings to an apac timezone meeting, since the main problem I think at
the moment is some folks in apac can't participate in our weekly meetings.

How do folks feel about that idea?

Thanks
-steve

Regards
-steve

On 1/15/16, 6:10 AM, "Ryan Hallisey"  wrote:

>Hello,
>
>I think creating a separate kolla-mesos meeting is a good idea. My only
>issue is that I'm a little afraid it might separate our community a
>little, but I think it's necessary for kolla-mesos to grow.  My other
>thought is what is there to come of other kolla-* repos? That being not
>only kolla-mesos, but in the future kolla-anisble.  Maybe kolla meetings
>can be an incubator for those repos until they need to move out on their
>own?  Just a thought here.
>
>+1
>-Ryan
>
>- Original Message -
>From: "Michal Rostecki" 
>To: openstack-dev@lists.openstack.org
>Sent: Friday, January 15, 2016 6:38:39 AM
>Subject: [openstack-dev] [kolla] kolla-mesos IRC meeting
>
>Hi,
>
>Currently we're discussing stuff about kolla-mesos project on kolla IRC
>meetings[1]. We have an idea of creating the separate meeting for
>kolla-mesos. I see the following reasons for that:
>
>- kolla-mesos has some contributors which aren't able to attend kolla
>meeting because of timezone reasons
>- kolla meetings had a lot of topics recently and there was a short time
>for discussing kolla-mesos things
>- in the most of kolla meetings, we treated the whole kolla-mesos as one
>topic, which is bad in terms of analyzing single problems inside this
>project
>
>The things I would like to know from you is:
>- whether you're +1 or -1 to the whole idea of having separate meeting
>- what is your preferred time of meeting - please use this etherpad[2]
>(I already added there some names of most active contributors from who
>I'd like to hear an opinion, so if you're interested - please "override
>color"; if not, remove the corresponding line)
>
>About the time of meeting and possible conflicts - I think that in case
>of conflicting times and the equal number of votes, opinion of core
>reviewers and people who are already contributing to the project
>(reviews and commits) will be more important. You can see the
>contributors here[3][4].
>
>[1] https://wiki.openstack.org/wiki/Meetings/Kolla
>[2] https://etherpad.openstack.org/p/kolla-mesos-irc-meeting
>[3] http://stackalytics.com/?module=kolla-mesos
>[4] http://stackalytics.com/?module=kolla-mesos&metric=commits
>
>Cheers,
>Michal
>
>__
>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] [devstack] Failure on installing openstack with latest devstack.

2016-01-16 Thread Vikram Choudhary

Remove cloud.yaml file and try!

*os-client-config* will look for a file called *clouds.yaml*in the
following locations:

Current Directory
~/.config/openstack
/etc/openstack

Thanks
Vikram
On Jan 17, 2016 8:19 AM, "Vikram Choudhary"  wrote:

> Remove cloud.yaml file try!
>
> *os-client-config* will look for a file called *clouds.yaml*in the
> following locations:
>
> Current Directory~/.config/openstack/etc/openstack
>
> Thanks
> Vikram
> Hi,
>
> I'm continuously seeing failure installing openstack with latest devstack.
> It exits with the following messages:
>
> ==
> 
>
>
>  
> ramdisk=/home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-initrd
>
> ++ for f in '"$xdir/"*.img' '"$xdir/"ami-*/image'
>
> ++ '[' -f
> /home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-blank.img
> ']'
>
> ++ echo
> /home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-blank.img
>
> ++ break
>
> ++ true
>
> +
> image=/home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-blank.img
>
> + [[ -z cirros-0.3.4-x86_64-uec ]]
>
> + is_arch ppc64
>
> ++ uname -m
>
> + [[ x86_64 == \p\p\c\6\4 ]]
>
> + is_arch aarch64
>
> ++ uname -m
>
> + [[ x86_64 == \a\a\r\c\h\6\4 ]]
>
> + '[' '' = bare ']'
>
> + local kernel_id= ramdisk_id=
>
> + '[' -n
> /home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-vmlinuz
> ']'
>
> ++ openstack --os-cloud=devstack-admin image create
> cirros-0.3.4-x86_64-uec-kernel --public --container-format aki
> --disk-format aki
>
> ++ grep ' id '
>
> ++ get_field 2
>
> ++ local data field
>
> ++ read data
>
> Could not determine a suitable URL for the plugin
>
> + kernel_id=
>
> + '[' -n
> /home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-initrd
> ']'
>
> ++ openstack --os-cloud=devstack-admin image create
> cirros-0.3.4-x86_64-uec-ramdisk --public --container-format ari
> --disk-format ari
>
> ++ grep ' id '
>
> ++ get_field 2
>
> ++ local data field
>
> ++ read data
>
> *Could not determine a suitable URL for the plugin*
>
> + ramdisk_id=
>
> + openstack --os-cloud=devstack-admin image create cirros-0.3.4-x86_64-uec
> --public --container-format ami --disk-format ami
>
> *Could not determine a suitable URL for the plugin*
>
> + exit_trap
>
> + local r=1
>
> ++ jobs -p
>
> + jobs=
>
> + [[ -n '' ]]
>
> + kill_spinner
>
> + '[' '!' -z '' ']'
>
> + [[ 1 -ne 0 ]]
>
> + echo 'Error on exit'
>
> Error on exit
>
> + [[ -z /opt/stack/logs ]]
>
> + /home/localadmin/devstack/tools/worlddump.py -d /opt/stack/logs
>
> World dumping... see /opt/stack/logs/worlddump-2016-01-15-231937.txt for
> details
>
> + exit 1
>
> Fri, 15. Jan 2016,15:19:37
>
>
> 
>
> Has anybody seen the same issue?
>
> Thanks,
> Nader.
>
> __
> 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] Failure on installing openstack with latest devstack.

2016-01-16 Thread Vikram Choudhary

Remove cloud.yaml file try!

*os-client-config* will look for a file called *clouds.yaml*in the
following locations:

Current Directory~/.config/openstack/etc/openstack

Thanks
Vikram
Hi,

I'm continuously seeing failure installing openstack with latest devstack.
It exits with the following messages:

==


 
ramdisk=/home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-initrd

++ for f in '"$xdir/"*.img' '"$xdir/"ami-*/image'

++ '[' -f
/home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-blank.img
']'

++ echo
/home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-blank.img

++ break

++ true

+
image=/home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-blank.img

+ [[ -z cirros-0.3.4-x86_64-uec ]]

+ is_arch ppc64

++ uname -m

+ [[ x86_64 == \p\p\c\6\4 ]]

+ is_arch aarch64

++ uname -m

+ [[ x86_64 == \a\a\r\c\h\6\4 ]]

+ '[' '' = bare ']'

+ local kernel_id= ramdisk_id=

+ '[' -n
/home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-vmlinuz
']'

++ openstack --os-cloud=devstack-admin image create
cirros-0.3.4-x86_64-uec-kernel --public --container-format aki
--disk-format aki

++ grep ' id '

++ get_field 2

++ local data field

++ read data

Could not determine a suitable URL for the plugin

+ kernel_id=

+ '[' -n
/home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-initrd
']'

++ openstack --os-cloud=devstack-admin image create
cirros-0.3.4-x86_64-uec-ramdisk --public --container-format ari
--disk-format ari

++ grep ' id '

++ get_field 2

++ local data field

++ read data

*Could not determine a suitable URL for the plugin*

+ ramdisk_id=

+ openstack --os-cloud=devstack-admin image create cirros-0.3.4-x86_64-uec
--public --container-format ami --disk-format ami

*Could not determine a suitable URL for the plugin*

+ exit_trap

+ local r=1

++ jobs -p

+ jobs=

+ [[ -n '' ]]

+ kill_spinner

+ '[' '!' -z '' ']'

+ [[ 1 -ne 0 ]]

+ echo 'Error on exit'

Error on exit

+ [[ -z /opt/stack/logs ]]

+ /home/localadmin/devstack/tools/worlddump.py -d /opt/stack/logs

World dumping... see /opt/stack/logs/worlddump-2016-01-15-231937.txt for
details

+ exit 1

Fri, 15. Jan 2016,15:19:37




Has anybody seen the same issue?

Thanks,
Nader.

__
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] [Openstack-dev][Manila] status=NONE when share is created

2016-01-16 Thread Ravi, Goutham

This seems to be a different bug than what you mentioned. When share instances 
were introduced some of the keys that shares had were moved to share instances 
and the database objects are created separately. POST to /shares endpoint 
triggers the create API, which currently only seems to be returning the share 
model as it was populated in the database. So, a bunch of fields would be 
null/None. I've updated the bug description here: 
https://bugs.launchpad.net/manila/+bug/1534161. This is a back port candidate. 
Thanks for noting.

Sincerely,
Goutham

From: Nidhi Mittal Hada (WT01 - Product Engineering Service)
Sent: Thursday, January 07, 2016 12:42 PM
To: 'OpenStack Development Mailing List (not for usage questions)' 
mailto:openstack-dev@lists.openstack.org>>
Subject: RE: [Openstack-dev][Manila] status=NONE when share is created

Hi All,

Could someone please reply to the mail below ..

Is this an expected state to get created share status as None?

As we are intentionally not creating “share instance” while creating
share..

For details please see mail below..

Thanks
Nidhi


From: Nidhi Mittal Hada (WT01 - Product Engineering Service)
Sent: Wednesday, January 06, 2016 1:23 PM
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Subject: [Openstack-dev][Manila] status=NONE when share is created

Hi All,

https://bugs.launchpad.net/manila/+bug/1526284


stack@controller:~/devstack$ manila create NFS 1 --name share5 --share-type 
GENERAL_Storage
+-+--+
| Property | Value |
+-+--+
| status | None 

 |
| share_type_name | GENERAL_Storage |
| description | None |
| availability_zone | None |
| share_network_id | None |
| export_locations | [] |
| share_server_id | None |
| host | None |
| snapshot_id | None |
| is_public | False |
| task_state | None |
| snapshot_support | True |
| id | 6572a26a-2313-4a1d-8765-4a031ec0ae3a |
| size | 1 |
| name | share5 |
| share_type | 961b767b-b8e4-4769-884f-7214af944f29 |
| created_at | 2015-12-15T11:31:23.818642 |
| export_location | None |
| share_proto | NFS |
| consistency_group_id | None |
| source_cgsnapshot_member_id | None |
| project_id | 0e15488bc7a14ce5b530920c95357457 |
| metadata | {} |
+--
__
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] [devstack] Failure on installing openstack with latest devstack.

2016-01-16 Thread Nader Lahouti

Hi,

I'm continuously seeing failure installing openstack with latest devstack.
It exits with the following messages:

==


 
ramdisk=/home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-initrd

++ for f in '"$xdir/"*.img' '"$xdir/"ami-*/image'

++ '[' -f
/home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-blank.img
']'

++ echo
/home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-blank.img

++ break

++ true

+
image=/home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-blank.img

+ [[ -z cirros-0.3.4-x86_64-uec ]]

+ is_arch ppc64

++ uname -m

+ [[ x86_64 == \p\p\c\6\4 ]]

+ is_arch aarch64

++ uname -m

+ [[ x86_64 == \a\a\r\c\h\6\4 ]]

+ '[' '' = bare ']'

+ local kernel_id= ramdisk_id=

+ '[' -n
/home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-vmlinuz
']'

++ openstack --os-cloud=devstack-admin image create
cirros-0.3.4-x86_64-uec-kernel --public --container-format aki
--disk-format aki

++ grep ' id '

++ get_field 2

++ local data field

++ read data

Could not determine a suitable URL for the plugin

+ kernel_id=

+ '[' -n
/home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-initrd
']'

++ openstack --os-cloud=devstack-admin image create
cirros-0.3.4-x86_64-uec-ramdisk --public --container-format ari
--disk-format ari

++ grep ' id '

++ get_field 2

++ local data field

++ read data

*Could not determine a suitable URL for the plugin*

+ ramdisk_id=

+ openstack --os-cloud=devstack-admin image create cirros-0.3.4-x86_64-uec
--public --container-format ami --disk-format ami

*Could not determine a suitable URL for the plugin*

+ exit_trap

+ local r=1

++ jobs -p

+ jobs=

+ [[ -n '' ]]

+ kill_spinner

+ '[' '!' -z '' ']'

+ [[ 1 -ne 0 ]]

+ echo 'Error on exit'

Error on exit

+ [[ -z /opt/stack/logs ]]

+ /home/localadmin/devstack/tools/worlddump.py -d /opt/stack/logs

World dumping... see /opt/stack/logs/worlddump-2016-01-15-231937.txt for
details

+ exit 1

Fri, 15. Jan 2016,15:19:37




Has anybody seen the same issue?

Thanks,
Nader.
__
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] [mistral] [murano] [yaql] An online YAQL evaluator [was RE: [mistral] [murano] An online YAQL evaluator]

2016-01-16 Thread Stan Lagun

Very cool, indeed! Even myself (developer of yaql) often use yaqluator
instead of yaql CLI :)

Finally took a time to see source codes.
Few tips that you may find useful:
* The most expensive operation in yaql is YaqlFactory.create(). This
method builds a parser and it takes significant time (orders of
magnitude more then expression parsing). I see that you create
factory/parser
  on each evaluation. However parser was designed to be immutable and
thread safe so it may be reasonable to create it only once (+1 for
legacy mode) and reuse it across queries. This will make a big
difference
  if the site become popular
* You don't use engine options. There are number of useful settings
that allow to limit iterator length or memory usage. For example looks
like I killed the site by executing [1, 2].cycle() which returns
indefinite collection.
   Sorry for that. Another useful option is the one that converts sets
to lists on output. Without it set function cannot be used in
yaqluator. Also see [1]

[1]: https://review.openstack.org/#/c/268673/
Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis



On Wed, Jan 13, 2016 at 9:17 AM, Renat Akhmerov  wrote:
> Very cool! It now even supports code assistance :)
>
> Moshe, can’t stop saying good words :) Amazing!
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
> On 22 Dec 2015, at 23:06, ELISHA, Moshe (Moshe)
>  wrote:
>
> Hi all,
>
> Thank you for the kind words.
> Just wanted to let you know that yaqluator[1] was updated and now supports
> YAQL 1.0.2.
> There is also a checkbox there to work in “Legacy Mode”.
>
> Hope you will find it useful.
>
> [1] http://yaqluator.com/
>
>
> From: Renat Akhmerov [mailto:rakhme...@mirantis.com]
> Sent: Friday, August 14, 2015 11:51 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [mistral] [murano] An online YAQL evaluator
>
> I just read this thread so decided to add my 2 cents into the collection of
> opinions.
>
> Guys, I tried it out a couple of weeks ago (was told about it by one of my
> colleagues). This is really incredible! Especially given that you completed
> it in 24 hours :) I think as YAQL attracts more and more users it will be
> very handy tool. I am actually for improving it further.
>
> Thanks a lot! Looking forward to switch to yaql 1.0!
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
>
> On 05 Aug 2015, at 04:09, Stan Lagun  wrote:
>
> Dmitry,
>
> yaql 1.0 has both str() and len() and much much more so there is no need to
> support them explicitly since Mistral is going to switch to yaql 1.0 and
> yaqluator.com is going to do the same
>
> Sincerely yours,
> Stan Lagun
> Principal Software Engineer @ Mirantis
>
>
>
> On Tue, Aug 4, 2015 at 8:55 PM, Dmitri Zimine 
> wrote:
> Awesome! Really.
>
> Thank you folks for doing this.
>
> I am so much looking forward to moving it to 1.0 with more built-in
> functions and more power to extend it...
>
> Note that Mistral has a few extensions, like `str`, `len`, which are not in
> the scope of evaluator.
>
> DZ>
>
>
> On Aug 2, 2015, at 12:44 PM, Stan Lagun  wrote:
>
>
> Guys, this is awesome!!!
>
> Happy to see yaql gets attention. One more initiative that you may find
> interesting is https://review.openstack.org/#/c/159905/
> This is an attempt to port yaql 1.0 from Python to JS so that the same can
> be done in browser
>
> Sincerely yours,
> Stan Lagun
> Principal Software Engineer @ Mirantis
>
>
>
> On Sun, Aug 2, 2015 at 5:30 PM, Nikolay Makhotkin 
> wrote:
> Hi guys!
>
> That's awesome! It is very useful for all us!
>
> --
> Best Regards,
> Nikolay
>
>
> __
> 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
>
>
> __
> 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

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

2016-01-16 Thread Jeremy Stanley

On 2016-01-16 11:59:44 +0800 (+0800), Thomas Goirand wrote:
[...]
> Though we could ask copyright holders to declare giving it to the
> foundation.
[...]

Please let's move this to the legal-discuss ML. Even if I thought
copyright assignment was a good idea (which I don't), I lack
sufficient experience in copyright law to know whether it's possible
at all under the current foundation bylaws and I doubt you know
either.
-- 
Jeremy Stanley

__
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] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

2016-01-16 Thread Jeremy Stanley

On 2016-01-16 12:14:20 +0800 (+0800), Thomas Goirand wrote:
[...]
> I've just asked this very point with the same example to the FTP
> masters. Let's see what they say...

Please point them to the archive for this thread. Specifically it
would be helpful for them to give _you_ feedback on your attempts to
switch or remove a large free software project's declared
contributor copyrights for your own packaging convenience. I
particularly find it galling that you suggest we should switch from
contributor-held copyright to a copyright assignment model because
it would make your life as a package maintainer easier. If there was
ever a good reason for copyright assignment in free software, that's
not it.
-- 
Jeremy Stanley

__
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] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

2016-01-16 Thread Jeremy Stanley

On 2016-01-16 12:12:00 +0800 (+0800), Thomas Goirand wrote:
> On 01/15/2016 11:26 PM, Jeremy Stanley wrote:
> > On 2016-01-15 23:09:34 +0800 (+0800), Thomas Goirand wrote:
> >> On 01/15/2016 09:57 PM, Jeremy Stanley wrote:
> > [...]
> >>> resulting in the summary at
> >>> https://wiki.openstack.org/wiki/LegalIssuesFAQ#Copyright_Headers for
> >>> those who choose to learn from history rather than repeating it.
> >>
> >> Well, this wiki entry doesn't even have a single line about copyright
> >> holding, it only tells about licensing and how/when to put a license
> >> header in source code. Or did I miss it when reading too fast?
> > 
> > What? That entire section I linked is _only_ about copyright
> > headers.
> 
> holder != header

Copyright holders are declared in copyright headers. The comments in
files like...

# Copyright 2012 Hewlett-Packard Development Company, L.P.
# Copyright 2013-2014 OpenStack Foundation
# Copyright 2012, 2014 Jeremy Stanley

...are copyright headers declaring the holders of copyright on at
least _some_ parts of the file (it is not guaranteed to be complete,
it is only those who have gone to the trouble to log substantial
changes). What information on "copyright holding" were you looking
for? If you're seeking legal advice, this is not at all the place to
do that.
-- 
Jeremy Stanley

__
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] [magnum] Nesting /containers resource under /bays

2016-01-16 Thread Mike Metral

The requirements that running a fully containerized application optimally & 
effectively requires the usage of a dedicated COE tool such as Swarm, 
Kubernetes or Marathon+Mesos.

OpenStack is better suited for managing the underlying infrastructure.

Mike Metral
Product Architect – Private Cloud R&D
email: mike.met...@rackspace.com
cell: +1-305-282-7606

From: Hongbin Lu
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Friday, January 15, 2016 at 8:02 PM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

A reason is the container abstraction brings containers to OpenStack: Keystone 
for authentication, Heat for orchestration, Horizon for UI, etc.

From: Kyle Kelley [mailto:rgb...@gmail.com]
Sent: January-15-16 10:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

What are the reasons for keeping /containers?

On Fri, Jan 15, 2016 at 9:14 PM, Hongbin Lu 
mailto:hongbin...@huawei.com>> wrote:
Disagree.

If the container managing part is removed, Magnum is just a COE deployment 
tool. This is really a scope-mismatch IMO. The middle ground I can see is to 
have a flag that allows operators to turned off the container managing part. If 
it is turned off, COEs are not managed by Magnum and requests sent to the 
/container endpoint will return a reasonable error code. Thoughts?

Best regards,
Hongbin

From: Mike Metral 
[mailto:mike.met...@rackspace.com]
Sent: January-15-16 6:24 PM
To: openstack-dev@lists.openstack.org

Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

I too believe that the /containers endpoint is obstructive to the overall goal 
of Magnum.

IMO, Magnum’s scope should only be concerned with:

  1.  Provisioning the underlying infrastructure required by the Container 
Orchestration Engine (COE) and
  2.  Instantiating the COE itself on top of said infrastructure from step #1.
Anything further regarding Magnum interfacing or interacting with containers 
starts to get into a gray area that could easily evolve into:

  *   Potential race conditions between Magnum and the designated COE and
  *   Would create design & implementation overhead and debt that could bite us 
in the long run seeing how all COE’s operate & are based off various different 
paradigms in terms of describing & managing containers, and this divergence 
will only continue to grow with time.
  *   Not to mention, the recreation of functionality around managing 
containers in Magnum seems redundant in nature as this is the very reason to 
want to use a COE in the first place – because it’s a more suited tool for the 
task
If there is low-hanging fruit in terms of common functionality across all 
COE’s, then those generic capabilities could be abstracted and integrated into 
Magnum, but these have to be carefully examined beforehand to ensure true 
parity exists for the capability across all COE’s.

However, I still worry that going down this route toes the line that Magnum 
should and could be a part of the managing container story to some degree – 
which again should be the sole responsibility of the COE, not Magnum.

I’m in favor of doing away with the /containers endpoint – continuing with it 
just looks like a snowball of scope-mismatch and management issues just waiting 
to happen.

Mike Metral
Product Architect – Private Cloud R&D - Rackspace

From: Hongbin Lu mailto:hongbin...@huawei.com>>
Sent: Thursday, January 14, 2016 1:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

In short, the container IDs assigned by Magnum are independent of the container 
IDs assigned by Docker daemon. Magnum do the IDs mapping before doing a native 
API call. In particular, here is how it works.

If users create a container through Magnum endpoint, Magnum will do the 
followings:
1.   Generate a uuid (if not provided).
2.   Call Docker Swarm API to create a container, with its hostname equal 
to the generated uuid.
3.   Persist container to DB with the generated uuid.

If users perform an operation on an existing container, they must provide the 
uuid (or the name) of the container (if name is provided, it will be used to 
lookup the uuid). Magnum will do the followings:
1.   Call Docker Swarm API to list all containers.
2.   Find the container whose hostname is equal to the provided uuid, 
record its “docker_id” that is the ID assigned by native tool.
3.   Call Docker Swarm API with “docker_id” to perform the operation.

Magnum doesn’t assume all operations to be routed through Magnum endpoints. 
Alternatively, users can directly

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

Re: [openstack-dev] [kolla] kolla-mesos IRC meeting

Re: [openstack-dev] [devstack] Failure on installing openstack with latest devstack.

Re: [openstack-dev] [devstack] Failure on installing openstack with latest devstack.

Re: [openstack-dev] [Openstack-dev][Manila] status=NONE when share is created

[openstack-dev] [devstack] Failure on installing openstack with latest devstack.

Re: [openstack-dev] [mistral] [murano] [yaql] An online YAQL evaluator [was RE: [mistral] [murano] An online YAQL evaluator]

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

11 matches

Site Navigation

Mail list logo

Footer information