Re: [openstack-dev] [Trove] Core reviewer update
+1. Congratulations to the new core members. From: Denis Makogon dmako...@mirantis.commailto:dmako...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, February 5, 2015 at 10:38 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Trove] Core reviewer update +1 Congratulations Peter, Victoria and Edmond. On Thu, Feb 5, 2015 at 6:26 PM, Nikhil Manchanda slick...@gmail.commailto:slick...@gmail.com wrote: Hello Trove folks: Keeping in line with other OpenStack projects, and attempting to keep the momentum of reviews in Trove going, we need to keep our core-team up to date -- folks who are regularly doing good reviews on the code should be brought in to core and folks whose involvement is dropping off should be considered for removal since they lose context over time, not being as involved. For this update I'm proposing the following changes: - Adding Peter Stachowski (peterstac) to trove-core - Adding Victoria Martinez De La Cruz (vkmc) to trove-core - Adding Edmond Kotowski (edmondk) to trove-core - Removing Michael Basnight (hub_cap) from trove-core - Removing Tim Simpson (grapex) from trove-core For context on Trove reviews and who has been active, please see Russell's stats for Trove at: - http://russellbryant.net/openstack-stats/trove-reviewers-30.txt - http://russellbryant.net/openstack-stats/trove-reviewers-90.txt Trove-core members -- please reply with your vote on each of these proposed changes to the core team. Peter, Victoria and Eddie -- please let me know of your willingness to be in trove-core. Michael, and Tim -- if you are planning on being substantially active on Trove in the near term, also please do let me know. Thanks, Nikhil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [Glance] PTL Non-Candidacy
+1 You will be missed Mark. Thank you for your leadership and mentorship. Iccha On 9/23/14, 5:59 AM, stuart.mcla...@hp.com stuart.mcla...@hp.com wrote: Hi Mark, Many thanks for your leadership, and keeping glance so enjoyable to work on over the last few cycles. -Stuart From: Mark Washenberger mark.washenber...@markwash.net To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: [openstack-dev] [Glance] PTL Non-Candidacy Message-ID: CAJyP2C_zR5oK-=dno1e5wv-qsimfqplckzfbl+rhg6-7fhd...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Greetings, I will not be running for PTL for Glance for the Kilo release. I want to thank all of the nice folks I've worked with--especially the attendees and sponsors of the mid-cycle meetups, which I think were a major success and one of the highlights of the project for me. Cheers, markwash -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20140922/ 85b17570/attachment-0001.html -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance][Trove] Metadata Catalog
+1 We are unsure when these changes will get into glance. IMO we should go ahead will our instance metadata patch for now and when things are ready in glance land we can consider migrating to using that as a generic metadata repository. Thanks, Iccha From: Craig Vyvial cp16...@gmail.commailto:cp16...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, July 24, 2014 at 3:04 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Glance][Trove] Metadata Catalog Denis, The scope of the metadata api goes beyond just using the glance metadata. The metadata can be used for instances and and other objects to add extra data like tags or something else that maybe a UI might want to use. We need this feature either way. -Craig On Thu, Jul 24, 2014 at 12:17 PM, Amrith Kumar amr...@tesora.commailto:amr...@tesora.com wrote: Speaking as a ‘database guy’ and a ‘Trove guy’, I’ll say this; “Metadata” is a very generic term and the meaning of “metadata” in a database context is very different from the meaning of “metadata” in the context that Glance is providing. Furthermore the usage and access pattern for this metadata, the frequency of change, and above all the frequency of access are fundamentally different between Trove and what Glance appears to be offering, and we should probably not get too caught up in the project “title”. We would not be “reinventing the wheel” if we implemented an independent metadata scheme for Trove; we would be implementing the right kind of when for the vehicle that we are operating. Therefore I do not agree with your characterization that concludes that: given goals at [1] are out of scope of Database program, etc Just to be clear, when you write: Unfortunately, we’re(Trove devs) are on half way to metadata … it is vital to understand that our view of “metadata” is very different from (for example, a file system’s view of metadata, or potentially Glance’s view of metadata). For that reason, I believe that your comments on https://review.openstack.org/#/c/82123/16 are also somewhat extreme. Before postulating a solution (or “delegating development to Glance devs”), it would be more useful to fully describe the problem being solved by Glance and the problem(s) we are looking to solve in Trove, and then we could have a meaningful discussion about the right solution. I submit to you that we will come away concluding that there is a round peg, and a square hole. Yes, one will fit in the other but the final product will leave neither party particularly happy with the end result. -amrith From: Denis Makogon [mailto:dmako...@mirantis.commailto:dmako...@mirantis.com] Sent: Thursday, July 24, 2014 9:33 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [Glance][Trove] Metadata Catalog Hello, Stackers. I’d like to discuss the future of Trove metadata API. But first small history info (mostly taken for Trove medata spec, see [1]): Instance metadata is a feature that has been requested frequently by our users. They need a way to store critical information for their instances and have that be associated with the instance so that it is displayed whenever that instance is listed via the API. This also becomes very usable from a testing perspective when doing integration/ci. We can utilize the metadata to store things like what process created the instance, what the instance is being used for, etc... The design for this feature is modeled heavily on the Nova metadata API with a few tweaks in how it works internally. And here comes conflict. Glance devs are working on “Glance Metadata Catalog” feature (see [2]). And as for me, we don’t have to “reinvent the wheel” for Trove. It seems that we would be able to use Glance API to interact with Metadata Catalog. And it seems to be redundant to write our own API for metadata CRUD operations. From Trove perspective, we need to define a list concrete use cases for metadata usage (eg given goals at [1] are out of scope of Database program, etc.). From development and cross-project integration perspective, we need to delegate all development to Glance devs. But we still able to help Glance devs with this feature by taking active part in polishing proposed spec (see [2]). Unfortunately, we’re(Trove devs) are on half way to metadata - patch for python-troveclient already merged. So, we need to consider deprecation/reverting of merged and block merging of proposed ( see [3]) patchsets in favor of Glance Metadata Catalog. Thoughts? [1] https://wiki.openstack.org/wiki/Trove-Instance-Metadata [2] https://review.openstack.org/#/c/98554/11 [3] https://review.openstack.org/#/c/82123/ Best regards, Denis Makogon
Re: [openstack-dev] [trove] Discussion of capabilities feature
Hey Doug, Thank you so much for putting this together. I have some questions/clarifications(inline) which would be useful to be addressed in the spec. From: Doug Shelley d...@tesora.commailto:d...@tesora.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, July 3, 2014 at 2:20 PM To: OpenStack Development Mailing List (not for usage questions) (openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [trove] Discussion of capabilities feature At yesterday's Trove team meeting [1] there was significant discussion around the Capabilities [2] feature. While the community previously approved a BP and some of the initial implementation, it is apparent now that there is no agreement in the community around the requirements, use cases or proposed implementation. I mentioned in the meeting that I thought it would make sense to adjust the current BP and spec to reflect the concerns and hopefully come up with something that we can get consensus on. Ahead of this, I thought it would to try to write up some of the key points and get some feedback here before updating the spec. First, here are what I think the goals of the Capabilities feature are: 1. Provide other components with a mechanism for understanding which aspects of Trove are currently available and/or in use Good point about communicating to other components. We can highlight how this would help other projects like horizon dynamically modify their UI based on the api response. [2] This proposal includes the ability to setup different capabilities for different datastore versions. “ So capabilities is specific to data stores/datastore versions and not for trove in general right? Also it would be useful for us as a community to maybe lay some ground rules for what is a capability and what is not in the spec. For example, how to distinguish what goes in https://github.com/openstack/trove/blob/master/trove/common/cfg.py#L273 as a config value and what does not. 2. Allow operators the ability to control some aspects of Trove at deployment time If we are controlling the aspects at deploy time what advantages do having tables like capabilities and capabilities_overrides offer over having in the config file under the config groups for different data stores like [mysql][redis] etc? I think it would be useful to document these answers because they might keep resurfacing in the future. Also want to make sure we are not trying to solve the problem of config override during run time here because that is an entirely different problem not in scope here. Use Cases 1. Unimplemented feature - this is the case where one/some datastore managers provide support for some specific capability but others don't. A good example would be replication support as we are only planning to support the MySQL manager in the first version. As other datastore managers gain support for the capability, these would be enabled. 2. Unsupported feature - similar to #1 except this would be the case where the datastore manager inherently doesn't support the capability. For example, Redis doesn't have support for volumes. 3. Operator controllable feature - this would be a capability that can be controlled at deployment time at the option of the operator. For example, whether to provide access to the root user on instance creation. Are not 1 and 2 set at deploy time as well? 4. Downstream capabilities addition - basically the ability to use capabilities as an extension point. Allow downstream implementations to add capabilities that aren't present in upstream Trove. Requirements 1. There are a well known set of capabilities that are provided with upstream Trove. Each capability is either read-only (basically use cases 1 2) or read-write (use case 3). Use case #4 capabilities are not part of the well known set. 2. Each capability can be over-ridden at the datastore manager level, the datastore level or the datastore version level. The datastore manager level would be used for the read only capabilities and specified by a given version of Trove. Datastore/Datastore version overrides would be for Operator controllable capabilities that are read-write. Is there going to be a distinction at design level between read-write/read only capabilities? For example are operators going to be forbidden from changing certain capabilities? 3. The datastore/datastore version overrides are only present if created by the Operator at deployment time. Again if this is deployment time only, should we be having config files for different data stores? And instead of having to populate databases by admins, this could be taken care of by config management tools in deployments? 4. A clean Trove install should create the
Re: [openstack-dev] [Glance] Proposed S3 multi-part upload functionality
Ozawa, +1 to what Zhi said. Go ahead and submit a patch for review and we can consider it for Icehouse. Also try to attend the glance meeting if possible and we can discuss it there. Having better uploads/downloads and specifically better error handling for uploads and downloads would definitely help conserve resources and improve time taken. Iccha -Original Message- From: Zhi Yan Liu lzy@gmail.com Sent: Monday, September 30, 2013 1:29am To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Glance] Proposed S3 multi-part upload functionality On Mon, Sep 30, 2013 at 12:22 PM, Masashi Ozawa moz...@cloudian.com wrote: Hi everyone, We already created the blueprint for this feature below belore, if Glance can use S3 MultiPart Upload REST API for the large objects in future release as Amazon recommends it for the large object to be uploaded, I believe that it's very useful for the customers and a good thing for AWS and other S3 servers. https://blueprints.launchpad.net/glance/+spec/s3-multi-part-upload However it's not in the future release list so we actually implemeted this feature based on Grizzly for an internal testing porpose and it works so far. Made the implementation strategy below. So please review this so that we can hopefully have this feature in the future openstack release. - Proposal S3 multi-part upload functionality https://etherpad.openstack.org/s3-multi-part-upload thanks, - Ozawa -- Cloudian KK - http://cloudian.jp/ Masashi Ozawa moz...@cloudian.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hello Masashi Ozawa, I consider it's a worth enhancement for s3 store driver, with a minor change and a boto requirement update. You can just prepare your patch base on the trunk code and commit it to Gerrit to allow team take a review If you like. Actually I'm just thinking if a resume-broken-transfer (image uploading and downloading) is a useful thing for Glance as a common requirement/enhancement. Any thoughts from you(s)? thanks, zhiyan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Waiting for someone to verify/look into a bug I have opened for Glance Client tool
Maty,
Can you link the launchpad bug? I have used image-list for glance v2 and it
seemed to work fine for me. Maybe you could provide more details?
Also maybe we should continue this discussion on openstack mailing list than
the dev list?
Thanks,
Iccha
-Original Message-
From: GROSZ, Maty (Maty) maty.gr...@alcatel-lucent.com
Sent: Monday, September 30, 2013 9:40am
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Subject: [openstack-dev] Waiting for someone to verify/look into a bug I have
opened for Glance Client tool
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi,
I have opened a bug for Glance Client tool some weeks ago (at September 8th) -
and I still didn't receive any comment on it. Is it right? Am I wrong?
Anything...
I will really appreciate if someone from the Glance client tool will have a
look on the bug (see below).
Thanks,
Maty.
From launchpad:
Hi,
When I am running Glance Client tool against glance service using the following
command:
glance --debug --os-image-api-version 2 image-list
I get the followng output:
curl -i -X GET -H 'X-Auth-Token:
rO0ABXc4ACAyYzlkYTk4ZDQwZGVmNWU2MDE0MGZjZDI0OThiMzk3MQAGbWdyb3N6AAQzMDQ3AAABQP0JOAs'
-H 'Content-Type: application/json' -H 'User-Agent: python-glanceclient' -k
https://cb.alucloud.local/al-openstack/v2/schemas/image
(9, 'Bad file descriptor')
*BUT* when I am running just the exact curl command you see in the debug log
curl -i -X GET -H 'X-Auth-Token:
rO0ABXc4ACAyYzlkYTk4ZDQwZGVmNWU2MDE0MGZjZDI0OThiMzk3MQAGbWdyb3N6AAQzMDQ3AAABQP0JOAs'
-H 'Content-Type: application/json' -H 'User-Agent: python-glanceclient' -k
https://cb.alucloud.local/al-openstack/v2/schemas/image
I get what am I expecting to get - the JSON schema:
HTTP/1.1 200 OK
Date: Sun, 08 Sep 2013 09:51:04 GMT
Content-Type: application/json
Content-Length: 4958
Connection: close
{type:object,properties:{id:{type:string},name:{type:string},visibility:{type:string,enum:[public,private]},file:{type:string},status:{type:string},minDisk:{type:integer},minRam:{type:integer},progress:{type:integer},userId:{type:string},metadata:{type:object},self:{type:string},size:{type:number},schema:{type:string},checksum:{type:string},customerId:{type:string},updated_at:{type:string},created_at:{type:string},container_format:{type:string,enum:[ovf,bare,aki,ari,ami]},disk_format:{type:string,enum:[raw,vhd,vmdk,vdi,iso,qcow2,aki,ari,ami]},name:image}
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
