Re: [openstack-dev] [OpenStack-Dev][Cinder] Cinder Core nomination
On 06:55 Thu 14 Aug , Boring, Walter wrote: Hey guys, I wanted to pose a nomination for Cinder core. Xing Yang. She has been active in the cinder community for many releases and has worked on several drivers as well as other features for cinder itself. She has been doing an awesome job doing reviews and helping folks out in the #openstack-cinder irc channel for a long time. I think she would be a good addition to the core team. +1 If you take a look at the last 3 months [1][2] she has been very active and providing great feedback in reviews. She has also been setting great expectations for other drivers with the recent third-party CI work. Thanks Xing! [1] - http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt [2] - http://stackalytics.com/?user_id=xing-yang -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Cinder plans for kilo: attention new driver authors!
On 17:18 Sun 07 Sep , Amit Das wrote: I had submitted the CloudByte driver code during juno and currently grappling with various aspects of setting up the CI for the same. It also requires a copy of tempest logs which also is a in progress item. Will above be automatically eligible for Kilo if above gets done before Kilo freeze dates. Do I need to follow any other processes? The driver code and cert test should be submitted before K-1. It would be great if you could communicate better that this is in progress. I asked for the cert test results and the status with your CI back on August 10th [1], and assumed this driver submission was already abandoned with no answer. [1] - https://review.openstack.org/#/c/102511/ -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Request for J3 Feature Freeze Exception
On 19:32 Fri 05 Sep , David Pineau wrote: So I asked Duncan what could be done, learned about the FFE, and I am now humbly asking you guys to give us a last chance to get in for Juno. I was told that if it was possible the last delay would be next week, and believe me, we're doing everything we can on our side to be able to meet that. As given in the comments [1], there will be a better chance for an exception with this after cert results are provided. [1] - https://review.openstack.org/#/c/110236/ -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Request for J3 FFE - add reset-state function for backups
On 12:23 Tue 09 Sep , yunling wrote: Hi Cinder Folks,I would like to request a FFE for add reset-state function for backups[1][2].The spec of add reset-state function for backups has been reviewed and merged[2]. These code changes have been well tested and are not very complex[3]. I would appreciate any consideration for an FFE.Thanks, It looks like the current review has some comments that are waiting too be addressed now. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Request for J3 FFE - NetApp: storage pools for scheduler
On 14:24 Fri 05 Sep , Alex Meade wrote: Hi Cinder Folks, I would like to request a FFE for cinder pools support with the NetApp drivers[1][2]. Looks like this is being reviewed now. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cinder] PTL Candidacy
Hello all, My name is Mike Perez, and I would like to be your next PTL for the OpenStack block storage project Cinder. I've been involved with the OpenStack community since October 2010. I'm a senior developer for Datera, which contributes to Linux Bcache and the Linux-IO SCSI Target (LIO) in the Linux kernel (which some Cinder setups use underneath for target management). Before that I was for seven years a senior developer for DreamHost, working on their core products and storage in their OpenStack public cloud. Since November 2012 I've been a core developer for Cinder. Besides code reviews, my main contributions include creating the v2 API, writing the v2 API reference and spec docs and rewriting the v1 api docs. These are contributions that I feel were well thought out and complete. This is exactly how I would like to see the future of Cinder's additional contributions and would like to lead the team in that direction. Over the years I've advocated for OpenStack [1][2][3][4] and its community to bring in more contributors by teaching the basics of Cinder's design, which then can be applied to a project a potential contributor is interested in. I also contribute to programs such as the Women Who Code event [5][6] to help get future OpenStack interns in the Gnome Outreach Program excited to help the project. I feel, as a leader, helping to build a healthy diverse community is key. I would like to continue to help the Cinder team with focusing on what the bigger picture is. Not letting us get lost in long discussion, but come to a consensus sooner and start making better progress now. Some of this includes better organizing of the blueprints and better triaging of bugs so contributors can use tools more effectively [7]. I would also like to guide folks with their ideas early on as something that fits with the project or not. For the Kilo release, a lot of features have a dependency on a state machine. I agree with the rest of Cinder contributors, this needs to happen now so that we can can progress forward. I have a summit session with an approach as discussed in the previous Cinder Mid-cycle meet up [8] to drive this important change forward. Lastly, rolling upgrades is being picked back up, and I will be showing interest in reviews and discussion with helping the contributors focus to bring this wonderful feature forward. These are the only changes I'm mentioning as I'm sure we'll need bandwidth for other necessary features that contributors will be bringing in. I'm looking forward to continuing to grow, and the opportunity to contribute to this project in new ways. Thanks, Mike Perez [1] - http://www.meetup.com/OpenStack-Northwest/events/151114422 [2] - http://www.meetup.com/meetup-group-NjZdcegA/events/150630962 [3] - http://www.meetup.com/OpenStack-Seattle/events/159943872 [4] - http://www.meetup.com/openstack/events/150932582/ [5] - http://www.meetup.com/Women-Who-Code-SF/events/195850392/ [6] - http://www.meetup.com/Women-Who-Code-SF/events/195850922/ [7] - http://status.openstack.org/reviews/ [8] - https://etherpad.openstack.org/p/cinder-meetup-summer-2014 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Not seeking another term as PTL
On 08:57 Tue 23 Sep , John Griffith wrote: Hey Everyone, I've been kinda mixed on this one, but I think it's a good time for me to not run for Cinder PTL. I've been filling the role since we started the idea back at the Folsom Summit, and it's been an absolute pleasure and honor for me. I don't plan on going anywhere and will still be involved as I am today, but hopefully I'll also now have a good opportunity to contribute elsewhere in OpenStack. We have a couple of good candidates running for Cinder PTL as well as a strong team backing the project so I think it's a good time to let somebody else take the official PTL role for a bit. Thanks, John Thanks John for initially making me feel welcomed in the Cinder team. I don't think I would be where I am today if it wasn't for the encouragements you've given me in the past. I also appreciate the foundation and original goal you've set for Cinder for us all to continue to follow today. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Support for Pecan in Nova
On 10:06 Thu 12 Dec , Christopher Yeoh wrote: On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann doug.hellm...@dreamhost.comwrote: On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello ryan.petre...@dreamhost.com wrote: Hello, I’ve spent the past week experimenting with using Pecan for Nova’s API, and have opened an experimental review: https://review.openstack.org/#/c/61303/6 …which implements the `versions` v3 endpoint using pecan (and paves the way for other extensions to use pecan). This is a *potential* approach I've considered for gradually moving the V3 API, but I’m open to other suggestions (and feedback on this approach). I’ve also got a few open questions/general observations: 1. It looks like the Nova v3 API is composed *entirely* of extensions (including “core” API calls), and that extensions and their routes are discoverable and extensible via installed software that registers itself via stevedore. This seems to lead to an API that’s composed of installed software, which in my opinion, makes it fairly hard to map out the API (as opposed to how routes are manually defined in other WSGI frameworks). I assume at this time, this design decision has already been solidified for v3? Yeah, I brought this up at the summit. I am still having some trouble understanding how we are going to express a stable core API for compatibility testing if the behavior of the API can be varied so significantly by deployment decisions. Will we just list each required extension, and forbid any extras for a compliant cloud? Maybe the issue is caused by me misunderstanding the term extension, which (to me) implies an optional component but is perhaps reflecting a technical implementation detail instead? Yes and no :-) As Ryan mentions, all API code is a plugin in the V3 API. However, some must be loaded or the V3 API refuses to start up. In nova/api/openstack/__init__.py we have API_V3_CORE_EXTENSIONS which hard codes which extensions must be loaded and there is no config option to override this (blacklisting a core plugin will result in the V3 API not starting up). So for compatibility testing I think what will probably happen is that we'll be defining a minimum set (API_V3_CORE_EXTENSIONS) that must be implemented and clients can rely on that always being present on a compliant cloud. But clients can also then query through /extensions what other functionality (which is backwards compatible with respect to core) may also be present on that specific cloud. This really seems similar to the idea of having a router class, some controllers and you map them. From my observation at the summit, calling everything an extension creates confusion. An extension extends something. For example, Chrome has extensions, and they extend the idea of the core features of a browser. If you want to do more than back/forward, go to an address, stop, etc, that's an extension. If you want it to play an audio clip stop, hammer time after clicking the stop button, that's an example of an extension. In OpenStack, we use extensions to extend core. Core are the essential feature(s) of the project. In Cinder for example, core is volume. In core you can create a volume, delete a volume, attach a volume, detach a volume, etc. If you want to go beyond that, that's an extension. If you want to do volume encryption, that's an example of an extension. I'm worried by the discrepancies this will create among the programs. You mentioned maintainability being a plus for this. I don't think it'll be great from the deployers perspective when you have one program that thinks everything is an extension and some of them have to be enabled that the deployer has to be mindful of, while the rest of the programs consider all extensions to be optional. Thanks, Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] weekly meeting
I agree with Qin here that alternating might be a good option. I'm not opposed to being present to both meetings though. -Mike Perez On Mon, Dec 16, 2013 at 9:31 PM, Qin Zhao chaoc...@gmail.com wrote: Hi John, Yes, alternating the time for each week should be fine. I just change my gmail name to English... I think you can see my name now... On Tue, Dec 17, 2013 at 12:05 PM, John Griffith john.griff...@solidfire.com wrote: On Mon, Dec 16, 2013 at 8:57 PM, 赵钦 chaoc...@gmail.com wrote: Hi John, I think the current meeting schedule, UTC 16:00, basically works for China TZ (12AM), although it is not perfect. If we need to reschedule, I think UTC 05:00 is better than UTC 04:00, since UTC 04:00 (China 12PM) is our lunch time. On Tue, Dec 17, 2013 at 11:04 AM, John Griffith john.griff...@solidfire.com wrote: Hi All, Prompted by a recent suggestion from Tom Fifield, I thought I'd gauge some interest in either changing the weekly Cinder meeting time, or proposing a second meeting to accomodate folks in other time-zones. A large number of folks are already in time-zones that are not friendly to our current meeting time. I'm wondering if there is enough of an interest to move the meeting time from 16:00 UTC on Wednesdays, to 04:00 or 05:00 UTC? Depending on the interest I'd be willing to look at either moving the meeting for a trial period or holding a second meeting to make sure folks in other TZ's had a chance to be heard. Let me know your thoughts, if there are folks out there that feel unable to attend due to TZ conflicts and we can see what we might be able to do. Thanks, John ___ 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 Hi Chaochin, Thanks for the feedback, I think the alternate time would have to be moved up an hour or two anyway (between the lunch hour in your TZ and the fact that it just moves the problem of being at midnight to the folks in US Eastern TZ). Also, I think if there is interest that a better solution might be to implement something like the Ceilometer team does and alternate the time each week. John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Qin Zhao ___ 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] [cinder][qa] release notes for cinder v1 to v2?
So the grizzly API releases notes are dead on. (I put them together and have worked with both API's ;) ) Unfortunately, a lot of the features in v2 got back ported to v1. The main differences are in the upgrade notes. -Mike Perez On Mon, Dec 16, 2013 at 9:57 PM, Zhi Kun Liu liuzhi...@gmail.com wrote: It seems that there's no document about the change from v1 to v2. Maybe the change is very small. Only found some info in OpenStack release notes. Cinder API v2 - List volumes/snapshots summary actually is a summary view. In v1 it was the same as detail view. - List volumes/snapshots detail and summary has display_name key changed to name. - List volumes/snapshots detail and summary has display_description key changed to description. https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly#OpenStack_Block_Storage_.28Cinder.29 https://wiki.openstack.org/wiki/ReleaseNotes/Havana#OpenStack_Block_Storage_.28Cinder.29 2013/12/17 David Kranz dkr...@redhat.com Sorry for lost subject in last message. Is there a document that describes the api changes from v1 to v2, similar to the one documenting nova v2 to v3? -David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards, Zhi Kun Liu ___ 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] Incubation Request for Barbican
On Tue, Dec 17, 2013 at 11:44 AM, Jarret Raim jarret.r...@rackspace.comwrote: On 12/13/13, 4:50 AM, Thierry Carrez thie...@openstack.org wrote: If you remove Jenkins and attach Paul Kehrer, jqxin2006 (Michael Xin), Arash Ghoreyshi, Chad Lung and Steven Gonzales to Rackspace, then the picture is: 67% of commits come from a single person (John Wood) 96% of commits come from a single company (Rackspace) I think that's a bit brittle: if John Wood or Rackspace were to decide to place their bets elsewhere, the project would probably die instantly. I would feel more comfortable if a single individual didn't author more than 50% of the changes, and a single company didn't sponsor more than 80% of the changes. I think these numbers somewhat miss the point. It is true that Rackspace is the primary sponsor of Barbican and that John Wood is the developer that has been on the project the longest. However, % of commits is not the only measure of contributions to the project. That number doesn¹t include the work on our chef-automation scripts or design work to figure out the HSM interfaces or work on the testing suite or writing our documentation or the million other tasks for the project. Rackspace is committed to this project. If John Wood leaves, we¹ll hire additional developers to replace him. There is no risk of the project lacking resources because a single person decides to work on something else. We¹ve seen other folks from HP, RedHat, Nebula, etc. say that they are interested in contributing and we are getting outside contributions today. That will only continue, but I think the risk of the project somehow collapsing is being overstated. There are problems that aren¹t necessarily the sexiest things to work on, but need to be done. It may be hard to get a large number of people interested in such a project in a short period of time. I think it would be a mistake to reject projects that solve important problems just because the team is a bit one sided at the time. Besides it being considered brittle because there is one major code contributor, I would be worried about the project being one-sided to solving the use cases that work for one company, but may not work for the use cases of other companies if they have not chimed in yet. Do you feel this is not the case? Can anyone from somewhere other than Rackspace speak up and say they have been involved with the design/discussions of Barbican? -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
On Tue, Dec 17, 2013 at 1:59 PM, Mike Perez thin...@gmail.com wrote: On Tue, Dec 17, 2013 at 11:44 AM, Jarret Raim jarret.r...@rackspace.comwrote: On 12/13/13, 4:50 AM, Thierry Carrez thie...@openstack.org wrote: If you remove Jenkins and attach Paul Kehrer, jqxin2006 (Michael Xin), Arash Ghoreyshi, Chad Lung and Steven Gonzales to Rackspace, then the picture is: 67% of commits come from a single person (John Wood) 96% of commits come from a single company (Rackspace) I think that's a bit brittle: if John Wood or Rackspace were to decide to place their bets elsewhere, the project would probably die instantly. I would feel more comfortable if a single individual didn't author more than 50% of the changes, and a single company didn't sponsor more than 80% of the changes. I think these numbers somewhat miss the point. It is true that Rackspace is the primary sponsor of Barbican and that John Wood is the developer that has been on the project the longest. However, % of commits is not the only measure of contributions to the project. That number doesn¹t include the work on our chef-automation scripts or design work to figure out the HSM interfaces or work on the testing suite or writing our documentation or the million other tasks for the project. Rackspace is committed to this project. If John Wood leaves, we¹ll hire additional developers to replace him. There is no risk of the project lacking resources because a single person decides to work on something else. We¹ve seen other folks from HP, RedHat, Nebula, etc. say that they are interested in contributing and we are getting outside contributions today. That will only continue, but I think the risk of the project somehow collapsing is being overstated. There are problems that aren¹t necessarily the sexiest things to work on, but need to be done. It may be hard to get a large number of people interested in such a project in a short period of time. I think it would be a mistake to reject projects that solve important problems just because the team is a bit one sided at the time. Besides it being considered brittle because there is one major code contributor, I would be worried about the project being one-sided to solving the use cases that work for one company, but may not work for the use cases of other companies if they have not chimed in yet. Do you feel this is not the case? Can anyone from somewhere other than Rackspace speak up and say they have been involved with the design/discussions of Barbican? -Mike Perez I reviewed the TC meeting notes, and my question still stands. It seems the committee is touching on the point of there being a worry because if it's a single company running the show, they can pull resources away and the project collapses. My worry is just having one company attempting to design solutions to use cases that work for them, will later not work for those potential companies that would provide contributors. -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Diversity as a requirement for incubation
On Wed, Dec 18, 2013 at 2:40 AM, Thierry Carrez thie...@openstack.orgwrote: I guess there are 3 options: 1. Require diversity for incubation, but find ways to bless or recommend projects pre-incubation so that this diversity can actually be achieved 2. Do not require diversity for incubation, but require it for graduation, and remove projects from incubation if they fail to attract a diverse community 3. Do not require diversity at incubation time, but at least judge the interest of other companies: are they signed up to join in the future ? Be ready to drop the project from incubation if that was a fake support and the project fails to attract a diverse community Personally I'm leaning towards (3) at the moment. Thoughts ? 3 gets my vote. As I've voiced over and over on the Barbican incubation thread, diversity is going to help the project gain contributors. You'll have a hard time gaining contributors if it's just one-sided designed solutions that only some companies can use. -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
On Thu, Dec 19, 2013 at 4:14 AM, Sean Dague s...@dague.net wrote: On 12/19/2013 12:10 AM, Mike Perez wrote: On Tue, Dec 17, 2013 at 1:59 PM, Mike Perez thin...@gmail.com mailto:thin...@gmail.com wrote: snip I reviewed the TC meeting notes, and my question still stands. It seems the committee is touching on the point of there being a worry because if it's a single company running the show, they can pull resources away and the project collapses. My worry is just having one company attempting to design solutions to use cases that work for them, will later not work for those potential companies that would provide contributors. -Mike Perez Which is our fundamental chicken and egg problem. The Barbican team has said they've reached out to other parties, who have expressed interest in joining, but no one else has. The Heat experience shows that a lot of the time companies won't kick in resources until there is some kind of stamp of general approval. If you showed up early, with a commitment to work openly, the fact that the project maps to your own use cases really well isn't a bug, it's a feature. I don't want to hold up a team from incubating because other people stayed on the sidelines. That was actually exactly what was going on with Heat, where lots of entities thought they would keep that side of the equation proprietary, or outside of OpenStack. By bringing Heat in, we changed the equation, I think massively for the better. -Sean To make my message more clear, I would like to see the TC thinking of this problem as well. In Cinder for example, there was a push for a shared service. One of the problems that the core saw in this feature was it was a one-sided project because only one vendor was really contributing. The API they provided may work great for them, but may not work for other potential contributors that come from another company where their storage system works differently. I see this as causing potential serious rewrites that really just sets a project back. I'm not at all saying this stops incubation, but just something else to consider besides a company pulling out the main resource from a project. -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Cinder Stability Hack-a-thon
Folks, I would love to get people together who are interested in Cinder stability to really dedicate a few days. This is not for additional features, but rather finishing what we already have and really getting those in a good shape before the end of the release. When: Feb 24-26 Where: San Francisco (DreamHost Office can host), Colorado, remote? Some ideas that come to mind: - Cleanup/complete volume retype - Cleanup/complete volume migration [1][2] - Other ideas that come from this thread. I can't stress the dedicated part enough. I think if we have some folks from core and anyone interested in contributing and staying focus, we can really get a lot done in a few days with small set of doable stability goals to stay focused on. If there is enough interest, being together in the mentioned locations would be great, otherwise remote would be fine as long as people can stay focused and communicate through suggested ideas like team speak or google hangout. What do you guys think? Location? Other stability concerns to add to the list? [1] - https://bugs.launchpad.net/cinder/+bug/1255622 [2] - https://bugs.launchpad.net/cinder/+bug/1246200 -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cinder Stability Hack-a-thon
On Sat, Feb 1, 2014 at 3:06 AM, Mike Perez thin...@gmail.com wrote: Folks, I would love to get people together who are interested in Cinder stability to really dedicate a few days. This is not for additional features, but rather finishing what we already have and really getting those in a good shape before the end of the release. Hey everyone! I'm really glad to see interest on this. There was even more of a response for this during the last Cinder IRC meeting! I have started an ether pad [1] with more information. Remote seems like the best option with such short notice. In the future we'll plan this earlier to make it easier for people to come and meet together if possible. Google hangout has a limit of 10 people, but that might be fine with the participation. If someone has a better suggestion for video/voice chat (we don't really need video), that works with windows/linux/mac, suggest it on the ether pad. I'll post finally details and a reminder once we get closer to the date. Thanks all! [1] - https://etherpad.openstack.org/p/cinder-hack-201402 -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] [Cinder] Cinder driver verification
On Thu, Feb 13, 2014 at 9:30 AM, Dean Troyer dtro...@gmail.com wrote: Are any of these drivers new for Icehouse? I think adding broken drivers in Icehouse is a mistake. The timing WRT Icehouse release schedule is unfortunate but so is shipping immature drivers that have to be supported and possibly deprecated. Should new drivers that are lacking have some not-quite-supported status to allow them to be removed in Juno if not brought up to par? Or moved into cinder/contrib? I don't mean to be picking on Cinder here, this seems to be recurring theme in OpenStack. I think we benefit from strengthening the precedent that makes it harder to get things in that are not ready even if the timing is inconvenient. We're seeing this in project incubation and I think we all benefit in the end. dt Since the cert tests were introduced, new drivers have been required to pass in order to be merged. -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cinder Stability Hack-a-thon
On Fri, Feb 7, 2014 at 6:51 PM, Mike Perez thin...@gmail.com wrote: Google hangout has a limit of 10 people, but that might be fine with the participation. If someone has a better suggestion for video/voice chat (we don't really need video), that works with windows/linux/mac, suggest it on the ether pad. I'll post finally details and a reminder once we get closer to the date. Thanks all! Hey everyone! Today is the day! I also learned making a google hangout public is a *scary* thing on the internet. Instead you can private message me thingee on #openstack-cinder your google plus profile link and I'll add you to the circle to join. If I don't respond, ask the channel if someone is already in that can invite you. In the future I'll get everyone who is interested added to the circle ahead of time to make things easier. Hack on! -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Pecan Evaluation for Marconi
On 03/19/2014 08:20 AM, Doug Hellmann wrote: As I understand it, all of the integrated projects have looked at Pecan, and are anticipating the transition. Most have no reason to create a new API version, and therefore build a new API service to avoid introducing incompatibilities by rebuilding the existing API with a new tool. This aligns with the plan when Pecan was proposed as a standard. Doug I have evaluated it for Cinder and have spoke to numerous interested folks in Cinder about using Pecan. It's currently what we're planning to move to after I did a rough prototype for some of our core API controllers. As you mentioned, we have no reason to do a version bump yet. We'll likely do a bump to be py3 compatible rather than for a significant change. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] [Cinder FFE] Request for HDS FFE
On 21:29 Mon 24 Mar , Tom Goulding wrote: I'd like to request an FFE for Cinder drivers for Hitachi HNAS storage. We showed this driver running in the demo theater at the Hong Kong summit and we've had end-users using it since January. The driver was initially submitted on Feb 18, 2014 some 45 days ago with regular work since then to address all review comments (a total of 8 revisions). The only real functional change that has occurred since Hong Kong was making CHAP protocol support optional. (The blueprint for this driver was submitted back on Aug. 29, 2013.) We've been working through the new Cinder requirements for certification testing which slowed things down as has obtaining a stable devstack environment. Early documentation on the new certification tests was not clear and has since been improved. We are convinced that the driver poses no risk to the stability and quality of the Icehouse release, so given that it's in the community's best interest to encourage a broad ecosystem of device support, and that we've been working in good faith to get this driver through the process, please help us get this into Icehouse. Hi Tom, Thanks for submitting your driver. Unfortunately I would have to give a -1 for an exception to be made for a new driver this late in the release. I'm sorry that there were problems with getting the cert tests working. However, on March 13th [1], your cert test did reveal that it was not passing for ISCSI and NFS [2][3], which would've gone out with the release. I think you would agree it's far more important to make sure things actually work than making a release. There were other issues with the unit tests not using mock and other standards that Cinder reviewers hold to every review, that this late in the release just didn't make the time frame doable. Regardless of risk to Cinder core, this is a time that contributors should be spending on getting targeted core issues stable and focusing review time on those issues. I would encourage you to propose a review for the Juno release. [1] - https://review.openstack.org/#/c/74371/ [2] - https://gist.github.com/sombrafam/9493308 [3] - https://gist.github.com/sombrafam/9416255 -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] the ability about list the available volume back-ends and their capabilities
On 06:11 Thu 03 Apr , Zhangleiqiang (Trump) wrote: Hi stackers: I think the ability about list the available volume back-ends, along with their capabilities, total capacity, available capacity is useful for admin. For example, this can help admin to select a destination for volume migration. But I can't find the cinder api about this ability. I find a BP about this ability: https://blueprints.launchpad.net/cinder/+spec/list-backends-and-capabilities But the BP is not approved. Who can tell me the reason? Hi Zhangleiqiang, I think it's not approved because it has not been set to a series goal by the drafter. I don't have permission myself to change the series goal, but I would recommend going into the #openstack-cinder IRC channel and ask for the BP to be set for the Juno release assuming there is a good approach. We'd also need a contributor to take on this task. I think it would be good to use the os-hosts extension which can be found in cinder.api.contrib.hosts and add the additional response information there. It already lists total volume/snapshot count and capacity used [1]. [1] - http://paste.openstack.org/show/74996 -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder]a question about os-volume_upload_image
On 01:32 Fri 04 Apr , Bohai (ricky) wrote: -Original Message- From: Mike Perez [mailto:thin...@gmail.com] Sent: Friday, April 04, 2014 1:20 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Cinder]a question about os-volume_upload_image What use case is that exactly? I mentioned earlier the original purpose was for knowing if something was bootable. I'm curious on how else this is being used. An image has the property for example: hw_scsi_model=virtio-scsi or other user specify property. In process (1), cinder has saved the image property in the cinder DB. I hope in process(2), cinder could provide an option to save the properties back to the new glance image. Without this ability, user has to find all the properties in origin image and set them back by hand. This is useful when user just want to make a little modify to an origin image. An image --(1)-- cinder volume --(2)-- An new Image Hi Ricky, Thanks for further explaining that to me. It does make sense, but I'm wondering if there would be cases that people can think of where the properties specified could become outdated because of changes that happen to the volume. In glance the properties make sense because an image is uploaded and has properties set. The image is not going to be changed. If you want to change something about that image, you upload a new one with the specified properties. Rather with a volume, it's constantly having blocks changed. Is there potential for that? Could this problem be potential if a volume is migrated to a different backend? -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder]a question about os-volume_upload_image
On 22:55 Wed 02 Apr , Mike Perez wrote: On 02:58 Thu 03 Apr , Bohai (ricky) wrote: Hi, When I use an image to create a cinder volume, I found image's metadata is saved into DB table volume_glance_metadata. But when I use os-volume_upload_image to create image from cinder volume, the metadata in volume_glance_metadata is not setted back to the newly created image. I can't found the reason for this. Anyone can give me a hint? I am a newbie for cinder and i apologize if I am missing something very obvious. Best regards to you. Ricky Hi Ricky, The glance metadata is currently only stored for creating new volumes, new snapshots or backups. It's used for in the volume creation to know if the volume is bootable. -- Mike Perez Correction to myself, the glance metadata is no longer used for determining if a volume is bootable. https://github.com/openstack/cinder/commit/c8f814569d07544734f10f134e146ce981639e07 -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Propose Jay Bryant for core
On Tue, Oct 29, 2013 at 1:54 PM, John Griffith john.griff...@solidfire.comwrote: Hey, I wanted to propose Jay Bryant (AKA jsbryant, AKA jungleboy, AKA :) ) for core membership on the Cinder team. Jay has been working on Cinder for a while now and has really shown some dedication and provided much needed help with quality reviews. In addition to his review activity he's also been very active in IRC and in Cinder development as well. I think he'd be a good add to the core team. Thanks, John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev +1 -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder][Driver] Delete snapshot
On 10:20 Wed 18 Jun , Amit Das wrote: Implementation issues - If Cinder driver throws an Exception the snapshot will have error_deleting status will not be usable. If Cinder driver logs the error silently then Openstack will probably mark the snapshot as deleted. What is the appropriate procedure that needs to be followed for above usecase. I'm not sure what Openstack will probably mark the snapshot as deleted means. If a snapshot gets marked with error_deleting, we don't know what state the snapshot is in because it could've been a delete that partially finished. You should leave the cinder volume manager to handle this. It's up to the driver to say the delete finished or failed, that's it. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Virtio-scsi settings nova-specs exception
As requested from the #openstack-meeting for Nova, I'm posting my nova-spec exception proposal to the ML. Spec: https://review.openstack.org/#/c/103797/3/specs/juno/virtio-scsi-settings.rst Code: https://review.openstack.org/#/c/107650/ - Nikola Dipanov was kind to be the first core sponsor. [1] - This is an optional feature, which should make it a low risk for Nova. - The spec was posted before the spec freeze deadline. - Code change is reasonable and available now. Thank you! [1] - https://etherpad.openstack.org/p/nova-juno-spec-priorities -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder] gettextutils enable_lazy not working
Recent change to how we use gettextutils [1] seem to not import _ anymore. According to the commit, enable_lazy() is suppose to *replace* gettextutils.install(), but I can't see where in the code that happens or see it actually working. I have reported a bug [2] that cinder-manage and cinder-rtstool [3] no longer work as a result. Using gettextutils.install() seems to resolve the issue or explicitly import _. Can someone who is familiar with this module please enlighten me how this is suppose to work? [1] - https://review.openstack.org/#/c/105561/4 [2] - https://bugs.launchpad.net/cinder/+bug/1345789 [3] - https://bugs.launchpad.net/cinder/+bug/1345789/comments/4 -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Virtio-scsi settings nova-specs exception
On 10:21 Mon 21 Jul , Michael Still wrote: I just want to check my understanding -- it seems to me that this depends on a feature that's very new to libvirt (merged there 22 May 2014). Is that right? http://libvirt.org/git/?p=libvirt.git;a=commit;h=d950494129513558a303387e26a2bab057012c5e Yes, this was mentioned in the Nova spec itself. We've had some concerns about adding features to the libvirt driver for features represented only in very new versions of libvirt. https://review.openstack.org/#/c/72038/ is an example. Now, its clear to me that we don't yet have a consensus on nova-core on how to handle features depending on very new libvirts. There are certainly CI concerns at the least. So, I think approving this exception is tied up in that whole debate. Hopefully we can get that sorted out soon (and possibly unblock https://review.openstack.org/#/c/72038/ depending on the outcome). Michael For what it's worth, it's optional and the administrator would have to really go out of their way to enable this in two ways: * You have to be using a Cinder driver that uses the vhost connector to pass the connection data to Nova. * Glance metadata of an image has to have these options set. The review you provided with the debate raised by Dan Smith has been stale for 19 days with Daniel waiting for a reply. Should we have this listed for the next Nova meeting? -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][qa] cinder client versions and tempest
On 16:19 Thu 24 Jul , David Kranz wrote: I noticed that the cinder list-extensions url suffix is underneath the v1/v2 in the GET url but the returned result is the same either way. Some of the returned items have v1 in the namespace, and others v2. For XML, the namespace is different. JSON makes no different. Also, in tempest, there is a single config section for cinder and only a single extensions client even though we run cinder tests for v1 and v2 through separate volume clients. I would have expected that listing extensions would be separate calls for v1 and v2 and that the results might be different, implying that tempest conf should have a separate section (and service enabled) for volumes v2 rather than treating the presence of v1 and v2 as flags in volume-feature-enabled. Am I missing something here? The results of using extensions with v1 or v2 makes no different except what I noted above. With that in mind, I recommend testing the extensions once with v2 since it's the latest supported, and v1 is deprecated as of Juno. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] vhost-scsi support in Nova
On 11:08 Fri 25 Jul , Stefan Hajnoczi wrote: On Fri, Jul 25, 2014 at 10:47 AM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: As mentioned, we'd like the Nova folks to consider vhost-scsi support as a experimental feature for the Juno release of Openstack, given the known caveats. I think OpenStack support for vhost-scsi makes sense if someone wants to do the work. This was done in Nova [1], but we're waiting on the additional requirements to be met that Daniel requested for Libvirt to support it. We'll revisit this for the next release. Support for vHost in Cinder was worked on [1][2], but is paused until the requirements above are met. [1] - https://review.openstack.org/#/c/107650/ [2] - https://github.com/openstack/cinder-specs/blob/master/specs/juno/vhost-support.rst [3] - https://github.com/Thingee/cinder/commit/4da7c5aab817f021b3f39b7d56df7c7beace2ab8 -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cinder tempest api volume tests failed
On 11:30 Thu 31 Jul , Nikesh Kumar Mahalka wrote: I deployed a single node devstack on Ubuntu 14.04. This devstack belongs to Juno. When i am running tempest api volume test, i am getting some tests failed. Hi Nikesh, To further figure out what's wrong, take a look at the c-vol, c-api and c-sch tabs in the stack screen session. If you're unsure where to go from there after looking at the output, set the `SCREEN_LOGDIR` setting in your local.conf [1] and copy the logs from those tabs to paste.openstack.org for us to see. [1] - http://devstack.org/configuration.html -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] Cinder tempest api volume tests failed
On 14:46 Fri 01 Aug , Nikesh Kumar Mahalka wrote: Hi Mike,test which is failed for me is: *tempest.api.volume.admin.test_volume_types.VolumeTypesTest* I am getting error in below function call in above test *self.volumes_client.wait_for_volume_status**(volume['id'],* * 'available')**.* This function call is in below function: *@test.attr(type='smoke')* *def test_create_get_delete_volume_with_volume_type_and_extra_specs(self)* This is due to the extra spec test by default setting the vendor name capability to 'Open Source'. Since your driver probably has a different vendor name, the scheduler is not able to find a suitable host to fulfill the volume create request with that volume type. There is a wiki page [1] that covers how to test your driver in devstack with Tempest, which will avoid this problem. [1] - https://wiki.openstack.org/wiki/Cinder#Configuring_devstack_to_use_your_driver_and_backend -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder] create server from a volume snapshot, 180 reties is sufficient?
On 23:58 Tue 08 Apr , Lingxian Kong wrote: hi there: According to the patch https://review.openstack.org/#/c/80619/, Nova will wait for volume creation for 180s, the config option is rejected by Russell and Nikola. But the reason I raise it up is, we found the server creation failed due to timeout in our deployment, with LVM as Cinder backend. So, I wander is 180s really suitable here? Are there some guidences about when should we add an option? But at least, we should not avoid an option, just because of the existing overwhelming number of them, right? Thoughts? It looks like this was a temporary accepted solution and the long term solution is with event callbacks [1]. [1] - https://blueprints.launchpad.net/nova/+spec/admin-event-callback-api -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder] create server from a volume snapshot, 180 reties is sufficient?
On 09:54 Wed 09 Apr , Lingxian Kong wrote: yes, the bp also make sense to nova-cinder interaction, may I submmit a blueprint about that? Any comments? Sounds fine to me! -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder][Nova][Keystone][docs] Version responses links
On 19:19 Sun 27 Apr , Andreas Jaeger wrote: So, my proposal would be: * Remove WADL links * Have PDF links to go http://docs.openstack.org * For those current links to the site http://docs.openstack.org: Take care that they point either to a current file or get redirected to http://docs.openstack.org/index.html Andreas, Thanks for starting this. As I mentioned, I started this with Cinder [1], but I was linking directly to the API spec version with the corresponding version. I'm curious on what others think the approach should be here. [1] - https://review.openstack.org/#/c/73856/ -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] About store faults info for volumes
On 06:49 Wed 30 Apr , Zhangleiqiang (Trump) wrote: Hi stackers: I found when a instance status become error, I will see the detailed fault info at times when I show the detail of Instance. And it is very convenient for me to find the failed reason. Indeed, there is a nova.instance_faults which stores the fault info. Maybe it is helpful for users if Cinder also introduces the similar mechanism. Any advice? -- zhangleiqiang (Trump) Best Regards There are some discussions that started a couple of weeks ago about using sub states like Nova to know more clearly what happened when a volume is in an 'error' state. Unfortunately I'm not sure if that'll be in a formal session at the summit, but it'll definitely be discussed while we have the team together. Maybe John Griffith can comment since he's approving the sessions. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata
On 06:31 Wed 07 May , Trump.Zhang wrote: Thanks for your further instructions. I think the situations I mentioned are the reasonable use cases. They are similar to the bootable volume use cases, user can create an empty volume and install os in it from an image or create bootable volume from instance ([1]). If volume metadata is not intended to be interpreted by cinder or nova as meaning anything, maybe Cinder needs to add support for updating some of glance_image_metadata of volume or introduce new property for volume like bootable ? I don't think these two methods are good either. [1] https://blueprints.launchpad.net/cinder/+spec/add-bootable-option Volume already has a bootable field: https://github.com/openstack/cinder/blob/master/cinder/db/sqlalchemy/models.py#L122 -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder], [cinder-driver] Request for new cinder driver
On 11:50 Tue 13 May , Mardan Raghuwanshi wrote: Hello Team, We develop cinder driver and supporting minimum features, but our driver are not the part of openstack release. We also created blueprint for it. I would like to understand the process to push the cinder driver with the official release of openstack. What are the pre-requisites one needs to fulfill to be part of the openstack release? so I'm looking at a clear procedure required to be qualified to be a part of the openstack release? Please let me know. Thanks, Mardan Hi Mardan, Welcome to the community! Cinder has a doc on minimum features [1] that are required to be in the Cinder tree. These are features that are available from the VolumeDriver class in cinder.volume.driver that should be implemented by your driver class. There are docs on submitting code to gerrit [2], how to form your commit messages [3] It has just been discussed at the design summit this week that we will be requiring new drivers to provide a CI hooked up to their real backend solution to run once a day to provide results of working on the current state of tree. [4]. We should have polished up documentation sometime next week, and will reply to this thread once that's done. For now, you can read about how the OpenStack CI works and how you would setup your own external system. [5][6][7] [1] - http://docs.openstack.org/developer/cinder/devref/drivers.html [2] - https://wiki.openstack.org/wiki/Gerrit_Workflow [3] - https://wiki.openstack.org/wiki/GitCommitMessages [4] - https://etherpad.openstack.org/p/juno-cinder-3rd-party-cert-and-verification [5] - http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/ [6] - http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/ [7] - http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/ -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Question about response code of API
On 00:08 Wed 14 May , Trump.Zhang wrote: Hi, all: I find a lot of methods in cinder.api.contrib.* return 202 code instead of 200, even when these methods only involve database operation, which are not async process. For example, cinder.api.contrib.types_extra_specs.\ VolumeTypeExtraSpecsController:delete, cinder.api.contrib.volume_actions.\ VolumeActionsController:_reserve, etc. From the HTTP/1.1 Status Code Definitions [1], 202 means Accepted, i.e. the request has been accepted for processing, but the processing has not been completed. Are these response codes are returned by mistake? If it's just a db operation, that sounds like a mistake. Unfortunately, we have not spent time on dealing with versioned extensions to easily deal with this. https://wiki.openstack.org/wiki/APIChangeGuidelines -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] about policy.json in unit test
On 02:04 Tue 29 Apr , Bohai (ricky) wrote: Hi stackers, I found there are two policy.json files in cinder project. One is for source code(cinder/etc/policy.json), another is for the unit test(cinder/cinder/tests/policy.json). Maybe it's better to united them and make the unit test to use the policy.json file in the source code: 1. policy.json in the source code is really what we want to test but not the one in unit test. 2. It's more convenient for the developers, because of only need to modify one policy.json file. Current it's easy to miss one of them. Any advices? Seems like the right direction. Don't know why they were separate to begin with. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata
On 03:08 Thu 08 May , Zhangleiqiang (Trump) wrote: Thanks for the summary and detailed explanation. 1. Volume metadata - this is for the tenant's own use. Cinder and nova don't assign meaning to it, other than treating it as stuff the tenant can set. It is entirely unrelated to glance_metadata Does it means that the volume_metadata is something like tagging for volume? Users can use it to do the filtering or grouping work. I don't know what the actual usage users are doing with volume metadata, but it would be possible to filter by it when listing volumes. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Question about storage backend capacity expansion
On 07:14 Wed 14 May , Zhangleiqiang (Trump) wrote: Hi, all: I meet a requirement in my OpenStack environment which initially uses one LVMISCSI backend. Along with the usage, the storage is insufficient, so I want to add a NFS backend to the exists Cinder. There is only a single Cinder-volume in environment, so I need to configure the Cinder to use multi-backend, which means the initial LVMISCSI storage and the new added NFS storage are both used as the backend. However, the existing volume on initial LVMISCSI backend will not be handled normally after using multi-backend, because the host of the exists volume will be thought down. I know that the migrate and retype APIs aim to handle the backend capacity expansion, however, each of them can't used for this situation. I think the use case above is common in production environment. Is there some existing method can achieve it ? Currently, I manually updated the host value of the existing volumes in database, and the existing volumes can then be handled normally. Thanks. This is exactly what migrate is suppose to help with. Unfortunately as you mentioned, it's not available in the LVM or NFS driver. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Qcow2 support for cinder-backup
On 12:45 Mon 12 May , Zhangleiqiang (Trump) wrote: Hi, all: I have planned to add the support to create qcow2 format file in NFS driver ([1]). From the comment of Eric Harney, I know that cinder-backup service currently assumes the volume is raw-formatted, and enable creating qcow2 in NFS driver will break backups of NFS volumes . After reading the code of backup service, I find we can first mount the qcow2 volume as a NBD device and then pass the NBD device as the source volume_file to backup service. Similar method of mounting qcow2 as NBD device has already used in Nova now. I think we can add it to NFS driver for backup, and it can be used for GlusterFS too. Any advice? Is there something I have not expected? This approach makes sense to me. Thanks for looking into this. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] How to mock the LOG inside cinder driver
On 21:46 Tue 03 Jun , Deepak Shetty wrote: deepakcs Hi, whats the right way to mock the LOG variable inside the driver ? I am mocking mock.patch.object(glusterfs, 'LOG') as mock_logger Please provide a paste[1] of the patch. [1] - http://paste.openstack.org -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Support the Ada Initiative: A Challenge to the OpenStack Communtiy
Some of you may already be aware of Sage Weil’s challenge to the open source storage community to raise the level of female participation in open source by contributing to the Ada Initiative [1]. I would also like to share about the Ada Initiative, and how they are helping open source communities like OpenStack. I’m also going to increase Sage’s original matching to $10,000 and extend a personal challenge [2] to the OpenStack community. If you already know about the Ada Initiative, you can donate now: https://supportada.org?campaign=openstack The current status of the campaign can be found here: https://adainitiative.org/counters/2014counter-openstack.svg The Ada Initiative has helped over two million women get and stay involved with open source communities. The organization helps communities understand a culture that needs to exist in order to successfully achieve diversity. While women make up about 30% of the software developer community, they only account for less than 10% of the open source community. On a personal level this is something that I have been actively committed to doing and I have had the wonderful opportunity to volunteer as a mentor at a couple of groups that are bringing diversity to the tech community. The PyLadies San Francisco group is providing exciting workshops [3] that will give a foundation to women to expand on. The Women Who Code group is preparing women for internship opportunities through the Gnome Outreach Program for Women in open source projects like OpenStack [4]. It's these experiences that led me to explore how the OpenStack community promotes diversity. Today the OpenStack community has been including a Code of Conduct [5] in an attempt to provide a safe, no harassment environment at our summits. We have events [6] that bring women together to talk about their achievements, to get others excited on what can be contributed to the community. Our participation in the Gnome Outreach Program for Women continues to grow with mentors eager to bring out the talent of our selected interns [7]. Things are getting better but we have a long way to go. The Atlanta design summit had attendance of 9% women, up from 7% at the previous Hong Kong summit. But this number is still unacceptable, and as others have echoed in the community, we must work to make it better. This is a change I want the OpenStack community to be part of. I would like to kick start things with the community with a challenge for us to raise $10,000 before Wednesday, Oct 8th, to which Sage and I will match that dollar for dollar! https://supportada.org?campaign=openstack Thanks, Mike Perez [1] - http://ceph.com/community/support-ada-initiative-challenge-open-storage-community [2] - https://www.dreamhost.com/dreamscape/2014/10/06/support-the-ada-initiative-a-challenge-to-the-openstack-community/ [3] - http://www.meetup.com/PyLadiesSF/events/201387112/ [4] - http://www.meetup.com/Women-Who-Code-SF/events/195850392/ [5] - https://www.openstack.org/summit/openstack-paris-summit-2014/code-of-conduct/ [6] - https://www.youtube.com/watch?v=jkzyNbvl_5g [7] - https://wiki.openstack.org/wiki/OutreachProgramForWomen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Support the Ada Initiative: A Challenge to the OpenStack Communtiy
You're all awesome, as the goal has already been met! The matching challenge has just been raised to $16,384! https://supportada.org?campaign=openstack Status: https://adainitiative.org/counters/2014counter-openstack.svg -- Mike Perez On Oct 6, 2014, at 11:33, Mike Perez thin...@gmail.com wrote: Some of you may already be aware of Sage Weil’s challenge to the open source storage community to raise the level of female participation in open source by contributing to the Ada Initiative [1]. I would also like to share about the Ada Initiative, and how they are helping open source communities like OpenStack. I’m also going to increase Sage’s original matching to $10,000 and extend a personal challenge [2] to the OpenStack community. If you already know about the Ada Initiative, you can donate now: https://supportada.org?campaign=openstack The current status of the campaign can be found here: https://adainitiative.org/counters/2014counter-openstack.svg The Ada Initiative has helped over two million women get and stay involved with open source communities. The organization helps communities understand a culture that needs to exist in order to successfully achieve diversity. While women make up about 30% of the software developer community, they only account for less than 10% of the open source community. On a personal level this is something that I have been actively committed to doing and I have had the wonderful opportunity to volunteer as a mentor at a couple of groups that are bringing diversity to the tech community. The PyLadies San Francisco group is providing exciting workshops [3] that will give a foundation to women to expand on. The Women Who Code group is preparing women for internship opportunities through the Gnome Outreach Program for Women in open source projects like OpenStack [4]. It's these experiences that led me to explore how the OpenStack community promotes diversity. Today the OpenStack community has been including a Code of Conduct [5] in an attempt to provide a safe, no harassment environment at our summits. We have events [6] that bring women together to talk about their achievements, to get others excited on what can be contributed to the community. Our participation in the Gnome Outreach Program for Women continues to grow with mentors eager to bring out the talent of our selected interns [7]. Things are getting better but we have a long way to go. The Atlanta design summit had attendance of 9% women, up from 7% at the previous Hong Kong summit. But this number is still unacceptable, and as others have echoed in the community, we must work to make it better. This is a change I want the OpenStack community to be part of. I would like to kick start things with the community with a challenge for us to raise $10,000 before Wednesday, Oct 8th, to which Sage and I will match that dollar for dollar! https://supportada.org?campaign=openstack Thanks, Mike Perez [1] - http://ceph.com/community/support-ada-initiative-challenge-open-storage-community [2] - https://www.dreamhost.com/dreamscape/2014/10/06/support-the-ada-initiative-a-challenge-to-the-openstack-community/ [3] - http://www.meetup.com/PyLadiesSF/events/201387112/ [4] - http://www.meetup.com/Women-Who-Code-SF/events/195850392/ [5] - https://www.openstack.org/summit/openstack-paris-summit-2014/code-of-conduct/ [6] - https://www.youtube.com/watch?v=jkzyNbvl_5g [7] - https://wiki.openstack.org/wiki/OutreachProgramForWomen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Any plan on cinder for kilo?
On 08:09 Tue 14 Oct , yoo bright wrote: Hi, I noticed nova has already opened blueprint and specs for kilo, so I was wondering what is the plan on cinder for kilo? If I want to contribute some code(add new feature) for cinder, whether the step is the same with nova (need write specs first)? Thanks! Yoo The specs/kilo directory should now be available to propose specs to. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder] Kilo Summit Topic Proposals
We will be discussing proposals [1] at the next Cinder meeting [2] October 22nd at 16:00 UTC: You may add proposals to the etherpad at this time. If you have something proposed, please be present at the meeting to answer any questions about your proposal. -- Mike Perez [1] - https://etherpad.openstack.org/p/kilo-cinder-summit-topics [2] - https://wiki.openstack.org/wiki/CinderMeetings ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance][Cinder] The sorry state of cinder's driver in Glance
On 09:11 Thu 23 Oct , Flavio Percoco wrote: According to the use-cases explained in this thread (also in the emails from John and Mathieu) this is something that'd be good having. I'm looking forward to seeing the driver completed. As John mentioned in his email, we should probably sync again in K-1 to see if there's been some progress on the bricks side and the other things this driver depends on. If there hasn't, we should probably get rid of it and add it back once it can actually be full-featured. I'm unsure if Brick [1] will be completed in time. With that in mind, even if we were to deprecate the glance driver for Kilo, Brick will likely be done by then and we would just be removing the deprecation in L, assuming the driver is completed in L. I think that would be confusing to users. It's unfortunate this was merged in the current state, but I would just say leave things as is with intentions at the latest to have the driver completed in L. If we're afraid no one is going to complete the driver, deprecate it now. [1] - https://github.com/hemna/cinder-brick -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Cinder plans for kilo: attention new driver authors!
On 19:41 Thu 04 Sep , Duncan Thomas wrote: Hi during this week's cinder weekly meeting [1], we discussed plans for Kilo, a discussion that started at the mid-cycle meetup [2]. The outcome is that we (the cinder core team and extended community) want to focus on stability and code clean-up in the Kilo release, and paying off some of the technical debt we've built up over the past couple of years [3]. In order to facilitate this, for the Kilo cycle: 1. New drivers must be submitted before K1 in order to be considered. Any driver submitted after this date will be deferred until the L cycle. We encourage submitters to get in early, even if you make K1 there is no guarantee of getting enough reviewer attention to get merged. 2. New features are limited and ideally merged by K2. 3. K3 is dedicated to stability and bug fixing. (Much of this work will happen before K3, but K3 is dedicated to testing and reviewing of it, in preference to anything else. Any driver enhancements required to support pre-existing features will also be considered, but please get them in as early as possible). 4. PoC required before the summit, for any summit session related to new features. 5. There will be a continuing drive for 3rd party CI of every driver in cinder during the Kilo cycle. I'll repost these guidelines and any follow-up clarifications shortly before the summit. Comments / feedback welcome. [1] http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-03-16.01.log.html [2] https://etherpad.openstack.org/p/cinder-meetup-summer-2014 [3] https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work Just reiterating points here. From the September 23rd Cinder meeting [1], and verified in the Oct 29th Cinder meeting [2], the community has agreed that new drivers must be submitted *before* K-1 ends. K-1 is expected to end on 12/18, according to the launchpad page [3]. Submitted and qualified for merge means: * Your blueprint for your driver was submitted and approved before 11/15. * Your driver code is posted to gerrit. * Your driver passes the cert test and the results are posted. [4] * Your driver fulfills minimum features. [5] * You have spoken to Duncan (DuncanT- on #openstack-cinder) about your third party ci. [6] To be clear: * Your driver submission must meet *all* the items before the end of k-1. * If your driver is submitted *LATE* in k-1, and meets *all* the items above, but isn't merged, it will be still be considered for merge in k-2 or k-3. However, expect low priority in reviews and not guaranteed for merge in Kilo. * If your driver is submitted after k-1, expect me to reference this email and will request the driver to be submitted in the L release. * This does not include backup drivers. And yes, the Cinder wiki will be updated with this information. [1] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-03-16.01.log.html [2] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-29-16.00.log.html [3] - https://launchpad.net/cinder/+milestone/kilo-1 [4] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers [5] - http://docs.openstack.org/developer/cinder/devref/drivers.html#minimum-features [6] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Testing_requirements_for_Kilo_release_and_beyond -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] add a common cache mechanism for block device storage
On 08:57 Wed 29 Oct , yoo bright wrote: Dear all, We proposed a new blueprint (at https://review.openstack.org/128814) for adding a common cache mechanism for block device storage. All requirements, suggestions and comments are welcome. Thank you! Thanks for submitting this Yoo. This is already posted in the review, but I think we would want to see a way for alternatives to be plugged in. I also think if you want this working on the compute nodes, you'll need to work with the Nova folks as well. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Adding support for iSCSI helper
On 01:35 Wed 05 Nov , Anish Bhatt wrote: This is very helpful, thank you ! Is this planned for kilo ? Yes. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder] Anyone Using the Open Solaris ZFS Driver?
The Open Solaris ZFS driver [1] is currently missing a lot of the minimum features [2] that the Cinder team requires with all drivers. As a result, it's really broken. I wanted to gauge who is using it, and if anyone was interested in fixing the driver. If there is not any activity with this driver, I would like to propose it to be deprecated for removal. [1] - https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/san/solaris.py [2] - http://docs.openstack.org/developer/cinder/devref/drivers.html#minimum-features -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Anyone Using the Open Solaris ZFS Driver?
On 07:27 Tue 18 Nov , Duncan Thomas wrote: Is the new driver drop-in compatible with the old one? IF not, can existing systems be upgraded to the new driver via some manual steps, or is it basically a completely new driver with similar functionality? On 17 November 2014 07:08, Drew Fisher drew.fis...@oracle.com wrote: We (here at Oracle) have a replacement for this driver which includes local ZFS, iSCSI and FC drivers all with ZFS as the underlying driver. We're in the process of getting CI set up so we can contribute the driver upstream along with our ZFSSA driver (which is already in the tree). If anybody has more questions about this, please let me know. The driver is in the open for folks to look at and if anybody wants us to start upstream integration for it, we'll be happy to do so. -Drew On 11/16/14, 8:45 PM, Mike Perez wrote: The Open Solaris ZFS driver [1] is currently missing a lot of the minimum features [2] that the Cinder team requires with all drivers. As a result, it's really broken. I wanted to gauge who is using it, and if anyone was interested in fixing the driver. If there is not any activity with this driver, I would like to propose it to be deprecated for removal. [1] - https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/san/solaris.py [2] - http://docs.openstack.org/developer/cinder/devref/drivers.html#minimum-features ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas Drew can you answer Duncan's question? I would like to get a head start on deprecating the driver, or expect your replacement this release to be compatible with the existing one. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Anyone Using the Open Solaris ZFS Driver?
On 14:37 Tue 25 Nov , Drew Fisher wrote: On 11/25/14, 12:56 PM, Jay S. Bryant wrote: Monty, I agree that upgrade is not a significant concern right now if the existing driver is not working. Drew, I am having trouble following where you guys are currently at with this work. I would like to help get you guys up and going during Kilo. I am concerned that maybe there is confusion about the blueprints/patches that we are all talking about here. I see this Blueprint that was accepted for Juno and appears to have an associated patch merged: [1] I also see this Blueprint that doesn't appear to be started yet: [2] So, can you help me understand what it is you are hoping to get in for Kilo? OK, so we have two drivers here at Oracle in Solaris. 1: A driver for the ZFS storage appliance (zfssa). That driver was integrated into the Icehouse branch and still there in Juno. That team, separate from mine, is working along side of us with the CI requirements to keep the driver in Kilo 2: The second driver is one for generic ZFS on Solaris. We have three different sub-drivers in one: - An iSCSI driver (COMSTAR on top of ZFS) - A FC driver (on top of ZFS) - A simple local ZFS driver useful for single-system / devstack / demo rigs. The local driver simply creates ZVOLs for Zones to use on the local system. It's not designed with any kind of migration abilities unlike iSCSI or FC. I know that you have been concerned about CI. For new drivers we are allowing some grace period to get things working. Once we get the confusion over blueprints worked out and have some code to start reviewing we can continue to discuss that issue. My plan is to discuss this plan with my team next week after the holiday. Once we get something in place on our side, we'll try to get a blueprint submitted ASAP for review. Sound good? Hi Drew, We're not accepting anymore drivers for the Kilo release. This was from a discussion that started back in September and mentioned on the mailing list a couple of times [1][2], multiple Cinder meetings [3][4], and the last design summit. The one driver we have from Oracle is a ZFS NFS [5] driver that was registered before the deadline. If you could verify with your team if they plan to fix the existing Solaris ISCSI driver [5], or can we remove it? [1] - http://lists.openstack.org/pipermail/openstack-dev/2014-September/044990.html [2] - http://lists.openstack.org/pipermail/openstack-dev/2014-October/049512.html [3] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-03-16.01.log.html [4] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-29-16.00.log.html [5] - https://blueprints.launchpad.net/cinder/+spec/oracle-zfssa-nfs-cinder-driver [5] - https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/san/solaris.py -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cinder Driver Base Requirements
Absolutely. I have some changes I need to make to the docs anyways for the drivers, so I created a bp. https://blueprints.launchpad.net/openstack-manuals/+spec/cinder-driver-base-features -Mike Perez! On Fri, Jul 19, 2013 at 10:54 AM, Anne Gentle annegen...@justwriteclick.com wrote: Great idea, Mike. Should we have a section that describes the minimum docs for a driver? On Thu, Jul 18, 2013 at 12:20 AM, thingee thin...@gmail.com wrote: To avoid having a grid of what features are available by which drivers and which releases, the Cinder team has met and agreed on 2013-04-24 that we would request all current and new drivers to fulfill a list of minimum requirement features [1] in order to be included in new releases. There have been emails sent to the maintainers of drivers that are missing features in the minimum feature requirement list. If there are questions, maintainers can reply back to my email and as always reach out to the team on #openstack-cinder. Thanks, Mike Perez [1] - https://wiki.openstack.org/wiki/Cinder#Minimum_Driver_Features ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Anne Gentle annegen...@justwriteclick.com ___ 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] Is WSME really suitable? (Was: [nova] Autogenerating the Nova v3 API specification)
On Mon, Aug 5, 2013 at 11:03 AM, Mac Innes, Kiall ki...@hp.com wrote: While the topic of WSME is open - Has anyone actually tried using it? snip I would be very cautious about assuming WSME can support anything we need when the absolute fundamentals of building a REST API are totally MIA. There was a whole thread about this a couple of months ago [1]. tl;dr Ceilometer is already using it. I have a rough patch for what would be v3 of Cinder using Pecan/WSME for J if we decide we need a bump [2]. Neutron will likely be using it when it switches to Pecan. For Cinder, WSME raises a 400 on type checking in the body as I need it to. Everything else I have raised in the controller as needed. Thanks, Mike Perez [1] - http://lists.openstack.org/pipermail/openstack-dev/2013-June/009824.html [2] - http://lists.openstack.org/pipermail/openstack-dev/2013-June/010857.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.db] Proposal: Get rid of deleted column
On Tue, Aug 20, 2013 at 1:59 PM, Jay Pipes jaypi...@gmail.com wrote: We should take a look at look at the various entities in the various database schemata and ask the following questions: 1) Do we care about archival of the entity? 2) Do we care about audit history of changes to the entity? For #1 and #2, really this sounds like another thing doing this along with Ceilometer. I would really like to leave this in Ceilometer and not have each project get more complex in having to keep track of this on their own. I start having fears of discrepancy bugs of what projects' audit say and what Ceilometer audit says. Have Ceilometer do audits, keep temporary logs for specified time, and leave it up to the ops user to collect and archive the information that's important to them. To answer your original question, I say just get rid of the column and do a hard delete. We didn't have Ceilometer then, so we no longer need to keep track in each project. Migration path of course should be thought of for the users that need this information archived if we decide to get rid of the columns. -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.db] Proposal: Get rid of deleted column
On Tue, Aug 20, 2013 at 2:52 PM, Vishvananda Ishaya vishvana...@gmail.comwrote: On Aug 20, 2013, at 2:44 PM, Mike Perez thin...@gmail.com wrote: For #1 and #2, really this sounds like another thing doing this along with Ceilometer. I would really like to leave this in Ceilometer and not have each project get more complex in having to keep track of this on their own. I start having fears of discrepancy bugs of what projects' audit say and what Ceilometer audit says. Have Ceilometer do audits, keep temporary logs for specified time, and leave it up to the ops user to collect and archive the information that's important to them. To answer your original question, I say just get rid of the column and do a hard delete. We didn't have Ceilometer then, so we no longer need to keep track in each project. Migration path of course should be thought of for the users that need this information archived if we decide to get rid of the columns. This was actually discussed during the summit session. The plan at that time was: a) bring back unique constraints by improving soft delete b) switch to archiving via shadow tables c) remove archiving and use ceilometer for all of the necessary parts. c) is going ot take a while. There are still quite a few places in nova, for example, that depend on accessing deleted records. We realized that c) was not acheivable in a single release so decided to do a) so we could have unique constraints until the other issues were solved. So ultimately I think we are debating things which we already have a plan for. Vish I guess I'm still failing to see why a, b and then c as the proposed path. I'm mainly curious because the change is being proposed in Cinder and I still can't make sense of why. [1] I'm not saying this idea is wrong, I just don't understand the use case yet. For existing environments, why can't we just stop doing soft deletes and have audits happen through Ceilometer as the agreed end goal. We can keep around the delete column for deprecation reasons and allow time for ops to take that information and store it how they need it. [1] - https://review.openstack.org/#/c/40660/ -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] FFE Request: Make RBD Usable for Ephemeral Storage
Folks, Currently in Havana development, RBD as ephemeral storage has serious stability and performance issues that makes the Ceph cluster a bottleneck for using an image as a source. Nova has to currently communicate with the external service Glance, which has to talk to the separate Ceph storage backend to fetch path information. The entire image is then downloaded to local disk, and then imported from local disk to RBD. This leaves a stability concern, especially with large images for the instance to be successfully created, due to unnecessary data pulling and pushing for solutions like RBD. Due to the fact we have to do a import from local disk to RBD, this can make performance even slower than a normal backend filesystem since the import is single threaded. This can be eliminated by instead having Nova's RBD image backend utility communicate directly with the Ceph backend to do a copy-on-write of the image. Not only does this greatly improve stability, but performance is drastically improved by not having to do a full copy of the image. A lot of the code to make this happen came from the RBD Cinder driver which has been stable and merged for quite a while. Bug: https://code.launchpad.net/bugs/1226351 Patch: https://review.openstack.org/#/c/46879/1 Thanks, Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder]The inconsistency between cinder client v1 and v2 supported arguments.
On Mon, Sep 23, 2013 at 12:18 AM, Da Zhao Y Yu d...@cn.ibm.com wrote: Hi all, When I was fixing bug 1221611, current codeReview link. I found in CinderClient component, there are many inconsistent arguments in v1 and v2 shell.py. Consider backwards compatibility and consistency, I think we need to fix this problem. For convenience, I made the following list of v1/v2 arguments inconsistency, please review it, the folks who have better understanding of the CLI client history please provide more insights on how to deal with current situation. Thanks! We're moving towards dashes in the optional argument name with v2. In v1, optional args that don't support underscores can be changed to do so, but they should still support what they originally supported for compatibility. -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Code pointer for processing cinder backend config
On 09:36 Sat 06 Dec , Pradip Mukhopadhyay wrote: Where this config info is getting parsed out in the cinder code? https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/netapp/options.py https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/netapp/common.py#L76 -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [python-cinderclient] Return request ID to caller
On 05:54 Fri 12 Dec , Malawade, Abhijeet wrote: HI, I want your thoughts on blueprint 'Log Request ID Mappings' for cross projects. BP: https://blueprints.launchpad.net/nova/+spec/log-request-id-mappings It will enable operators to get request id's mappings easily and will be useful in analysing logs effectively. I've weighed on this question a couple of times now and recently from the Cinder meeting. Solution 1 please. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder driver] A question about Kilo merge point
On 11:40 Tue 16 Dec , liuxinguo wrote: If a cinder driver can not be mergerd into Kilo before Kilo-1, does it means that this driver will has very little chance to be merged into Kilo? And what percentage of drivers will be merged before Kilo-1 according to the whole drivers that will be merged into Kilo at last? Thanks! All the details for this is here: http://lists.openstack.org/pipermail/openstack-dev/2014-October/049512.html -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] [driver] DB operations
On 01:20 Fri 19 Dec , Duncan Thomas wrote: So our general advice has historical been 'drivers should not be accessing the db directly'. I haven't had chance to look at your driver code yet, I've been on vacation, but my suggestion is that if you absolutely must store something in the admin metadata rather than somewhere that is covered by the model update (generally provider location and provider auth) then writing some helper methods that wrap the context bump and db call would be better than accessing it directly from the driver. Duncan Thomas On Dec 18, 2014 11:41 PM, Amit Das amit@cloudbyte.com wrote: snip So what is the proper way to run these DB operations from within a driver ? Drivers not doing db changes is also documented in the How to contribute a driver wiki page. https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] [driver] DB operations
On 06:05 Sat 20 Dec , Duncan Thomas wrote: No, I mean that if drivers are going to access database, then they should do it via a defined interface that limits what they can do to a sane set of operations. I'd still prefer that they didn't need extra access beyond the model update, but I don't know if that is possible. Duncan Thomas On Dec 19, 2014 6:43 PM, Amit Das amit@cloudbyte.com wrote: Thanks Duncan. Do you mean hepler methods in the specific driver class? On 19 Dec 2014 14:51, Duncan Thomas duncan.tho...@gmail.com wrote: So our general advice has historical been 'drivers should not be accessing the db directly'. I haven't had chance to look at your driver code yet, I've been on vacation, but my suggestion is that if you absolutely must store something in the admin metadata rather than somewhere that is covered by the model update (generally provider location and provider auth) then writing some helper methods that wrap the context bump and db call would be better than accessing it directly from the driver. Duncan Thomas On Dec 18, 2014 11:41 PM, Amit Das amit@cloudbyte.com wrote: I've expressed in past reviews that we should have an interface that limits drivers access to the database [1], but received quite a bit of push back in Cinder. I recommend we stick to what has been decided, otherwise, Amit you should spend some time on reading the history of this issue [2] from previous meetings and start a rediscussion on it in the next meeting [3]. Not discouraging it, but this has been something brought up at least a couple of times now and it ends up with the same answer from the community. [1] - https://review.openstack.org/#/c/107693/14 [2] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-15-16.00.log.html#l-186 [3] - https://wiki.openstack.org/wiki/CinderMeetings -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] [Glance] [Swift] cinder upload-to-image creates image with 'queued' state
On 16:42 Thu 01 Jan , Timur Nurlygayanov wrote: Hi all, I have the strange error with Cinder: I have several volumes (with 30-100 Gb size) and I want to create Glance images based on these volumes, but when I execute snip How I can debug this issue? (I have no any errors/exceptions in Glance/Cinder/Swift logs) Regardless, please provide your cinder and glance logs. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Change reset-state to involve the driver
On 19:44 Thu 22 Jan , D'Angelo, Scott wrote: Thanks to everyone who commented on the spec to change reset-state to involve the driver: https://review.openstack.org/#/c/134366/ I've put some comments in reply, and I'm going to attempt to capture the various ideas here. I hope we can discuss this at the Mid-Cycle in Austin. 1) The existing reset-state python-cinderclient command should not change in unexpected ways and shouldn't have any new parameters (general consensus here). It should not fail if the driver does not implement my proposed changes (my opinion). 2) The existing reset-state is broken for some use cases (my UseCase2, for example, when stuck in 'attaching' but volume is still attached to instance). Existing reset-state will work for other situations (my UseCase1, when stuck in 'attaching' but not really attached. 3)MikeP pointed out that moving _reset_status() would break clients. I could use help with understanding some of the API code here. 4) Xing had noted that this doesn't fix Nova. I hope we can do that separately, since this is proving contentious enough. Some cases such as a timeout during initialize_connection() could be fixed in Nova with a bug once this change is in. Other Nova changes might require a new Nova API to call for cleanup during reset-state, and that sounds much more difficult to get through the Nova change process. 5) Walt suggested a new driver method reset_state(). This seems fine, although I had hoped terminate_connection() and detach_volume() would cover all possible cleanup in the driver. 6) MikeP pointed out that difficulty of getting 30+ drivers to implement a change. I hope that this can be done in such a way that the reset-state commands works exactly as it does today if this is not implemented in the driver. Putting code in the driver to improve what exists today would be strictly optional. Scott thanks for your work on this! I think your last comments have clarified things for me and I really like the direction this is going. I have replied to the review with some addition comments to add your ideas as I would like to keep the discussion in the review. Thanks! -- Mike Perez __ 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] [Cinder][3rd CI] Confused about “*real* storage backend”requirement for 3rd CI.
On 11:30 Fri 23 Jan , Bharat Kumar wrote: Liu, Yes, by default DevStack configures cinder with LVM. But we can customize DevStack to configure cinder with our own backend (real storage backend). Below is the link to the path, enables Automatic Configuration of GlusterFS for Cinder using devstack: https://review.openstack.org/#/c/133102/ And also below it the link to Configure CEPH with Cinder using devstack: https://review.openstack.org/#/c/65113/ Above two are old way of real storage plugin implementation. Sean Dague proposed a new way of devstack plugin implementation. Have a look at below two links: https://review.openstack.org/#/c/142805/ https://review.openstack.org/#/c/142805/7/doc/source/plugins.rst Just want to clarify that you don't have to make any changes in upstream devstack to configure devstack to use your volume driver. Information for configuring Devstack to use your driver as mentioned earlier can be found here: https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#How_do_I_configure_DevStack_so_my_Driver_Passes_Tempest.3F -- Mike Perez __ 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] Changes to Cinder Core
On 10:14 Wed 21 Jan , Mike Perez wrote: It gives me great pleasure to nominate Ivan Kolodyazhny (e0ne) for Cinder core. Ivan's reviews have been valuable in decisions, and his contributions to Cinder core code have been greatly appreciated. snip Cinder core, please reply with a +1 for approval. This will be left open until Jan 26th. Assuming there are no objections, this will go forward after voting is closed. Ivan Kolodyazhny is now part of Cinder core. Welcome to the team! -- Mike Perez __ 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] [cinder] Request for clarification regarding deadline for new drivers in Kilo
On 16:55 Mon 26 Jan , Eduard Matei wrote: Hi, Any update on this? No. Updates will be in your review, not this list. -- Mike Perez __ 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] [cinder] Why not allow deleting volume from a CG ?
On 15:51 Fri 06 Feb , Nilesh P Bhosale wrote: snip I understand this is as per design, but curious to understand logic behind this. snip Why not allow deletion of volumes form the CG? at least when there are no dependent snapshots. From the review [1], this is because allowing a volume that's part of a consistency group to be deleted is error prone for both the user and the storage backend. It assumes the storage backend will register the volume not being part of the consistency group. It also assumes the user is keeping tracking of what's part of a consistency group. With the current implementation, only way to delete the volume is to delete the complete CG, deleting all the volumes in that, which I feel is not right. The plan in Kilo is to allow adding/removing volumes from a consistency group [2][3]. The user now has to explicitly remove the volume from a consistency group, which in my opinion is better than implicit with delete. I'm open to rediscussing this issue with vendors and seeing about making sure things in the backend to be cleaned up properly, but I think this solution helps prevent the issue for both users and backends. [1] - https://review.openstack.org/#/c/149095/ [2] - https://blueprints.launchpad.net/cinder/+spec/consistency-groups-kilo-update [3] - https://review.openstack.org/#/c/144561/ -- Mike Perez __ 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] what code in cinder volume driver supports volume migration between two backends of same type but having different volume types?
On 00:31 Tue 20 Jan , Nikesh Kumar Mahalka wrote: do cinder retype (v2) works for lvm? How to use cinder retype? In the future, please have your subject prefixed with [cinder]. I tried for volume migration from one volume-type LVM backend to another volume-type LVM backend.But its failed. How can i acheive this? Please provide your cinder-api, cinder-vol, and cinder-scheduler service logs. You can paste things to http://paste.openstack.org -- Mike Perez __ 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] [Cinder] Cutoff deadlines for cinder drivers
On 13:53 Tue 20 Jan , Erlon Cruz wrote: Thanks Deepak! Mike is also sending the announce to the vendors in the mail accounts listed in the CI Status page[1]. [1] https://wiki.openstack.org/wiki/Cinder/third-party-ci-status I've actually gone through each volume driver file and emailed whoever mostly appeared in git blame, as well as whoever appeared recently in commits with an obvious company email address. This has been cross checked with the proposed maintainers file [1]. -- Mike Perez [1] - https://review.openstack.org/#/c/116887/ __ 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] Changes to Cinder Core
It gives me great pleasure to nominate Ivan Kolodyazhny (e0ne) for Cinder core. Ivan's reviews have been valuable in decisions, and his contributions to Cinder core code have been greatly appreciated. Reviews: https://review.openstack.org/#/q/reviewer:%22Ivan+Kolodyazhny+%253Ce0ne%2540e0ne.info%253E%22,n,z Contributions: https://review.openstack.org/#/q/owner:%22Ivan+Kolodyazhny%22+project:+openstack/cinder,n,z 30/90 day review stats: http://stackalytics.com/report/contribution/cinder-group/30 http://stackalytics.com/report/contribution/cinder-group/90 As new contributors step up to help in the project, some move onto other things. I would like to recognize Josh Durgin for his early contributions to Nova volume, early involvement with Cinder, and now unfortunately departure from the Cinder core team. Cinder core, please reply with a +1 for approval. This will be left open until Jan 26th. Assuming there are no objections, this will go forward after voting is closed. -- Mike Perez __ 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] Changes to Cinder Core
On Wed, Jan 21, 2015 at 10:14 AM, Mike Perez thin...@gmail.com wrote: It gives me great pleasure to nominate Ivan Kolodyazhny (e0ne) for Cinder core. Ivan's reviews have been valuable in decisions, and his contributions to Cinder core code have been greatly appreciated. Reviews: https://review.openstack.org/#/q/reviewer:%22Ivan+Kolodyazhny+%253Ce0ne%2540e0ne.info%253E%22,n,z Contributions: https://review.openstack.org/#/q/owner:%22Ivan+Kolodyazhny%22+project:+openstack/cinder,n,z 30/90 day review stats: http://stackalytics.com/report/contribution/cinder-group/30 http://stackalytics.com/report/contribution/cinder-group/90 As new contributors step up to help in the project, some move onto other things. I would like to recognize Josh Durgin for his early contributions to Nova volume, early involvement with Cinder, and now unfortunately departure from the Cinder core team. Cinder core, please reply with a +1 for approval. This will be left open until Jan 26th. Assuming there are no objections, this will go forward after voting is closed. And apologies for missing the [cinder] subject prefix. -- Mike Perez __ 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] [cinder] Request for clarification regarding deadline for new drivers in Kilo
On 11:24 Wed 21 Jan , Eduard Matei wrote: Hi, This weekend our driver [https://review.openstack.org/#/c/130733/] got a -2 stating that This is past the deadline for release of new drivers in Kilo. and the deadline for new drivers passed at the end of Kilo-1. This needs to wait for the L release. But, in another mail on the mailing list we were informed: If your driver is submitted *LATE* in k-1, and meets *all* the items above, but isn't merged, it will be still be considered for merge in k-2 or k-3. The items above being that the blueprint is submitted, together with cert tests and the code is submitted to gerrit and that a CI is working. We had the blueprint, cert tests and code on gerrit *EARLY* in k-1 (first patchset was on Oct 24), blueprint was approved for k-1 and cert tests were posted. CI is under construction, and will be ready by March deadline. So, can someone from cinder core clarify why the driver is delayed to L when all items are met? Would like to take this off the list. I replied to your review. -- Mike Perez __ 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] [cinder] All Cinder Volume Drivers Must Have A Third Party CI by March 19, 2014
*Note: A more detailed email about this has been sent to all Cinder volume driver maintainers directly.* In the Jan 14th 2015 16:00 UTC Cinder IRC meeting [1], it was agreed by Cinder core and participating vendors that the deadline for vendors to have a third party CI would be: March 19th 2015 There are requirements set for OpenStack Third Party CI's [2]. In addition Cinder third party CI's must: 1) Test all volume drivers your company has integrated in Cinder. 2) Test all fabrics your solution uses. For example, if your company has two volume drivers in Cinder and they both use ISCSI and FibreChannel, you would need to have a CI that tests against four backends and reports the results for each backend, for every Cinder upstream patch. To test we're using a subset of tests in Tempest [6]. To get started, read OpenStack's third party testing documentation [32]. There are a variety of solutions [3] that help setting up a CI, third party mentoring meetings [4], and designated people to answer questions with setting up a third party CI in the #openstack-cinder room [5]. If a solution is not being tested in a CI system and reporting to OpenStack gerrit Cinder patches by the deadline of March 19th 2015, a volume driver could be removed from the Cinder repository as of the Kilo release. Without a CI system, Cinder core is unable to verify your driver works in the Kilo release of Cinder. We will make sure OpenStack users are aware of this via the OpenStack users mailing list and Kilo release notes. Cinder third party CI's have been discussed throughout a variety of ways last year: * Cinder IRC Meetings: [1][9][10][11][12][13][14][15][16] * Midcycle meetups: [17] * OpenStack dev list: [18][19][20][21][22][23][24][25][26][27][28][29] * Design summit sessions: [30][31] If there is something not clear about this email, please email me *directly* with your question. You can also reach me as thingee on Freenode IRC in the #openstack-cinder channel. Again I want you all to be successful in this, and take advantage of this testing you will have with your product. Please communicate with me and reach out to the team for help. -- Mike Perez [1] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-14-16.00.log.html#l-21 [2] - http://ci.openstack.org/third_party.html#requirements [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Existing_CI_Solutions [4] - https://wiki.openstack.org/wiki/Meetings/ThirdParty [5] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Questions [6] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F [7] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-12-10-16.00.log.html#l-471 [8] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19-16.00.log.html#l-34 [9] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-29-16.00.log.html#l-224 [10] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-15-16.00.log.html#l-59 [11] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-08-16.00.log.html#l-17 [12] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-17-16.00.log.html#l-244 [13] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-07-02-16.01.log.html#l-141 [14] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-07-23-16.00.log.html#l-161 [15] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-06-18-16.02.log.html#l-255 [16] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-05-21-16.00.log.html#l-310 [17] - https://etherpad.openstack.org/p/cinder-meetup-summer-2014 [18] - http://lists.openstack.org/pipermail/openstack-dev/2014-September/045137.html [19] - http://lists.openstack.org/pipermail/openstack-dev/2014-October/047673.html [20] - http://lists.openstack.org/pipermail/openstack-dev/2014-July/039103.html [21] - http://lists.openstack.org/pipermail/openstack-dev/2014-December/051957.html [22] - http://lists.openstack.org/pipermail/openstack-dev/2014-August/043392.html [23] - http://lists.openstack.org/pipermail/openstack-dev/2014-August/042672.html [24] - http://lists.openstack.org/pipermail/openstack-dev/2014-August/041748.html [25] - http://lists.openstack.org/pipermail/openstack-dev/2014-February/026999.html [26] - http://lists.openstack.org/pipermail/openstack-dev/2014-March/028707.html [27] - http://lists.openstack.org/pipermail/openstack-dev/2014-July/039057.html [28] - http://lists.openstack.org/pipermail/openstack-dev/2014-February/027527.html [29] - http://lists.openstack.org/pipermail/openstack-dev/2014-August/041704.html [30] - https://etherpad.openstack.org/p/juno-cinder-3rd-party-cert-and-verification [31] - http://junodesignsummit.sched.org/event/56eae44976e986f39c858d784344c7d0 [32] - http://ci.openstack.org/third_party.html
Re: [openstack-dev] [cinder] FFE driver-private-data + pure-iscsi-chap-support
On 14:50 Sun 15 Feb , Patrick East wrote: Hi All, I would like to request a FFE for the following blueprints: https://blueprints.launchpad.net/cinder/+spec/driver-private-data https://blueprints.launchpad.net/cinder/+spec/pure-iscsi-chap-support The first being a dependency for the second. The new database table for driver data feature was discussed at the Cinder mid-cycle meetup and seemed to be generally approved by the team in person at the meeting as something we can get into Kilo. There is currently a spec up for review for it here: https://review.openstack.org/#/c/15/ but doesn't look like it will be approved by the end of the day for the deadline. I have code pretty much ready to go for review as soon as the spec is approved, it is a relatively small patch set. I already told Patrick I would help see this change in Kilo. If I can get another Cinder core to sponsor this, that would be great. This change makes it possible for some drivers to be able to have chap auth support in their unique setup, and I'd rather not leave people out in Cinder. -- Mike Perez __ 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] [cinder] FFE driver-private-data + pure-iscsi-chap-support
On 10:07 Wed 18 Feb , John Griffith wrote: On Tue, Feb 17, 2015 at 11:36 PM, Mike Perez thin...@gmail.com wrote: On 14:50 Sun 15 Feb , Patrick East wrote: Hi All, I would like to request a FFE for the following blueprints: https://blueprints.launchpad.net/cinder/+spec/driver-private-data https://blueprints.launchpad.net/cinder/+spec/pure-iscsi-chap-support The first being a dependency for the second. The new database table for driver data feature was discussed at the Cinder mid-cycle meetup and seemed to be generally approved by the team in person at the meeting as something we can get into Kilo. There is currently a spec up for review for it here: https://review.openstack.org/#/c/15/ but doesn't look like it will be approved by the end of the day for the deadline. I have code pretty much ready to go for review as soon as the spec is approved, it is a relatively small patch set. I already told Patrick I would help see this change in Kilo. If I can get another Cinder core to sponsor this, that would be great. This change makes it possible for some drivers to be able to have chap auth support in their unique setup, and I'd rather not leave people out in Cinder. -- Mike Perez __ 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 +2 from me, I'm willing to sponsor this This spec is approved for FFE. I would like to get a +2 on the spec from John, as well as approval from Walt who has interest in this being implemented for his drivers. -- Mike Perez __ 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] [cinder] Kilo Deadlines
On Sat, Jan 31, 2015 at 1:53 PM, Mike Perez thin...@gmail.com wrote: * Blueprint/Spec approval deadline - February 15th * Code freeze for all features - March 10th After blueprint/spec approval deadline date has passed, you may request exception by: 1) Email the Openstack Dev mailing list with [cinder] Request Spec Freeze Exception in the subject. 2) The spec is reviewed the usual way, but should be a high priority to get in. These deadlines were agreed on in the Cinder IRC meeting [1]. -- Mike Perez [1] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-14-16.00.log.html#l-303 February 15th is the last day to get a feature proposed for Kilo in Cinder. Any blueprints that are not approved after February 15th will need to request Feature Freeze Exception on this list, with the subject [cinder] FFE feature name. Yes, I changed the format, and we are terribly oversubscribed as it is. At this point I've gone through specs and left comments on the ones that I think that have a chance in Kilo. A blueprint will be removed from K-3 [1] if it does not have code proposed and passing Jenkins by March 1st as agreed in the Cinder meeting [2]. We will not be doing anymore merges, except for bug fixes after March 10th, as explained earlier in this thread and agreed in the Cinder meeting [3]. Cinder K-3 priorities have been set for people to sign up on [4]. [1] - https://launchpad.net/cinder/+milestone/kilo-3 [2] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-11-16.00.log.html#l-328 [3] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-14-16.00.log.html#l-303 [4] - https://etherpad.openstack.org/p/cinder-k3-priorities __ 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] [cinder] K-2 Review-a-thon
* Why: We got a bit in the review queue. K-2 [1] cut is set to February 5th. * When: February 2nd at 2:00 UTC [2] to February 5th at 2:00 UTC [3] or sooner if we finish! * Where: #openstack-cinder on freenode IRC. There will also be a posted google hangout link in channel and etherpad [4] since that really worked out in previous hackathons. Remember there is a limit, so please join only if you're really going to be participating. You also don't have to be core. I'm encouraging two cores to sign up for a review in the etherpad [4]. If there are already two people to a review, try to move onto something else to avoid getting burnt out on efforts already spent on a review. Patch owners will also be receiving an email directly from me to be aware of this prime time to respond back to feedback and post revisions if necessary. -- Mike Perez [1] - https://launchpad.net/cinder/+milestone/kilo-2 [2] - http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150202T02p1=1440 [3] - http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150205T02p1=1440 [4] - https://etherpad.openstack.org/p/cinder-k2-priorities __ 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] [cinder] Kilo Deadlines
* Blueprint/Spec approval deadline - February 15th * Code freeze for all features - March 10th After blueprint/spec approval deadline date has passed, you may request exception by: 1) Email the Openstack Dev mailing list with [cinder] Request Spec Freeze Exception in the subject. 2) The spec is reviewed the usual way, but should be a high priority to get in. These deadlines were agreed on in the Cinder IRC meeting [1]. -- Mike Perez [1] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-14-16.00.log.html#l-303 __ 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] [cinder] Etherpad for the Cinder midcycle meetup
The meetup will be in Austin, TX on January 27-29. You can find more information and post your topics on the etherpad: https://etherpad.openstack.org/p/cinder-kilo-midcycle-meetup -- Mike Perez __ 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] Vancouver Design Summit format changes
On 15:50 Fri 09 Jan , Thierry Carrez wrote: Hi everyone, The OpenStack Foundation staff is considering a number of changes to the Design Summit format for Vancouver, changes on which we'd very much like to hear your feedback. The problems we are trying to solve are the following: - Accommodate the needs of more OpenStack projects - Reduce separation and perceived differences between the Ops Summit and the Design/Dev Summit - Create calm and less-crowded spaces for teams to gather and get more work done While some sessions benefit from large exposure, loads of feedback and large rooms, some others are just workgroup-oriented work sessions that benefit from smaller rooms, less exposure and more whiteboards. Smaller rooms are also cheaper space-wise, so they allow us to scale more easily to a higher number of OpenStack projects. My proposal is the following. Each project team would have a track at the Design Summit. Ops feedback is in my opinion part of the design of OpenStack, so the Ops Summit would become a track within the forward-looking Design Summit. Tracks may use two separate types of sessions: * Fishbowl sessions Those sessions are for open discussions where a lot of participation and feedback is desirable. Those would happen in large rooms (100 to 300 people, organized in fishbowl style with a projector). Those would have catchy titles and appear on the general Design Summit schedule. We would have space for 6 or 7 of those in parallel during the first 3 days of the Design Summit (we would not run them on Friday, to reproduce the successful Friday format we had in Paris). * Working sessions Those sessions are for a smaller group of contributors to get specific work done or prioritized. Those would happen in smaller rooms (20 to 40 people, organized in boardroom style with loads of whiteboards). Those would have a blanket title (like infra team working session) and redirect to an etherpad for more precise and current content, which should limit out-of-team participation. Those would replace project pods. We would have space for 10 to 12 of those in parallel for the first 3 days, and 18 to 20 of those in parallel on the Friday (by reusing fishbowl rooms). Each project track would request some mix of sessions (We'd like 4 fishbowl sessions, 8 working sessions on Tue-Thu + half a day on Friday) and the TC would arbitrate how to allocate the limited resources. Agenda for the fishbowl sessions would need to be published in advance, but agenda for the working sessions could be decided dynamically from an etherpad agenda. By making larger use of smaller spaces, we expect that setup to let us accommodate the needs of more projects. By merging the two separate Ops Summit and Design Summit events, it should make the Ops feedback an integral part of the Design process rather than a second-class citizen. By creating separate working session rooms, we hope to evolve the pod concept into something where it's easier for teams to get work done (less noise, more whiteboards, clearer agenda). What do you think ? Could that work ? If not, do you have alternate suggestions ? Sounds good to me. Glad we're keeping the Friday format too! -- Mike Perez __ 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] [Cinder] Cutoff deadlines for cinder drivers
On 14:42 Fri 09 Jan , Ivan Kolodyazhny wrote: Hi Erlon, We've got a thread mailing-list [1] for it and some details in wiki [2]. Anyway, need to get confirmation from our core devs and/or Mike. [1] http://lists.openstack.org/pipermail/openstack-dev/2014-October/049512.html [2] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Testing_requirements_for_Kilo_release_and_beyond Regards, Ivan Kolodyazhny On Fri, Jan 9, 2015 at 2:26 PM, Erlon Cruz sombra...@gmail.com wrote: Hi all, hi cinder core devs, I have read on IRC discussions about a deadline for drivers vendors to have their CI running and voting until kilo-2, but I didn't find any post on this list to confirm this. Can anyone confirm this? Thanks, Erlon We did discuss and agree in the Cinder meeting that the deadline would be k-2, but I don't think anyone reached out to the driver maintainers about the deadline. Duncan had this action item [1], perhaps he can speak more about it. [1] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19-16.00.html -- Mike Perez __ 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] [Cinder] Cutoff deadlines for cinder drivers
On 21:00 Sat 10 Jan , Jay S. Bryant wrote: I think what we discussed was that existing drivers were supposed to have something working by the end of k-2, or at least have something close to working. For new drivers they had to have 3rd party CI working by the end of Kilo. Duncan, correct me if I am wrong. Jay On 01/10/2015 04:52 PM, Mike Perez wrote: On 14:42 Fri 09 Jan , Ivan Kolodyazhny wrote: Hi Erlon, We've got a thread mailing-list [1] for it and some details in wiki [2]. Anyway, need to get confirmation from our core devs and/or Mike. [1] http://lists.openstack.org/pipermail/openstack-dev/2014-October/049512.html [2] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Testing_requirements_for_Kilo_release_and_beyond Regards, Ivan Kolodyazhny On Fri, Jan 9, 2015 at 2:26 PM, Erlon Cruz sombra...@gmail.com wrote: Hi all, hi cinder core devs, I have read on IRC discussions about a deadline for drivers vendors to have their CI running and voting until kilo-2, but I didn't find any post on this list to confirm this. Can anyone confirm this? Thanks, Erlon We did discuss and agree in the Cinder meeting that the deadline would be k-2, but I don't think anyone reached out to the driver maintainers about the deadline. Duncan had this action item [1], perhaps he can speak more about it. [1] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19-16.00.html That is correct [1]. However, I don't think there was any warning given to existing drivers [2]. If Duncan can confirm this is the case, I would recommend fair warning go out for the end of Kilo for existing drivers as well. [1] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Deadlines [2] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19-16.00.html -- Mike Perez __ 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] [Cinder] Cutoff deadlines for cinder drivers
On 09:03 Mon 12 Jan , Erlon Cruz wrote: Hi guys, Thanks for answering my questions. I have 2 points: 1 - This (remove drivers without CI) is a way impacting change to be implemented without exhausting notification and discussion on the mailing list. I myself was in the meeting but this decision wasn't crystal clear. There must be other driver maintainers completely unaware of this. I agree that the mailing list has not been exhausted, however, just reaching out to the mailing list is not good enough. My instructions back in November 19th [1][2] were that we need to email individual maintainers and the openstack-dev list. That was not done. As far as I'm concerned, we can't stick to the current deadline for existing drivers. I will bring this up in the next Cinder meeting. 2 - Build a CI infrastructure and have people to maintain a the CI for a new driver in a 5 weeks frame. Not all companies has the knowledge and resources necessary to this in such sort period. We should consider a grace release period, i.e. drivers entering on K, have until L to implement theirs CIs. New driver maintainers have until March 19th. [3] That's around 17 weeks since we discussed this in November [2]. This is part the documentation for how to contribute a driver [4], which links to the third party requirement deadline [3]. [1] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19-16.00.html [2] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19-16.00.log.html#l-34 [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Deadlines [4] - https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver -- Mike Perez __ 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] [cinder] Feature Freeze Exception Request - bp/linux-systemz
On 17:31 Mon 09 Feb , Andreas Maier wrote: Hello, I would like to ask for the following feature freeze exception in Cinder. Cinder is not in a feature freeze at the moment [1]. Additional notes: The code in Nova patch set https://review.openstack.org/149256 is consistent with this patch set, but a decision to include them in kilo can be made independently for each of the two patch sets: The Nova patch set enables FCP storage for a compute node with KVM on System z, while the Cinder patch set enables Cinder services to run on System z Linux. If it's not landing in Nova for Kilo [2], I'd rather not target it for Kilo in Cinder. We're already really packed for K-3, and it's not useful without the Nova piece. Please resubmit for L-1 in Cinder. [1] - http://lists.openstack.org/pipermail/openstack-dev/2015-January/055719.html [2] - https://blueprints.launchpad.net/nova/+spec/libvirt-kvm-systemz -- Mike Perez __ 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] [cinder] Why not allow deleting volume from a CG ?
On 16:34 Mon 09 Feb , Nilesh P Bhosale wrote: Adding an ability to Add/Remove existing volumes to/from CG looks fine. But, it does not help the use-case where one would want to directly delete a volume from CG. Why do we force him to first remove a volume from CG and then delete? Xing and I have already explained the reasons for this decision previously in the thread. Besides it being an accident, you're making an assumption that all backends will handle directly removing a volume from a consistency group the same. I see a few ways they can handle it: 1) The backend errors on this, and the end user will never see the error, because it just goes to Cinder logs from the Cinder volume service. 2) The backend allows it, but they still see that volume part of the consistency group, even if it was deleted. Leaving things in a weird state. 3) The backend allows the delete and updates the consistency group accordingly. With 72 different drivers, you can't make an assumption here. As CG goes along with replication and backends creating a separate pool per CG, removing a volume from CG, just to be able to delete it in the next step, may be an unnecessary expensive operation. Can you explain more how this is expensive? I would argue making a mistake in deleting a volume that's part of a consistency group on accident would be an expensive mistake. In fact, I think whatever decision user takes, even to delete a normal volume, is treated as his conscious decision. We're humans, we make mistakes. I work on an interface that assumes this. -- Mike Perez __ 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] [cinder] [nova] [glance] Consistency in client side sorting
On 09:13 Mon 05 Jan , Steven Kaufer wrote: Giving that each of these 3 clients will be supporting client-side sorting in kilo, it seems that we should get this implemented in a consistent manner. It seems that the 2 options are either: --sort-key key1 --sort-dir desc --sort-key key2 --sort-dir asc --sort key1:asc,key2:desc Personally, I favor option 2 but IMO it is more important that these are made consistent. I like option 2 better. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder] Proposals for Liberty Summit
Proposals for the fishbowl, working and sprint sessions with the block storage project Cinder can be submitted now: https://etherpad.openstack.org/p/cinder-liberty-proposed-sessions On April 27th, we will be discussing these together in the Cinder IRC meeting [1]. This will allow time to set things in the official summit schedule. [1] - https://wiki.openstack.org/wiki/CinderMeetings -- Mike Perez __ 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] [cinder] K3 Feature Freeze Exception request for bp/nfs-backup
On 01:15 Thu 12 Mar , Fox, Kevin M wrote: Also, can https://review.openstack.org/#/c/163647https://review.openstack.org/#/c/163647/2 be considered. all it does is move code from the accepted nfs.py to posix.py as described in the approved spec. This enables all posix complient file systems to be used, such as lustre instead of just nfs. It is already tested through the nfs tests. I would rather review resources be spent on approving the back log of bugs we have submitted. That's what this time is spent for. There's no reason this can't wait for Liberty. The posix backup driver has been cooking in one form or another since Juno. It would be a shame to need to wait over a year and a half for it. Technically this will be in October, which is not a year and a half. More than happy to review in L-1. -- Mike Perez __ 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] [cinder]difference between spec merged and BP approval
On 02:22 Sat 07 Mar , Chen, Wei D wrote: Hi, I thought the feature should be approved as long as the SPEC[1] is merged, but it seems I am wrong from the beginning[2], both of them (SPEC merged and BP approval[4][5]) is necessary and mandatory for getting some effective reviews, right? anyone can help to confirm with that? Besides, who is eligible to define/modify the priority in the list[3], only PTL or any core? I am trying to understand the acceptable procedure for the coming 'L'. [1] https://review.openstack.org/#/c/136253/ [2] https://review.openstack.org/#/c/147726/ [3] https://etherpad.openstack.org/p/cinder-k3-priorities [4] https://blueprints.launchpad.net/cinder/+spec/support-modify-volume-image-metadata [5] https://blueprints.launchpad.net/python-cinderclient/+spec/support-modify-volume-image-metadata There are a few things: 1) The blueprint should've been approved and targeted for K-3 after the spec was merged, but that never happened. 2) This shouldn't have been -2 on March 6th, it still had until March 10th technically since the blueprint should've been approved. 3) There were disageements on snapshots having mutable metadata as discussed in a Cinder meeting [1]. I agree with Duncan on how this can break billing properties. I also mentioned in the meeting that I would not merge this until that was addressed. Regardless, we're way too late for K now. Apologies on this not been targeted, but feel free to let me know in the future if I miss something of yours that should be targeted so it's prioritized. [1] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-11-16.00.log.html#l-186 -- Mike Perez __ 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] [cinder] All Cinder Volume Drivers Must Have A Third Party CI by March 19, 2014
The deadline is almost near. First off I want to thank all driver maintainers who are reporting successfully with their driver CI in Cinder reviews. For many of you, I know you discovered how useful the CI is, in just the bugs it has caught or revealed. OpenStack users that use your solution will appreciate the added stability as well. I have been keeping a report of the different vendors, which I promised to make public: https://docs.google.com/spreadsheets/d/1GrIzXY4djNbJnF3RMw44_2e3aTWgBbgnBlSKafEDNGQ/edit?usp=sharing If you're not marked with a light green or dark green color and you believe this is a mistake, please let me know on IRC via thingee or this email address, and provide proof of multiple reviews your CI has posted results to. For the drivers that have not responded and won't be able to make the deadline. Proposing your driver back into Cinder in Liberty will require a CI reporting before merge back in. I want to make this as easy as possible to be merged back into tree, so I will just do a diff of what's being proposed and what was previously in tree. This should cut down on a review time quite a bit. Drivers that are removed in the Kilo release will be mentioned in the release notes if they were in prior to Kilo. -- Mike Perez On Thu, Jan 15, 2015 at 7:31 PM, Mike Perez thin...@gmail.com wrote: *Note: A more detailed email about this has been sent to all Cinder volume driver maintainers directly.* In the Jan 14th 2015 16:00 UTC Cinder IRC meeting [1], it was agreed by Cinder core and participating vendors that the deadline for vendors to have a third party CI would be: March 19th 2015 There are requirements set for OpenStack Third Party CI's [2]. In addition Cinder third party CI's must: 1) Test all volume drivers your company has integrated in Cinder. 2) Test all fabrics your solution uses. For example, if your company has two volume drivers in Cinder and they both use ISCSI and FibreChannel, you would need to have a CI that tests against four backends and reports the results for each backend, for every Cinder upstream patch. To test we're using a subset of tests in Tempest [6]. To get started, read OpenStack's third party testing documentation [32]. There are a variety of solutions [3] that help setting up a CI, third party mentoring meetings [4], and designated people to answer questions with setting up a third party CI in the #openstack-cinder room [5]. If a solution is not being tested in a CI system and reporting to OpenStack gerrit Cinder patches by the deadline of March 19th 2015, a volume driver could be removed from the Cinder repository as of the Kilo release. Without a CI system, Cinder core is unable to verify your driver works in the Kilo release of Cinder. We will make sure OpenStack users are aware of this via the OpenStack users mailing list and Kilo release notes. Cinder third party CI's have been discussed throughout a variety of ways last year: * Cinder IRC Meetings: [1][9][10][11][12][13][14][15][16] * Midcycle meetups: [17] * OpenStack dev list: [18][19][20][21][22][23][24][25][26][27][28][29] * Design summit sessions: [30][31] If there is something not clear about this email, please email me *directly* with your question. You can also reach me as thingee on Freenode IRC in the #openstack-cinder channel. Again I want you all to be successful in this, and take advantage of this testing you will have with your product. Please communicate with me and reach out to the team for help. -- Mike Perez [1] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-14-16.00.log.html#l-21 [2] - http://ci.openstack.org/third_party.html#requirements [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Existing_CI_Solutions [4] - https://wiki.openstack.org/wiki/Meetings/ThirdParty [5] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Questions [6] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F [7] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-12-10-16.00.log.html#l-471 [8] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19-16.00.log.html#l-34 [9] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-29-16.00.log.html#l-224 [10] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-15-16.00.log.html#l-59 [11] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-08-16.00.log.html#l-17 [12] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-17-16.00.log.html#l-244 [13] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-07-02-16.01.log.html#l-141 [14] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-07-23-16.00.log.html#l-161 [15] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-06-18-16.02.log.html#l-255 [16] - http://eavesdrop.openstack.org/meetings
Re: [openstack-dev] [OpenStack-Infra] [cinder] Could you please re-consider Oracle ZFS/SA Cinder drivers (iSCSI and NFS)
On 12:37 Fri 20 Mar , Alka Deshpande wrote: Hi MIke, My team and I would like to respectfully request a revert for the change at:https://review.openstack.org/#/c/165939/ to bring back the ZFSSA drivers to Kilo. Oracle has the CI working internally and we are in the process of going through internal security review, which is expected to be done by the end of March. In the mean time, we have gotten permission to post test results to an external webserver. We will have results reported by the end of the week. If need be, we can show proof of CI running internally by pasting results to pastebin: http://paste.openstack.org/show/193964/ We have been working diligently on setting up the CI system, and we have been keeping you updated since the mid-cycle meetup in Austin. We really appreciate your consideration. We do take CI setup effort very seriously and striving to get it to the level of your satisfaction. The tag for Kilo in Cinder has already happened, so it's too late to revert. We may be able to revisit this in Kilo RC, but I want to see your CI reporting reliably now to then to Cinder reviews. FWIW, everyone who was removed told me they were taking it seriously too. Just not serious enough to have CI's reporting by the overly announced deadline. [1][2][3][4][5][6][7][8] [1] - http://lists.openstack.org/pipermail/openstack-dev/2015-January/054614.html [2] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers [3] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-21-16.00.log.html [4] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-04-16.04.log.html [5] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-18-16.00.log.html [6] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-25-16.00.log.html [7] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-04-16.00.log.html [8] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-18-16.00.log.html -- Mike Perez __ 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] [cinder] Request exemption for removal of NetApp FC drivers (no voting CI)
On 12:33 Fri 20 Mar , ClaytonLuce, Timothy wrote: I'd like to point out that for NetApp FC drivers NetApp has been in discussions and updating progress on these drivers since their submission. I will point out a discussion in the Nov Core meeting where I brought up the challenge around FC environments and the response I received: snip NetApp has in good faith been working toward implementing a CI for FC, I won't go into the challenges of spending $$ for lab equipment to build out a scalable quality CI system but suffice it to say the lab equipment is on order and scheduled for arrival the first part of April, at which point we can put in place the CI for FC. 1) We've been talking about CI's since Feburary 2014. That's really too bad this took so long. The deadline itself has been overly announced on the mailing list and Cinder IRC meetings. [1][2][3][4][5][6][7][8] 2) We have a number of FC drivers today that had no problem meeting this deadline that was expressed in November 2014. 3) I've barely received updates from Netapp folks on progress here. I'm the only point of contact, so if you weren't talking to me, then it's unknown. I've expressed this to a number of your engineers and in my announcements about the CI deadline [8] I had to engage with Netapp to get updates, no one came to me with updates. The last update I heard from one of your engineers was, we bought the hardware, but it's just sitting there. That is not acceptable with us being past the deadline, and shows a clear sign of this not being a priority. NetApp has been very forthcoming in our progress and have gotten all our other CI systems in place for 7-mode iSCSI/NFS, cDOT iSCSI/NFS and E-Series. I respectfully request that NetApp FC be removed from this list of drivers to be removed for Kilo and placed back in the releaes and we can negotiate an agreed upon time as to when the CI system for these drivers will be in place. There will be no negotiating on what is an acceptable timeline for Netapp. What we all agreed to as a *community* back at the summit and Cinder IRC meeting was it. [1] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers [2] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-21-16.00.log.html [3] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-04-16.04.log.html [4] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-18-16.00.log.html [5] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-25-16.00.log.html [6] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-04-16.00.log.html [7] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-18-16.00.log.html [8] - http://lists.openstack.org/pipermail/openstack-dev/2015-January/054614.html -- Mike Perez __ 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] [cinder] May you reconsider about huawei driver?
On 09:41 Fri 20 Mar , Jay S. Bryant wrote: Mike, Looks like this removal may have been a mistake. We should readdress. This was not a mistake. As Walt has mentioned that CI run failed anyways. Also if you take a look at Huawei's CI reporting history, it's not that often AND not reliable [1]. This is not satisfactory meeting the requirements. If we're saying they're having networking issues from January to now, this really sounds like to me it was *not* a priority. [1] - https://review.openstack.org/#/q/reviewer:+huawei-ci+project:openstack/cinder,n,z -- Mike Perez __ 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] [cinder] Request exemption for removal of NetApp FC drivers (no voting CI)
On 21:53 Fri 20 Mar , Rochelle Grober wrote: Ditto for Huawei. While we are not *reliably* reporting, we are reporting and the necessary steps have already been taken (and more importantly, approved) to get this reliably working ASAP. We respectfully request the same consideration for our cinder drivers. The most important piece of a CI meeting the requirements is that the test pass with your storage solution configured in Cinder, and to only report failures when a patch really does break your integration. Otherwise, there is no point. So far, the times Huawei-ci has reported have been false failures [1]. [1] - https://review.openstack.org/#/q/reviewer:+huawei-ci+project:openstack/cinder,n,z -- Mike Perez __ 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] [cinder] cinder is broken until someone fixes the forking code
On 11:49 Wed 11 Mar , Walter A. Boring IV wrote: We have this patch in review currently. I think this one should 'fix' it no? Please review. https://review.openstack.org/#/c/163551/ Looks like it to me. Would appreciate a +1 from Mike Bayer before we push this through. Thanks for all your time on this Mike. -- Mike Perez __ 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
