Re: [openstack-dev] [Glance] [all] Proposal for new Glance core reviewers
+1 for both! Congrats :) On Nov 25, 2014, at 12:16 PM, Nikhil Komawar nikhil.koma...@rackspace.commailto:nikhil.koma...@rackspace.com wrote: Hi all, Please consider this email as a nomination for Erno and Alex (CC) for adding them to the list of Glance core reviewers. Over the last cycle, both of them have been doing good work with reviews, participating in the project discussions as well as taking initiatives to creatively improve the project. Their insights into project internals and it's future directions has been valuable too. Please let me know if anyone has concerns with this change. If there none brought up, I will make this membership change official in about a week. Thanks for your consideration and the hard work, Erno and Alex! Cheers! -Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] [oslo-vmware] Propose adding Radoslav to core team
+1 On Sep 15, 2014, at 9:37 AM, Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com wrote: Hi, I would like to propose Radoslav to be a core team member. Over the course of the J cycle he has been great with the reviews, bug fixes and updates to the project. Can the other core team members please update with your votes if you agree or not. Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] Image upload/download bandwidth cap
+1, That’s what suggested in the blueprint a year ago: https://blueprints.launchpad.net/glance/+spec/transfer-rate-limiting It looks like consensus during summit discussion that rate limiting should be a separate facility running as a proxy in front of glance.” Thanks, Arnaud On Aug 8, 2014, at 1:23 PM, Russell Bryant rbry...@redhat.commailto:rbry...@redhat.com wrote: On 08/08/2014 04:17 PM, Jay Pipes wrote: On 08/08/2014 08:49 AM, Tomoki Sekiyama wrote: Hi all, I'm considering how I can apply image download/upload bandwidth limit for glance for network QoS. There was a review for the bandwidth limit, however it is abandoned. * Download rate limiting https://review.openstack.org/#/c/21380/ Was there any discussion in the past summit about this not to merge this? Or, is there alternative way to cap the bandwidth consumed by Glance? I appreciate any information about this. Hi Tomoki :) Would it be possible to integrate traffic control into the network configuration between the Glance endpoints and the nova-compute nodes over the control plane network? https://urldefense.proofpoint.com/v1/url?u=http://www.lartc.org/lartc.html%23LARTC.RATELIMIT.SINGLEk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0Am=dshyVjCo6WO66P5gNLmupQU512o2hEOHZwAxFhhOFt8%3D%0As=d3df646cf78d4e527ad3b66bbba20c110333b6d1cd59c6da8ab4dc5981e5b432 Yep, that was my first thought as well. It seems like something that would ideally be handled outside of OpenStack itself. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] [Nova] Nominating Jay Pipes for nova-core
+1 On Jul 30, 2014, at 2:19 PM, Chris Behrens cbehr...@codestud.commailto:cbehr...@codestud.com wrote: +1 On Jul 30, 2014, at 2:02 PM, Michael Still mi...@stillhq.commailto:mi...@stillhq.com wrote: Greetings, I would like to nominate Jay Pipes for the nova-core team. Jay has been involved with nova for a long time now. He's previously been a nova core, as well as a glance core (and PTL). He's been around so long that there are probably other types of core status I have missed. Please respond with +1s or any concerns. References: https://review.openstack.org/#/q/owner:%22jay+pipes%22+status:open,n,z https://review.openstack.org/#/q/reviewer:%22jay+pipes%22,n,z https://urldefense.proofpoint.com/v1/url?u=http://stackalytics.com/?module%3Dnova-group%26user_id%3Djaypipesk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0Am=IppJUOxE0wpcWrqsgOU%2BMiy8NOVXZDIcFqt3W625XGc%3D%0As=424d8b5979fbe1982f94312e202772dbb03e323eaab03cadef6b64d6586dcb72 As a reminder, we use the voting process outlined at https://wiki.openstack.org/wiki/Nova/CoreTeam to add members to our core team. Thanks, Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] ova support in glance
Hi Malini, I would be pleased to work with you on the effort to make the import of OVA working out of tree using the Glance tasks. I am sure many people will be delighted by this feature and I also agree with Mark in the fact that there might be a problem a message by bringing this feature in the tree. Consequently, I definitely see a StackForge project as a good candidate for the import/export workflows we don’t want upstream in the Glance codebase. As mentioned at the meetup, we are not far to have the import tasks engine to be merged (we committed to less than 3 weeks). So, I think we can start working on this very soon. Thank you, Arnaud On Jul 26, 2014, at 10:39 AM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.commailto:gokrokvertsk...@mirantis.com wrote: Hi, Please take a look at this document: http://www.dmtf.org/sites/default/files/standards/documents/DSP0265_1.0.0.pdfhttps://urldefense.proofpoint.com/v1/url?u=http://www.dmtf.org/sites/default/files/standards/documents/DSP0265_1.0.0.pdfk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0Am=YQSwSUEuCghCz1eHV6bZWyeQ6YkFS3gVnL0vmjn9WXo%3D%0As=5f62a9a4a54977f16e77ad73943deb2e0826b51387f7bb7f4a3fea0e68278b01. There are clarifications of what is OVF and how it should be used. Check section 9 for use cases. From our experience OVA\OVF are used to deliver applications in form of pre-backed images + deployment options to successfully deploy this application. OVF format is close to TOSCA and can define not only resources but network configuration, startup scripts, software installation and license agreement for proprietary software. I want to highlight that OVA import procedure in VMWare ends with actual instance creation rather then keeping disk images. And there is a reason for that as OVF defines the deployment procedures and VMWare even will generate UI to ask specific deployment parameters like IP addresses, hostnames and Application specific options. We had OVA experience in Murano project. We had a customer who uses virtual appliances distributed in form of OVA. We had to convert them to a set of image+heat-template+murano workflow/UI. I think we are going to support Applications in OVA format in Murano as we already plan to support other formats like TOSCA and APS (Parallels application standard). Thanks Georgy On Sat, Jul 26, 2014 at 7:19 AM, Mark Washenberger mark.washenber...@markwash.netmailto:mark.washenber...@markwash.net wrote: Thanks for sending out this message Malini. I'm really pleased that the image import mechanism we've been working on in Glance for a while is going to be helpful for supporting this kind of use case. The problem that I see is one of messaging. If we tell end users that OpenStack can import and run OVAs I think we're probably setting ourselves up for a serious problem with expectations. Since an OVA is *not* an image, and actually could be much broader in scope or more constrained, I'm worried that this import will fail for most users most of the time. This just creates a negative impression of our cloud, and may cause a significant support headache for some of our deployers. The plan I propose to respond to this challenge is as follows: 1) develop the initial OVA image import out of tree - the basic functionality is just to grab the root disk out of the ova and to set image properties based on some of the ovf metadata 2) assess what the median level of OVA complexity is out there in the wild among OVA users 3) make sufficient progress with artifacts to ensure we can cover the median level of OVA complexity in an OpenStack accessible way - openstack accessible to me means there probably has to be qemu-image / libvirt / heat support for a given OVA concept 4) Bring OVA import into the main tree as part of the General Import [1] operation once that artifact progress has been made However, I'm very interested to know if there are some folks more embedded with operators and deployers who can reassure me that this OVA messaging problem can be dealt with another way. Thanks! [1] As a reminder, the General Import item on our hazy future backlog is different from Image Import in the following way. For an image import, you are explicitly trying to create an image. For the general import, you show up to the cloud with some information and just ask for it to be imported, the import task itself will inspect the data you provide to determine what, if anything, can be created for it. This works well for OVAs because we may want to produce a disk image, a block device mapping artifact, or even up to the level of a heat template. On Fri, Jul 25, 2014 at 7:08 PM, Bhandaru, Malini K malini.k.bhand...@intel.commailto:malini.k.bhand...@intel.com wrote: Hello Everyone! We were discussing the following blueprint in Glance: Enhanced-Platform-Awareness-OVF-Meta-Data-Import :https://review.openstack.org/#/c/104904/ The OVA format is
Re: [openstack-dev] [Glance][Trove] Metadata Catalog
Hi Denis, I think this is a perfect time for you to review the spec for the glance metadata catalog https://review.openstack.org/#/c/98554/ and see if it fits your use case. Also, we have a session tomorrow at 9:00am PST at the Glance meetup to discuss this topic. I think it would be useful if you could join (in person or remotely). Please see the details: https://wiki.openstack.org/wiki/Glance/JunoCycleMeetup Thank you, Arnaud On Jul 24, 2014, at 6:32 AM, Denis Makogon dmako...@mirantis.commailto:dmako...@mirantis.com wrote: 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
[openstack-dev] [Glance] Juno mid-cyle meetup last minute updates
Greetings, A couple of updates for the meetup tomorrow: - The schedule of the meetup can be found here: https://wiki.openstack.org/wiki/Glance/JunoCycleMeetup - We will start at 9:00 AM PST: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140725T09p1=1240 - It will be possible to join remotely the meetup through Webex. Please ping me (arnaud) on IRC to get the Webex URL and passcode. Hopefully, the experience won’t be too bad… - The address has been updated: VMware, Inc 3425 Hillview Avenue - Building Hilltop A (HTA) Palo Alto, CA 94304 USA - Directions to VMware: http://www.vmware.com/files/pdf/company/vmw-directions-to-vmware.pdf That’s pretty much it! Best, Arnaud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][glance] Allow Nova to use either Glance V1 or V2: Call for reviews to get the spec merged
The spec to allow Nova to support Glance v1 and v2 got an exception for the Juno Spec Freeze: see [1]. The spec has been created in April and went through 16 iterations. The spec has been discussed several times already especially at the last Glance meetup in Washington D.C. A couple of updates: - The performances issues found in V2 have been fixed [2] - We will use Glance V1 as the default API in Juno (see comments about that here [3]) - The changes made to the Nova codebase won’t be destructive meaning that each Nova functionality will be working equally with V1 and V2. I think this is a good time to get this approved and go forward. Please review the spec as soon as possible to get it merged: https://review.openstack.org/#/c/84887/ Thanks, Arnaud [1] https://etherpad.openstack.org/p/nova-juno-spec-priorities [2] http://git.openstack.org/cgit/openstack/glance/commit/?id=0711daa7c27af0332d39dd7a2d906205611cce8b [3] https://review.openstack.org/#/c/84887/14/specs/juno/use-glance-v2-api.rst ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo][infra] issue with a requirement update
Greetings, I am facing an issue and looking for guidance/best practice. So, here is the problem: - glance [stable/icehouse] contains a requirement to oslo.vmware = 0.2 [1] and consequently requirements/global-requirements [stable/icehouse] also contains oslo.vmware = 0.2.[2] So far nothing wrong. - a requirement/global-requirement to the retrying library has been added in master [3]. - now, if we add the retrying requirement to oslo.vmware in master, grenade fails [4] because stable/icehouse will pick the latest version of oslo.vmware (containing retrying) but using requirements/global-requirements [stable/icehouse] which doesn’t contain retrying. So, I can see two options: 1. pin the oslo.vmware version in stable/icehouse. something like oslo.vmware = 0.2,0.4. This means two patches: one in requirements/global-requirements and one in glance. I am not sure if it is OK to have requirements/global-requirements and glance having different version intervals for some time: global-requirements would contain oslo.vmware = 0.2,0.4 but glance would contain oslo.vmware = 0.2. Does Glance requirements and global-requirements need to contain the exact version interval for a given library at any time? or the fact that = 0.2,0.4 includes = 0.2 is enough? in which case, this seems the way to go. 2. add the retrying requirement to global-requirements [stable/icehouse], but this would mean that for any new library added to oslo.vmware (not being in the requirements of a previous release), we would have the same problem. [1] https://github.com/openstack/glance/blob/stable/icehouse/requirements.txt#L30 [2] https://github.com/openstack/requirements/blob/stable/icehouse/global-requirements.txt#L52 [3] https://github.com/openstack/requirements/blob/master/global-requirements.txt#L182 [4] https://review.openstack.org/#/c/106488/ Thank you, Arnaud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [glance] Bug Days - July 15/16
Hi All, Glance is going to have bug days next week on July Tuesday 15 and Wednesday 16. This is a two-days bug day to accommodate most of the Glance contributors (time zones, etc.). Of course, You do not need to be 100% two days… This is a great opportunity to: - triage bugs - fix bugs - tag bugs and hopefully make Glance better…! Please register yourself on the wiki page if you plan to participate: https://etherpad.openstack.org/p/glance-bug-day We will be hanging out on #openstack-glance. We seriously need help so even the bare minimum will be better than nothing…! A couple of links: - All Glance bugs: https://bugs.launchpad.net/glance - Bugs that have gone stale: https://bugs.launchpad.net/glance/+bugs?orderby=date_last_updatedfield.status%3Alist=INPROGRESSassignee_option=anyhttps://bugs.launchpad.net/glance/+bugs?orderby=date_last_updatedfield.status:list=INPROGRESSassignee_option=any - Untriaged bugs: https://bugs.launchpad.net/glance/+bugs?field.searchtext=orderby=-importancesearch=Searchfield.status:list=NEWassignee_option=anyfield.assignee=field.bug_reporter=field.bug_commenter=field.subscriber=field.structural_subscriber=field.tag=field.tags_combinator=ANYfield.has_cve.used=field.omit_dupes.used=field.omit_dupes=onfield.affects_me.used=field.has_patch.used=field.has_branches.used=field.has_branches=onfield.has_no_branches.used=field.has_no_branches=onfield.has_blueprints.used=field.has_blueprints=onfield.has_no_blueprints.used=field.has_no_blueprints=on https://bugs.launchpad.net/glance/+bugs?field.searchtext=orderby=-importancesearch=Searchfield.status:list=NEWassignee_option=anyfield.assignee=field.bug_reporter=field.bug_commenter=field.subscriber=field.structural_subscriber=field.tag=field.tags_combinator=ANYfield.has_cve.used=field.omit_dupes.used=field.omit_dupes=onfield.affects_me.used=field.has_patch.used=field.has_branches.used=field.has_branches=onfield.has_no_branches.used=field.has_no_branches=onfield.has_blueprints.used=field.has_blueprints=onfield.has_no_blueprints.used=field.has_no_blueprints=on - Bugs without owners: https://bugs.launchpad.net/glance/+bugs?field.searchtext=orderby=-importancesearch=Searchfield.status%3Alist=NEWfield.status%3Alist=CONFIRMEDfield.status%3Alist=TRIAGEDfield.status%3Alist=INPROGRESSassignee_option=nonefield.assignee=field.bug_reporter=field.bug_commenter=field.subscriber=field.structural_subscriber=field.tag=field.tags_combinator=ANYfield.has_cve.used=field.omit_dupes.used=field.omit_dupes=onfield.affects_me.used=field.has_patch.used=field.has_branches.used=field.has_branches=onfield.has_no_branches.used=field.has_no_branches=onfield.has_blueprints.used=field.has_blueprints=onfield.has_no_blueprints.used=field.has_no_blueprints=onhttps://bugs.launchpad.net/glance/+bugs?field.searchtext=orderby=-importancesearch=Searchfield.status:list=NEWfield.status:list=CONFIRMEDfield.status:list=TRIAGEDfield.status:list=INPROGRESSassignee_option=nonefield.assignee=field.bug_reporter=field.bug_commenter=field.subscriber=field.structural_subscriber=field.tag=field.tags_combinator=ANYfield.has_cve.used=field.omit_dupes.used=field.omit_dupes=onfield.affects_me.used=field.has_patch.used=field.has_branches.used=field.has_branches=onfield.has_no_branches.used=field.has_no_branches=onfield.has_blueprints.used=field.has_blueprints=onfield.has_no_blueprints.used=field.has_no_blueprints=on Cheers, Arnaud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance] Unifying configuration file
@ZhiYan: I don't like the idea of removing the sample configuration file(s) from the git repository. Many people do not want to have to checkout the entire codebase and tox every time they have to verify a variable name in a configuration file. I know many people who were really frustrated where they realized that the sample config file was gone from the Nova repo. However, I agree with the fact that it would be better if the sample was 100% accurate: so the way I would love to see this working is to generate the sample file every time there is a config change (this being totally automated (maybe at the gate level...)). @Julien: I would be interested to understand the value that you see of having only one config file? At this point, I don't see why managing one file is more complicated than managing several files especially when they are organized by categories. Also, scrolling through the registry settings every time I want to modify an api setting seem to add some overhead. Thanks, Arnaud - Original Message - From: Zhi Yan Liu lzy@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, June 17, 2014 7:47:53 AM Subject: Re: [openstack-dev] [glance] Unifying configuration file Frankly I don't like the idea of using single configuration for all service too, I think it will be cool if we can generate separated configuration template files automatically for each Glance service. So besides https://review.openstack.org/#/c/83327/ , actually I'm working on that idea as well, to allow deployer generates separated configuration files on demand, and then probably we could move those templates away from code repo. But I like your idea for paste.ini template part. zhiyan On Tue, Jun 17, 2014 at 10:29 PM, Kuvaja, Erno kuv...@hp.com wrote: I do not like this idea. As now we are on 5 different config files (+ policy and schema). One for each (API and Registry) would still be ok, but putting all together would just become messy. If the *-paste.ini will be migrated to .conf files that would bring it down, but please do not try to mix reg and API configs together. - Erno (jokke) Kuvaja -Original Message- From: Flavio Percoco [mailto:fla...@redhat.com] Sent: 17 June 2014 15:19 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [glance] Unifying configuration file On 17/06/14 15:59 +0200, Julien Danjou wrote: Hi guys, So I've started to look at the configuration file used by Glance and I want to switch to one configuration file only. I stumbled upon this blueprint: https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/glance/%2Bspec/use-oslo-configk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0Am=QTguordmDDZNC%2FRUVedjVKf5cPErz5dhlJAZA56YqWU%3D%0As=ce068ea89b0fbf4260f6f8f18758f99b407536ec391c7c7392a079fc550ba468 w.r.t using config.generator https://review.openstack.org/#/c/83327/ which fits. Does not look like I can assign myself to it, but if someone can do so, go ahead. So I've started to work on that, and I got it working. My only problem right now, concerned the [paste_deploy] options that is provided by Glance. I'd like to remove this section altogether, as it's not possible to have it and have the same configuration file read by both glance-api and glance-registry. My idea is also to unify glance-api-paste.ini and glance-registry-paste.ini into glance-paste.ini and then have each server reads their default pipeline (pipeline:glance-api). Does that sounds reasonable to everyone? +1, it sounds like a good idea. I don't think we need to maintain 2 separate config files, especially now that the registry service is optional. Thanks for working on this. Flavio -- @flaper87 Flavio Percoco ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance] Unifying configuration file
All the things that you mention here seem to be technical difficulties. I don't think technical difficulties should drive the experience of the user. Also, Zhi Yan seems to be able to make that happen :) Thanks, Arnaud - Original Message - From: Julien Danjou jul...@danjou.info To: Arnaud Legendre alegen...@vmware.com Cc: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, June 17, 2014 8:43:38 AM Subject: Re: [openstack-dev] [glance] Unifying configuration file On Tue, Jun 17 2014, Arnaud Legendre wrote: @ZhiYan: I don't like the idea of removing the sample configuration file(s) from the git repository. Many people do not want to have to checkout the entire codebase and tox every time they have to verify a variable name in a configuration file. I know many people who were really frustrated where they realized that the sample config file was gone from the Nova repo. However, I agree with the fact that it would be better if the sample was 100% accurate: so the way I would love to see this working is to generate the sample file every time there is a config change (this being totally automated (maybe at the gate level...)). You're a bit late on this. :) So what I did these last months (year?) in several project, is to check at gate time the configuration file that is automatically generated against what's in the patches. That turned out to be a real problem because sometimes some options changes from the eternal module we rely on (e.g. keystone authtoken or oslo.messaging). In the end many projects (like Nova) disabled this check altogether, and therefore removed the generated configuration file From the git repository. @Julien: I would be interested to understand the value that you see of having only one config file? At this point, I don't see why managing one file is more complicated than managing several files especially when they are organized by categories. Also, scrolling through the registry settings every time I want to modify an api setting seem to add some overhead. Because there's no way to automatically generate several configuration files with each its own set of options using oslo.config. Glance is (one of?) the last project in OpenStack to manually write its sample configuration file, which are not up to date obviously. So really this is mainly about following what every other projects did the last year(s). -- Julien Danjou -- Free Software hacker -- https://urldefense.proofpoint.com/v1/url?u=http://julien.danjou.info/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0Am=a7BLHSmThzpuZ12zhxZOghcz1HWzlQNCbEAXFoAcFSY%3D%0As=fe3ff048464bdba926f7da2f19834adba8df90b69fdb2ddd63a35f8288e7fed2 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Nominating Nikhil Komawar for Core
+1 Good job Nikhil! - Original Message - From: Brian Rosmaita brian.rosma...@rackspace.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, June 12, 2014 10:15:07 AM Subject: Re: [openstack-dev] [Glance] Nominating Nikhil Komawar for Core +1 From: Kuvaja, Erno [kuv...@hp.com] Sent: Thursday, June 12, 2014 9:34 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Nominating Nikhil Komawar for Core +1 From: Alex Meade [mailto:mr.alex.me...@gmail.com] Sent: 12 June 2014 13:56 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Nominating Nikhil Komawar for Core +100 it's about time! On Thu, Jun 12, 2014 at 3:26 AM, Mark Washenberger mark.washenber...@markwash.net wrote: Hi folks, I'd like to nominate Nikhil Komawar to join glance-core. His code and review contributions over the past years have been very helpful and he's been taking on a very important role in advancing the glance tasks work. If anyone has any concerns, please let me know. Otherwise I'll make the membership change next week (which is code for, when someone reminds me to!) Thanks! markwash ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Glance] Mid Cycle Meetup
Hi Folks We are currently working on the logistic to organize the Glance mid-cycle meetup. What we know so far: - it will happen in California, USA (either in Palo Alto or San Francisco), - it will be a 3 days event in the week Jul 28th - Aug 1st (either Monday to Wednesday or Tuesday to Thursday), With that in mind, please add yourself to this etherpad if you think you will be able to attend: https://etherpad.openstack.org/p/glance-juno-mid-cycle-meeting This will help a lot for the organization! Thank you, Arnaud - Original Message - From: Mark Washenberger mark.washenber...@markwash.net To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Sent: Thursday, May 15, 2014 10:26:47 AM Subject: [openstack-dev] [Glance] Mid Cycle Meetup Survey Hi Folks! Ashwhini has put together a great survey to help us plan our Glance mid cycle meetup. Please fill it out if you think you might be interested in attending! In particular we're trying to figure out sponsorship and location. If you have no location preference, feel free to leave those check boxes blank. https://docs.google.com/forms/d/1rygMU1fXcBYn9_NgvEtjoCXlRQtlIA1UCqsQByxbTA8/viewform Cheers, markwash ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0Am=SHx25gcyyMWZZfoV01a%2Bkquv%2FsR5nVAjRLZQfrSobeI%3D%0As=0ae22f23cbd0591f9b0f53977ad078d6f60ed41629c39c6d0f941cebb530ee62 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Announcing glance-specs repo
Greetings! The glance-specs repository is now opened! - If you have a blueprint that is targeted for Juno-1 and Approved: you do not need to create a spec. Only two blueprints seem to fall into this category. See [1] for more details. - If you have a blueprint in Launchpad (approved or not, targeted or not): please create a spec and add a reference to the Launchpad blueprint in the spec. - If you want to submit a new blueprint: please create a spec. You do not need to create a Launchpad blueprint . The LP blueprint will be automatically created for you when the spec is approved. All the information to create the specs are in the readme [2] and the template [3]. The spec needs to be created in the juno folder ( path: root / specs / juno ) Feel free to modify the template if you think something is not correct. If you have a problem or concern: please ping us (markwash, rosmaita, myself). Thank you! Arnaud [1] https://launchpad.net/glance/+milestone/juno-1 [2] http://git.openstack.org/cgit/openstack/glance-specs/tree/README.rst [3] http://git.openstack.org/cgit/openstack/glance-specs/tree/specs/template.rst - Original Message - From: Mark Washenberger mark.washenber...@markwash.net To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Sent: Friday, April 25, 2014 2:42:09 PM Subject: [openstack-dev] [Glance] Announcing glance-specs repo Hey hey glancy glance, Recently glance drivers made a somewhat snap decision to adopt the -specs gerrit repository approach for new blueprints. Pursuant to that, Arnaud has been kind enough to put forward some infra patches to set things up. After the patches to create the repo [1] and enable tests [2] land, we will need one more patch to add the base framework to the glance-specs repo, so there is a bit of time needed before people will be able to submit their specs. I'd like to see us use this system for Juno blueprints. I think it would also be very helpful if any blueprints being discussed at the design summit could adopt this format in time for review prior to the summit (which is just over two weeks away). I understand that this is all a bit late in the game to make such requirements, so obviously we'll try to be very understanding of any difficulties. Additionally, if any glance folks have serious reservations about adopting the glance-specs repo, please speak up now. Thanks again to Arnaud for spearheading this effort. And thanks to the Nova crew for paving a nice path for us to follow. Cheers, markwash [1] - https://review.openstack.org/#/c/90461/ [2] - https://review.openstack.org/#/c/90469/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0Am=BfXWjsBQnTnW3S%2BoFiToxN%2FTJ7aYKCiy42uiAosEmnA%3D%0As=a471bedf059056126e8eade6f94d20db62f8426d4c385ad923d87be8619ba424 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] An analysis of code review in Nova
Hi Matt, I totally agree with you and actually we have been discussing this a lot internally the last few weeks. . As a top priority, the driver MUST integrate with oslo.vmware. This will be achieved through this chain of patches [1]. We want these patches to be merged before other things. I think we should stop introducing more complexity which makes the task of refactoring more and more complicated. The integration with oslo.vmware is not a refactoring but should be seen as a way to get a more lightweight version of the driver which will make the task of refactoring a bit easier. . Then, we want to actually refactor, we got several meetings to know what is the best strategy to adopt going forward (and avoid reproducing the same mistakes). The highest priority is spawn(): we need to make it modular, remove nested methods. This refactoring work should include the integration with the image handler framework [2] and introducing the notion of image type object to avoid all these conditions on types of images inside the core logic. . I would like to see you cores to be involved in this design since you will be reviewing the code at some point. involved here can be interpreted as review the design, and/ or actually participate to the design discussions. I would like to get your POV on this. Let me know if this approach makes sense. Thanks, Arnaud [1] https://review.openstack.org/#/c/70175/ [2] https://review.openstack.org/#/c/33409/ - Original Message - From: Matt Riedemann mrie...@linux.vnet.ibm.com To: openstack-dev@lists.openstack.org Sent: Wednesday, March 12, 2014 11:28:23 AM Subject: Re: [openstack-dev] [nova] An analysis of code review in Nova On 2/25/2014 6:36 AM, Matthew Booth wrote: I'm new to Nova. After some frustration with the review process, specifically in the VMware driver, I decided to try to visualise how the review process is working across Nova. To that end, I've created 2 graphs, both attached to this mail. Both graphs show a nova directory tree pruned at the point that a directory contains less than 2% of total LOCs. Additionally, /tests and /locale are pruned as they make the resulting graph much busier without adding a great deal of useful information. The data for both graphs was generated from the most recent 1000 changes in gerrit on Monday 24th Feb 2014. This includes all pending changes, just over 500, and just under 500 recently merged changes. pending.svg shows the percentage of LOCs which have an outstanding change against them. This is one measure of how hard it is to write new code in Nova. merged.svg shows the average length of time between the ultimately-accepted version of a change being pushed and being approved. Note that there are inaccuracies in these graphs, but they should be mostly good. Details of generation here: https://urldefense.proofpoint.com/v1/url?u=https://github.com/mdbooth/heatmapk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0Am=q%2BhYPEq%2BGxlDrGrMdbYCWuaLhZOwXwRpMQwWxkSied4%3D%0As=9a9e8ba562a81e0d00ca4190fbda306617637473ba5e721e4071d8d0ae20175c. This code is obviously single-purpose, but is free for re-use if anyone feels so inclined. The first graph above (pending.svg) is the one I was most interested in, and shows exactly what I expected it to. Note the size of 'vmwareapi'. If you check out Nova master, 24% of the vmwareapi driver has an outstanding change against it. It is practically impossible to write new code in vmwareapi without stomping on an oustanding patch. Compare that to the libvirt driver at a much healthier 3%. The second graph (merged.svg) is an attempt to look at why that is. Again comparing the VMware driver with the libvirt we can see that at 12 days, it takes much longer for a change to be approved in the VMware driver than in the libvirt driver. I suspect that this isn't the whole story, which is likely a combination of a much longer review time with very active development. What's the impact of this? As I said above, it obviously makes it very hard to come in as a new developer of the VMware driver when almost a quarter of it has been rewritten, but you can't see it. I am very new to this and others should validate my conclusions, but I also believe this is having a detrimental impact to code quality. Remember that the above 12 day approval is only the time for the final version to be approved. If a change goes through multiple versions, each of those also has an increased review period, meaning that the time from first submission to final inclusion is typically very, very protracted. The VMware driver has its fair share of high priority issues and functionality gaps, and the developers are motived to get it in the best possible shape as quickly as possible. However, it is my impression that when problems stem from structural issues, the developers choose to add metaphorical gaffer tape rather than fix them,
Re: [openstack-dev] [Glance][Artifacts] Artifact dependencies: Strict vs Soft
Hi Alexander, Thank you for your input. I think we need to clearly define what a version means for an artifact. First, I would like to comeback to the definition of an artifact: this broader audience might not be aware of this concept. As of today, my understanding is the following: An artifact is a set of metadata without any pre-defined structure. The only contract is that these artifacts will reference one or many blocks of bits (potentially images) stored in the Glance storage backends. With that in mind, I can see two types of versions: metadata version and the version of the actual bits. I think the version you are talking about is a mix of two versions you I mention above. Could you confirm? Now, I have another question: you mention that you have can several versions of an artifact accessible in the system: does that mean that the previous versions are still available (i.e. both metadata and actual blocks of data are available)? Can I rollback and use version #1 if the latest version of my artifact is version #2? Based on your question, I think the answer is Yes in which case this comes with a lot of other issues: we are dealing with block of data that can have big sizes: you need to give the ability to the user to say: I want to store only the last 2 versions and not the full history. So, to answer you question, I would like to see an API which is providing all the versions available (accessible) for a given artifact. Then, it's up to the artifact using it to decide which one it should import. Thanks, Arnaud - Original Message - From: Alexander Tivelkov ativel...@mirantis.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, February 25, 2014 3:57:41 AM Subject: [openstack-dev] [Glance][Artifacts] Artifact dependencies: Strict vs Soft Hi folks, While I am still working on designing artifact-related APIs (sorry, the task is taking me longer then expected due to a heavy load in Murano, related to the preparation of incubation request), I've got a topic I wanted to discuss with the broader audience. It seems like we have agreed on the idea that the artifact storage should support dependencies between the artifacts: ability for any given artifact to reference some other artifacts as its dependencies, and the API call which will allow to retrieve all the dependency graph of the given artifact (i.e. its direct and transitive dependecies) Another idea which was always kept in mind when we were designing the artifact concept was artifact versioning: the system should allow to store different artifact having the identical name but different versions, and the API should be able to return the latest (based on some notation) version of the artifact. Being able to construct such a queries actually gives an ability to define kind of aliases, so the url like /v2/artifacts?type=imagename=ubuntuversion=latest will always return the latest version of the given artifact (ubuntu image in this case). The need to be able to define such aliaces was expressed in [1], and the ability to satisfy this need with artifact API was mentioned at [2] But combining these two ideas brings up an interesting question: how should artifacts define their dependencies? Should this be an explicit strict reference (i.e. referencing the specific artifact by its id), or it should be an implicit soft reference, similar to the alias described above (i.e. specifying the dependency as A requires the latest version of B or even A requires 0.2=B0.3)? The later seems familiar: it is similar to pip dependency specification, right? This approach obviosuly may be very usefull (at least I clearly see its benefits for Murano's application packages), but it implies lazy evaluation, which may dramatically impact the performance. In contrary, the former approach - with explicit references - requires much less computation. Even more, if we decide that the artifact dependencies are immutable, this will allow us to denormalize the storage of the dependency graph and store all the transitive dependencies of the given artifact in a flat table, so the dependency graph may be returned by a sinle SQL query, without a need for recursive calls, which are otherwise unavoidable in the normalized database storing such hierarchical structures. Meanwhile, the mutability of dependencis is also unclear to me: ability to modify them seems to have its own pros and cons, so this is another topic to dicsuss. I'd like to hear your opinion on all of these. Any feedback is welcome, and we may come back to this topic on the Thursday's meeting. Thanks! [1] https://blueprints.launchpad.net/glance/+spec/glance-image-aliases [2] https://blueprints.launchpad.net/glance/+spec/artifact-repository-api -- Regards, Alexander Tivelkov ___ OpenStack-dev mailing list
Re: [openstack-dev] [Nova][VMware] Deploy from vCenter template
Hi Qui Xing, We are planning to address the vCenter template issue by levering the OVF/OVA capabilities. Kiran's implementation is tied to a specific VC and requires to add Glance properties that are not generic. For existing templates, the workflow will be: . generate an *.ova tarball (containing the *.ovf descriptor + *.vmdk stream-optimized) out of the template, . register the *.ova as a Glance image location (using the VMware Glance driver see bp [1]) or simply upload the *.ova to another Glance store, . The VMware driver in Nova will be able to consume the *.ova (either through the location or by downloading the content to the cache): see bp [2]. However, for Icehouse, we are not planning to actually consume the *.ovf descriptor (work scheduled for the J/K release). [1] https://blueprints.launchpad.net/glance/+spec/vmware-datastore-storage-backend [2] https://blueprints.launchpad.net/nova/+spec/vmware-driver-ova-support If you have questions about [1], please send me an email. For [2], please reach vuil. Thanks, Arnaud - Original Message - From: Shawn Hartsock harts...@acm.org To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Monday, December 16, 2013 9:37:34 AM Subject: Re: [openstack-dev] [Nova][VMware] Deploy from vCenter template IIRC someone who shows up at https://wiki.openstack.org/wiki/Meetings/VMwareAPI#Meetings is planning on working on that again for Icehouse-3 but there's some new debate on the best way to implement the desired effect. The goal of that change would be to avoid streaming the disk image out of vCenter for the purpose of then streaming the same image back into the same vCenter. That's really inefficient. So there's a Nova level change that could happen (that's the patch you saw) and there's a Glance level change that could happen, and there's a combination of both approaches that could happen. If you want to discuss it informally with the group that's looking into the problem I could probably make sure you end up talking to the right people on #openstack-vmware or if you pop into the weekly team meeting on IRC you could mention it during open discussion time. On Mon, Dec 16, 2013 at 3:27 AM, Qing Xin Meng mengq...@cn.ibm.com wrote: I saw a commit for Deploying from VMware vCenter template and found it's abandoned. https://review.openstack.org/#/c/34903 Anyone knows the plan to support the deployment from VMware vCenter template? Thanks! Best Regards ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- # Shawn.Hartsock - twitter: @hartsock - plus.google.com/+ShawnHartsock ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0Am=KCBtvBVSZCslDQrTvSEqBcTEcx%2FSKxtF0ZRIjtTFmSw%3D%0As=f45fbe293564be6a16c90b0125534e5e62f7505fea9f92708b72aa60e5e1dc5f ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
