On 04/24/2013 02:12 PM, Dan Prince wrote: > > > ----- Original Message ----- >> From: "Monty Taylor" <[email protected]> >> To: [email protected] >> Sent: Wednesday, April 24, 2013 11:19:17 AM >> Subject: Re: [OpenStack-Infra] Talking is the first step. >> >> >> >> On 04/24/2013 11:07 AM, Brian Lamar wrote: >>> >>> On Apr 24, 2013, at 10:50 AM, Dan Prince <[email protected]> wrote: >>> >>>> >>>> ----- Original Message ----- >>>>> From: Brian Lamar <[email protected]> >>>> >>>>> So the question again becomes how can we get XenServer into the >>>>> gate. >>>> >>>> Hi Lamar, >>>> >>>> I understand there is a long term goal to move towards larger scale >>>> testing on bare metal w/ TripleO, etc. I'm very interested in that >>>> myself too. In the short/mid term however perhaps using SmokeStack >>>> (which supports testing multiple/flexible configurations) would >>>> help cover the scenario you described below via pre-gate testing? >>> >>> I knew I was missing something big when I had finished this email. >>> Absolutely. Maybe our first fight really is how we can get SmokeStack >>> (and thus XenServer testing) as part of the gate. >>> >>> My understanding is that the main gripe is that it needs to be easy >>> for people to see what failed and for them to have access to the >>> nodes to troubleshoot failures. Is this what is holding things back? > > >>> I'd love to get as many specifics as possible so we can work on >>> getting things integrated. This is probably a question for >>> Jim/Monty. >> >> There are a few issues around this: >> >> a) puppet/packages in the gate is a HUGE issue that we do not have a >> solution for yet > > Sure. This topic may warrant its own thread. But it does seem like any *more > realistic* 3rd party deployments may have the same sorts of problems that we > face with gating on puppet (which uses packages). Probably best to take this > offline.
Yah. Almost certainly its own topic. I had totally meant to grab beer with you at the summit and argue this one - but damn if I wasn't busy! >> b) reliability engineering - running the amount of tests that we run >> with the other system is a really big undertaking and there is a full >> time team of people working basically just on making it work. >> c) duplication of effort. This was the thing that made me yell at Dan >> originally - although I think we're friends now. But we don't want two >> things in the gate driving testing. We have zuul, and we have jenkins, >> and we add new features to them constantly to keep up with the needs of >> the gate. We don't want to add a second parallel system to a collection >> of tools that's already a huge undertaking to manage, because it would >> mean that everything we do to the zuul system would have to be >> duplicated in the non-zuul system. > > The focus of SmokeStack has really become pre-gate testing testing w/ > packages and config management. Find issues before they land (outside of the > scope of the gate). Because it isn't a gate we can be a bit more agile about > the configuration we run (while still being careful) and provide good > feedback to the community. If your goal is to gate things I do agree with the > gist of what Monty says above in that zuul is our gate. > > Gating issues aside I do want to clarify a couple of things lest I be seen as > someone who goes around duplicating CI things on the project by just reading > this thread: > > - SmokeStack was around before there even was a devstack gate or zuul. (The > openstack Jenkins did exist... but didn't cut it for me initially) > > - It is a big undertaking, I've been running a live system to test upstream > since Cactus. :) > > - Once upon a time I even maintained a job in the OpenStack Jenkins that > basically did the same thing a SmokeStack job does (w/ packages and config > mgmt). After feedback from the Diablo conference there wasn't really a "light > at the end of the tunnel" as far as making this job gating. For that matter > upstream packages seemed to be going out of style (we stopped maintaining the > upstream PPA's etc). > > So... SmokeStack still exists and I continue to find value in running 3rd > party configuration/testing with it. > > I'm not trying to dig up history or dwell on any of this. But I'm also not > trying to duplicate things and I do think SmokeStack might be useful for this > task in the short term being a bit more agile than our full gating solution. Totally - history and all. Certainly not trying to bring up past stuff. :) >> Now don't get me wrong - I think smokestack has been a very useful tool >> for the community and I think it's great that Dan has provided that >> service for the community. But if we were to "integrate" it in to the >> gate, I'd be much more interested in porting the things that it runs on >> machines to the system that the OpenStack project already runs. >> >> That still doesn't address the issues with adding packaging and config >> management to the gate though. >> >> If smokestack is useful to you to get started on this task, then by all >> means use it! But in terms of gating, I'd really like for us to engage >> in the hard work of meeting all of the requirements that are out there >> in a way that's integrated with the work that's already being done. > > Lamar: > > I do think SmokeStack could be useful in the short term for this. It is > probably less than a weeks worth of work to get these 4 machines upgraded to > XenServer 6.1 and then you'd have your pre-gate test results for the most > part. It is your call as to whether you think this is worth the effort. > > Mid-term: If we tease out the packages and config management pieces of what > I'm currently doing and replace it with whatever (Devstack or custom > shell/venv deployment solution), and then move that job into Jenkins/Zuul I > think you'll have your gate. > > Long-term: I'd love to see a fully automated bare metal solution. TripleO, > etc. I agree with all three of those. _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
