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] [Openstack-dev][Cinder] FFE request for adding Huawei SDSHypervisor driver and connector
On 17:38 Fri 12 Sep , Thierry Carrez wrote: > Zhangni wrote: > > I'd like to request an Juno feature freeze exception for this blueprint > > and Spec: > > > > https://blueprints.launchpad.net/cinder/+spec/huawei-sdshypervisor-driver > > I would say it's way too late at this point for a new driver in Juno. At > this point we should be focused on fixing what we already have, not add > more surface. > > Cheers, > > -- > Thierry Carrez (ttx) +1 Zhangni, you are however on track for the window to have your driver in for K-1 [1]. Please make sure to communicate with Duncan Thomas about your third-party CI [2]. [1] - http://lists.openstack.org/pipermail/openstack-dev/2014-September/044990.html [2] - https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver#Third_Party_CI_Requirement_Policy -- 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
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 > wrote: > > > > > > > > >> 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] Re-initializing or dynamically configuring cinder driver
On Sun, Dec 15, 2013 at 3:08 AM, iKhan wrote: > I don't know if this is being planned in Icehouse, if not probably > proposing an approach will help. We have seen cinder-volume service > initialization part. Similarly if we can get our hands on child process > that are running under cinder-volume service, if we terminate those process > and restart them along with newly added backends. It might help us achieve > the target. > It's not in the plans [1][2]. Having the idea spec'd out in the wiki and setting an agenda item [3] for the next meeting can get things going though. [1] - https://launchpad.net/cinder/+milestone/icehouse-2 [2] - https://launchpad.net/cinder/+milestone/icehouse-3 [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] Tracking mox to mock unit tests?
On Sat, Dec 14, 2013 at 10:30 PM, Subramanian < subramanian.neelakan...@gmail.com> wrote: > Is there a bug/bp tracking the overall cinder unit tests move from mox to > mock? Is this targeted to complete in IceHouse? > > Thanks, > Subbu > There is no bp tracking who is switching over what. The general idea, and I think this is similar to other programs [1], we want new test cases when possible to be done in mock. Avishay has already proposed a patch to switch scheduler tests over to mock [2] though. As I've heard from multiple driver maintainers, they're going off to switch their tests over to mock, however, the team has not started on discussing a hard deadline yet. [1] - http://lists.openstack.org/pipermail/openstack-dev/2013-November/018520.html [2] - https://review.openstack.org/#/c/60715/ -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 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, 赵钦 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 >> > 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 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 > >> 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 wrote: > On 12/13/13, 4:50 AM, "Thierry Carrez" 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 wrote: > On Tue, Dec 17, 2013 at 11:44 AM, Jarret Raim > wrote: > >> On 12/13/13, 4:50 AM, "Thierry Carrez" 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 wrote: > 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 wrote: > On 12/19/2013 12:10 AM, Mike Perez wrote: > > On Tue, Dec 17, 2013 at 1:59 PM, Mike Perez > <mailto:thin...@gmail.com>> wrote: > > > 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 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 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 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] [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 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] 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" wrote: > > > 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" wrote: > > > Thanks Duncan. > > Do you mean hepler methods in the specific driver class? > > On 19 Dec 2014 14:51, "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" 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 > 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] [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] 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] [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 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] 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 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 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
[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.opens
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
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
Re: [openstack-dev] Changes to Cinder Core
On Wed, Jan 21, 2015 at 10:14 AM, 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. > > 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
[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] [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] [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 09:40 Sun 25 Jan , liuxinguo wrote: > It still can not work. > > My local.conf is: > > [[post-config|\$CINDER_CONF]] > [DEFAULT] > enabled_backends=huawei_18000 > [huawei_18000] > volume_driver=cinder.volume.drivers.huawei.HuaweiVolumeDriver > cinder_huawei_conf_file=/etc/cinder/cinder_huawei_conf.xml > > And the resulted cinder.conf is: > > [DEFAULT] > default_volume_type = default > enabled_backends = default > [default] > volume_group = stack-volumes-default > volume_driver = cinder.volume.drivers.lvm.LVMISCSIDriver > volume_backend_name = default > > Looks like it did not work as I expected. Is there anything I am wrong? Your local.conf is missing the first line needed in local.conf: [[local|localrc]] Please reread the instructions in the Cinder thirdparty doc: https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#How_do_I_configure_DevStack_so_my_Driver_Passes_Tempest.3F You're also encouraged to use the third party meeting for help: https://wiki.openstack.org/wiki/Meetings/ThirdParty -- 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. > 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][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: > 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
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]a question about os-volume_upload_image
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 ___ 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 kernel. 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 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 that direction. Instead of listing out the technical things that need to be improved in Cinder, I would like to just talk about the things as PTL I would improve, which as a side effect will allow the team to focus better on those technical issues. Cinder is a small but a very effective team. Just like other projects, we need more contributors to handle the requirements we get daily. First impressions with contributors who are very excited to make their name in OpenStack can be better helped by simple outreach in how they can be more effective with the team. Guiding those contributors on what are the goals, and spending a little time with them on how their interests can help those goals can go a long way. Currently I feel like potential long term contributors are discouraged in the time that they spend on evaluating what they could improve and to later find out that their proposed improvements don't fit the project plans. Focus itself can help contributors be effective in what's important. With the support of the community, I would like to raise better guidelines on when certain contributions are appropriate. With these community agreed guidelines, it should be clearer on what is appropriate for review and what can be pushed to the next release. With a better focus we can allow more time for features to be more complete as mentioned earlier. Being complete means having confidence something works. This can be ensured by trying changes before merge when possible and not relying on tests alone, having performance results, and actually having documentation so people know how to use new features. Release notes are not enough to figure out new Cinder features. I want to help the team realize more they can do in Cinder. I don't want to be a single person people rely on in the project, but rather have this team help me carry this project forward. Thank you, 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 18:37 Thu 03 Apr , Lingxian Kong wrote: > Thanks Duncan for your answer. > > I am very interested in making a contribution towards this effort, but > what to do next? Waiting for approving for this blueprint? Or see > others' opinions on this before we putting more efforts in achieving > this? I just want to make sure that we could handle other people's use > cases and not just our own. 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. -- 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] Support for multiple sort keys and sort directions in REST GET APIs
Duncan, I think the point you raise could happen even without this change. In the example of listing volumes, you would first query for the list in some multi-key sort. The API extensions for example that add additional response keys will do another lookup on that resource for the appropriate column it's retrieving. There are some extensions that still do this unfortunately, but quite a few got taken care of in Havana in using cache instead of doing these wasteful lookups. Overall Steven, I think this change is useful, especially from one of the Horizon sessions I heard in Hong Kong for filtering/sorting. -- Mike Perez On 11:18 Thu 03 Apr , Duncan Thomas wrote: > Some of the cinder APIs do weird database joins and double lookups and > things, making every field sortable might have some serious database > performance impact and open up a DoS attack. Will need more > investigation to be sure. > > On 2 April 2014 19:42, Steven Kaufer wrote: > > I have proposed blueprints in both nova and cinder for supporting multiple > > sort keys and sort directions for the GET APIs (servers and volumes). I am > > trying to get feedback from other projects in order to have a more uniform > > API across services. ___ 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] [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
[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
[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 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] Now accepting Kilo specs
There is a specs/kilo directory [1] available now. I will be doing plenty of reviewing and organizing this week! Please keep in mind of stable priorities as you're proposing things [2]. -- Mike Perez [1] - https://github.com/openstack/cinder-specs/tree/master/specs/kilo [2] - https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work ___ 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][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 > 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
[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 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] Propose Jay Bryant for core
On Tue, Oct 29, 2013 at 1:54 PM, John Griffith wrote: > 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] RFC: reverse the default Gerrit sort order
On Wed, Nov 6, 2013 at 3:36 PM, Robert Collins wrote: > I've been thinking about review queues recently (since here at the > summit everyone is talking about reviews! :)). > > One thing that struck me today was that Gerrit makes it easier to > review the newest changes first, rather than the changes that have > been in the queue longest, or the changes that started going through > the review process first. > > So... is it possible to change the default sort order for Gerrit? How > hard is it to do - could we do an experiment on that and see if it > nudges the dial for reviewstats (just make the change, not ask anyone > to change their behaviour)? > > As for what sort order to choose, I'd be happy just getting data on a > different default sort order - it seems like the easiest thing would > be to reverse the current order, vs doing something more > sophisticated. > > If folk are about to jump up and say 'hey, reviewday' or 'hey > next-review' : I specifically want to see what the effect on changing > the Gerrit web UI is, because my sense is that that is the default > place folk do reviews, and I want to change the default-experience > folk have, not the optional experience folk can opt into. > > -Rob > > -- > Robert Collins > Distinguished Technologist > HP Converged Cloud > I tend to use this review priority page [1], which appears to give a higher score to things by age (according to the cinder listing the oldest one has no bp or bug and is on the top), bp priority, and bug priority. Now this doesn't stop people from grabbing the first thing on gerrit reviews, but perhaps we can encourage better practices by where people usually start [2] and maybe a link to good review workflows [3] on gerrit itself? [1] - http://status.openstack.org/reviews [2] - https://wiki.openstack.org/wiki/How_To_Contribute [3] - https://wiki.openstack.org/wiki/ReviewWorkflowTips -- 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 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 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] [OpenStack][Cinder] Driver qualification
On Thu, Jul 25, 2013 at 5:44 PM, John Griffith wrote: > Hey Everyone, > > Something I've been kicking around for quite a while now but never really > been able to get around to is the idea of requiring that drivers in Cinder > run a qualification test and submit results prior to introduction in to > Cinder. > As being someone who has reviewed many drivers into Cinder, this would be immensely awesome. I find myself often times unsure of certain caveats in drivers, and having this along side would reassuring. 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] OpenStack Cinder List Snapshots Support
Hi Mikhail, cinder.db.sqlalchemy.api exposes snapshot_update which allows updating that table. Thanks, Mike Perez On Mon, Aug 5, 2013 at 8:25 AM, Mikhail Khodos wrote: > Thanks, that's what I thought! Do you know how to update that table? > > > 2013/8/4 Avishay Traeger > >> This is handled by the DB, not drivers. That line doesn't make sense. >> >> Thanks, >> Avishay >> >> >> >> From: Mikhail Khodos >> To: openstack-dev@lists.openstack.org, >> Date: 08/01/2013 11:09 PM >> Subject:[openstack-dev] OpenStack Cinder List Snapshots Support >> >> >> >> The Cinder Support Matrix >> https://wiki.openstack.org/wiki/CinderSupportMatrix, states that snapshot >> listing is implemented in drivers by: LVM, EMC, NetApp, IBM, etc. However, >> I could not find any methods or interfaces in the cinder volume api that >> implement snapshot listing. Could anybody clarify if snapshot listing is >> supported only via DB? >> > > ___ 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 wrote: > While the topic of WSME is open - Has anyone actually tried using it? > > > > 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 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 wrote: > > On Aug 20, 2013, at 2:44 PM, Mike Perez 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
Re: [openstack-dev] [cinder] meeting place for event Monday night in Tokyo ...
On 15:54 Oct 21, Jay S. Bryant wrote: > Not sure where the evening will take us, but we are planning to meet > by registration at the Convention Center. Looking at the map, if I > am reading it properly, in front of the Huawei Community Lounge on > the first floor looks like a good place to meet that is right near > registration. So, lets go for that. :-) I know a place with local craft beer and pizza. The only time this week you'll probably have it in Tokyo with the other festivities happening. venue: http://bairdbeer.com/en/tap/nakameguro.html map: https://goo.gl/maps/umqvsjPag3S2 I delegate someone to make reservations for 15 people. -- 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] [keystone] [nova] [cinder] Mitaka summit working session: Resource Federation for an Open Cloud
On 12:27 Oct 19, George Silvis, III wrote: > Although all of our changes are to Nova, the changes have implications > for Cinder and Keystone as well. So, with the help of the Nova team, we > are in the process of organizing a cross-project session at the Mitaka > design summit. We're especially looking for Nova, Cinder, and Keystone > developers to attend and give feedback. I will definitely be there for the Cinder side. -- 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] meeting place for event Monday night in Tokyo ...
> On Oct 25, 2015, at 10:48, Mike Perez wrote: > > On 15:54 Oct 21, Jay S. Bryant wrote: > > > >> Not sure where the evening will take us, but we are planning to meet >> by registration at the Convention Center. Looking at the map, if I >> am reading it properly, in front of the Huawei Community Lounge on >> the first floor looks like a good place to meet that is right near >> registration. So, lets go for that. :-) > > I know a place with local craft beer and pizza. The only time this week you'll > probably have it in Tokyo with the other festivities happening. > > venue: http://bairdbeer.com/en/tap/nakameguro.html > map: https://goo.gl/maps/umqvsjPag3S2 > > I delegate someone to make reservations for 15 people. Taking initiative here and booked our restaurant for 15 people. Done. T.Y. HARBOR Japan, 〒140-0002 Tokyo, Shinagawa, Higashishinagawa, 2 Chome−1, 東品川２−１−３ https://goo.gl/maps/bg6awGGf2GT2 -- 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] meeting place for event Monday night in Tokyo ...
On Oct 25, 2015, at 18:19, Mike Perez wrote: >> On Oct 25, 2015, at 10:48, Mike Perez wrote: >> >> On 15:54 Oct 21, Jay S. Bryant wrote: >> >> >> >>> Not sure where the evening will take us, but we are planning to meet >>> by registration at the Convention Center. Looking at the map, if I >>> am reading it properly, in front of the Huawei Community Lounge on >>> the first floor looks like a good place to meet that is right near >>> registration. So, lets go for that. :-) >> >> I know a place with local craft beer and pizza. The only time this week >> you'll >> probably have it in Tokyo with the other festivities happening. >> >> venue: http://bairdbeer.com/en/tap/nakameguro.html >> map: https://goo.gl/maps/umqvsjPag3S2 >> >> I delegate someone to make reservations for 15 people. > > Taking initiative here and booked our restaurant for 15 people. Done. > > T.Y. HARBOR > Japan, 〒140-0002 Tokyo, Shinagawa, Higashishinagawa, 2 Chome−1, 東品川２−１−３ > https://goo.gl/maps/bg6awGGf2GT2 This will be at 7pm Monday. -- 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] Cross-Project meeting, Tue Nov 3rd, 21:00 UTC
Dear PTLs, cross-project liaisons and anyone else interested, We'll have a cross-project meeting tomorrow at 21:00 UTC, with the following agenda: * Review past action items * Team announcements (horizontal, vertical, diagonal) * Design Summit feedback * Proposed changes to the cross-project meeting, following the cross-project workshop on it * Open discussion If you're from a horizontal team (Release management, QA, Infra, Docs, Security, I18n...) or a vertical team (Nova, Swift, Keystone...) and have something to communicate to the other teams, feel free to abuse the relevant sections of that meeting and make sure it gets #info-ed by the meetbot in the meeting summary. See you there! For more details on this meeting, please see: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting -- 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
