On 07/16/2013 06:19 PM, rob_hirschf...@dell.com wrote: > Sascha, > > I have concerns about making any core infrastructure changes in CB 1.x; > however, the actual risk and overhead a pretty small because those are highly > tested/stable components of Rails. While it does add some additional > overhead to Crowbar's Rails' server, it's pretty minimal and contained. > > Like any new behavior, this may have subtle side effects that we need to be > prepared to address; however, we've done this in CB2 and I do not remember > any major issues.
I agree that we want to avoid disruptive changes for CB 1.x as much as possible. Providing more capacity to the session store (with persistence as a side effect), shouldn't impact any other part of CB and testing didn't reveal anything so far. Personally, I really appreciate the peer reviews we've successfully established together and such discussions sparking out of them. More than any other means we've used before, this seems to help solving issues on the spot. Due to this, pebbles is shaping up very nicely and we're getting a lot done in such a short time. To me this looks like the ideal collaboration model for any future CB development. > -----Original Message----- > From: crowbar-bounces On Behalf Of Sascha Peilicke > Sent: Tuesday, July 16, 2013 3:18 AM > To: crowbar > Subject: [Crowbar] Session store issues > > Hi fellow crowbarians, > > recently I stumbled across a rather annoying issue with how currently (ab)use > the session store. I won't repeat what's discussed at [1], but it's > generating internal server errors (500), which are > > but the proposed solution would require using a persistent session store. I > thought sqlite would be the obvious choice since we don't have a real DB > setup this early (and we can't use the database barclamp). > This should introduce any performance / storage issues since we don't expect > many users to use the Crowbar UI in parallel ;-) > > Currently, there seem to exists some doubts about the (re)introduced database > dependency. However, this change would happen on pebbles and there's no > requirement to pull it into mesa (Dell's stable branch). > Alternatively, it could be guarded with platform=="suse" checks if that's > would be more acceptable. > > A totally different solution would be to not use the session store (through > Rails' flash messages) for error messages regarding raw proposal JSON or to > cut them mercilessly. However, errors in proposals are already hard to > interpret for users, so this doesn't seem ideal to me. > > But maybe I missed something totally obvious, so let's discuss. > > > [1] https://github.com/crowbar/barclamp-crowbar/pull/581 > [2] https://github.com/crowbar/crowbar/pull/1863 > -- > Sascha Peilicke > SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) > > _______________________________________________ > Crowbar mailing list > Crowbar@dell.com > https://lists.us.dell.com/mailman/listinfo/crowbar > For more information: http://crowbar.github.com/ > -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
