Mike, Noji asked me to commit it http://markmail.org/message/da6irvkbfqolwz6r You are right about it not being marked as critical and both 6928 and 6935 coming from him I assumed .... sorry @Noji, I will revert the commits.
On Fri, Jun 27, 2014 at 4:57 PM, Mike Tutkowski <mike.tutkow...@solidfire.com> wrote: > Hi, > > I would say that once Daan reverts the commits I mentioned in a previous > e-mail (related to 4.4 and 4.4-forward) that we are OK on those branches. > > We can then try out the patch on master and see how it works. > > Unless I'm missing something, I don't think that code was intended for 4.4 > or even 4.4-forward as it's not related to a blocker or critical ticket. > > Thanks, > Mike > > > On Fri, Jun 27, 2014 at 5:03 AM, Daan Hoogland <daan.hoogl...@gmail.com> > wrote: >> >> Thanks Noji, >> >> Please be very specific about which commits should be reverted and >> which should be cherry-picked (and which related commits should stay) >> I don't want to do anything last minute untill we are absolutely sure >> and in agreement of what will work. >> >> On Fri, Jun 27, 2014 at 10:42 AM, Yoshikazu Nojima <m...@ynojima.net> >> wrote: >> > Hi Dann, >> > Thank you for organizing issue. >> > >> >> Is this a blocker? >> > Yes, it is. At least Mike's latest commit in master should be picked >> > into 4.4 to utilize SolidFire's storage. >> > If possible, I would like to make additional change I proposed. I >> > regard this part is better to have, but not a blocker for 4.4. >> > >> >> Do you have that patch ready to ship? >> > Yes, I have a patch and I pushed with a branch name >> > "remove-root-disk-filtering-logic-for-iscsi-storage". >> > >> > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/remove-root-disk-filtering-logic-for-iscsi-storage >> > I suppose it works for Mike since the root disk filtering logic he >> > concerned is removed. >> > I confirmed it can be compiled, but I haven't confirmed in a test >> > environment with iSCSI storage. >> > >> > Mike, >> > Could you confirm this fix will resolve your concern? >> > >> > 2014-06-27 1:56 GMT-06:00 Daan Hoogland <daan.hoogl...@gmail.com>: >> >> Noji, Mike, >> >> >> >> Is this a blocker? I realize that we are in three different timezones >> >> and always one of us must be sleeping but I really would like to >> >> handle this today in spite of other tasks. >> >> >> >> @Mike: I suppose you would consider it a blocker. if you read Noji's >> >> latest proposal before breakfast, can you say something about the >> >> feasibility of the solution? >> >> >> >> @ Noji, Do you have that patch ready to ship? and do you have an >> >> alternative, in case it doesn't work for Mike? >> >> As I recall the original issue that you solved with it was quite >> >> serious to you, was it? Could we release with a revert? >> >> >> >> 20:00 UTC I come back home from unrelated business and could have an >> >> irc meeting. >> >> regard and many thanks, >> >> Daan >> >> >> >> On Fri, Jun 27, 2014 at 9:14 AM, Daan Hoogland >> >> <daan.hoogl...@gmail.com> wrote: >> >>> ok, Mike I will have a look how it came in and revert >> >>> >> >>> On Fri, Jun 27, 2014 at 8:19 AM, Mike Tutkowski >> >>> <mike.tutkow...@solidfire.com> wrote: >> >>>> Yeah, I just looked at the Review Request: >> >>>> >> >>>> https://reviews.apache.org/r/22717/#review46838 >> >>>> >> >>>> It says it's for master (4.5), so I'm not sure how this ended up in >> >>>> 4.4 or >> >>>> 4.4-forward. >> >>>> >> >>>> >> >>>> On Fri, Jun 27, 2014 at 12:09 AM, Mike Tutkowski < >> >>>> mike.tutkow...@solidfire.com> wrote: >> >>>> >> >>>>> Hi Daan, >> >>>>> >> >>>>> Please revert commit 99dd86e588fd28dedd5fb3b830297a8a4f885760 from >> >>>>> 4.4. >> >>>>> >> >>>>> Also, please revert commit 45f0c7367680f4bfbcee470139b708d69322be78 >> >>>>> from >> >>>>> 4.4-forward. >> >>>>> >> >>>>> These commits actually break zone-wide primary storage. >> >>>>> >> >>>>> I was not aware that they ended up in 4.4 and 4.4-forward (I was >> >>>>> thinking >> >>>>> they were just in master). >> >>>>> >> >>>>> I performed some testing on this logic in master tonight and saw the >> >>>>> breakage of zone-wide primary storage. >> >>>>> >> >>>>> In my opinion, we don't have enough in the way of regression testing >> >>>>> in >> >>>>> CloudStack to be comfortable committing code that can have such >> >>>>> wide-ranging effects this late in the game. >> >>>>> >> >>>>> I think we should start asking for a risk analysis from the >> >>>>> developer when >> >>>>> code is checked in this late in the game (the more risk, the more >> >>>>> important >> >>>>> the issue better be and the more testing that better have been >> >>>>> done). In >> >>>>> this case, my entire plug-in would have been rendered useless in 4.4 >> >>>>> by >> >>>>> these checkins and I don't understand how the issue itself even >> >>>>> qualified >> >>>>> as a Blocker or Critical. >> >>>>> >> >>>>> Thanks, Daan! >> >>>>> >> >>>>> -- >> >>>>> *Mike Tutkowski* >> >>>>> *Senior CloudStack Developer, SolidFire Inc.* >> >>>>> e: mike.tutkow...@solidfire.com >> >>>>> o: 303.746.7302 >> >>>>> Advancing the way the world uses the cloud >> >>>>> <http://solidfire.com/solution/overview/?video=play>*™* >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> *Mike Tutkowski* >> >>>> *Senior CloudStack Developer, SolidFire Inc.* >> >>>> e: mike.tutkow...@solidfire.com >> >>>> o: 303.746.7302 >> >>>> Advancing the way the world uses the cloud >> >>>> <http://solidfire.com/solution/overview/?video=play>*™* >> >>> >> >>> >> >>> >> >>> -- >> >>> Daan >> >> >> >> >> >> >> >> -- >> >> Daan >> >> >> >> -- >> Daan > > > > > -- > Mike Tutkowski > Senior CloudStack Developer, SolidFire Inc. > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the cloud™ -- Daan
