Open Stack

On Tue, Oct 28, 2014 at 11:08:05PM +1300, Robert Collins wrote:
> On 28 October 2014 22:51, Steven Hardy <shardy at redhat.com> wrote:
> > On Tue, Oct 28, 2014 at 03:22:36PM +1300, Robert Collins wrote:
> >> So this should work and I think its generally good.
> >>
> >> But - I'm curious, you only need a single image for devtest to
> >> experiment with tuskar - the seed - which should be about the same
> >> speed (or faster, if you have hot caches) than devstack, and you'll
> >> get Ironic and nodes registered so that the panels have stuff to show.
> >
> > TBH it's not so much about speed (although, for me, devstack is faster as
> > I've not yet mirrored all-the-things locally, I only have a squid cache),
> > it's about establishing a productive test/debug/hack/re-test workflow.
> 
> mm, squid-cache should still give pretty good results. If its not, bug
> time :). That said..
> 
> > I've been configuring devstack to create Ironic nodes FWIW, so that works
> > OK too.
> 
> Cool.
> 
> > It's entirely possible I'm missing some key information on how to compose
> > my images to be debug friendly, but here's my devtest frustration:
> >
> > 1. Run devtest to create seed + overcloud
> 
> If you're in dev-of-a-component cycle, I wouldn't do that. I'd run
> devtest_seed.sh only. The seed has everything on it, so the rest is
> waste (unless you need all the overcloud bits - in which case I'd
> still tune things - e.g. I'd degrade to single node, and I'd iterate
> on devtest_overcloud.sh, *not* on the full plumbing each time).

Yup, I went round a few iterations of those, e.g running devtest_overcloud
with -c so I could more quickly re-deploy, until I realized I could drive
heat directly, so I started doing that :)

Most of my investigations atm are around investigating Heat issues, or
testing new tripleo-heat-templates stuff, so I do need to spin up the
overcloud (and update it, which is where the fun really began ref bug 
#1383709 and #1384750 ...)

> > 2. Hit an issue, say a Heat bug (not that *those* ever happen! ;D)
> > 3. Log onto seed VM to debug the issue.  Discover there are no logs.
> 
> We should fix that - is there a bug open? Thats a fairly serious issue
> for debugging a deployment.

I've not yet raised one, as I wasn't sure if it was either by design, or if
I was missing some crucial element from my DiB config.

If you consider it a bug, I'll raise one and look into a fix.

> > 4. Restart the heat-engine logging somewhere
> > 5. Realize heat-engine isn't quite latest master
> > 6. Git pull heat, discover networking won't allow it
> 
> Ugh. Thats horrid. Is it a fedora thing? My seed here can git pull
> totally fine - I've depended heavily on that to debug various things
> over time.

Not yet dug into it in a lot of detail tbh, my other VMs can access the
internet fine so it may be something simple, I'll look into it.

> > 7. scp latest master from my laptop->VM
> > 8. setup.py install, discover the dependencies aren't all there
> 
> This one might be docs: heat is installed in a venv -
> /opt/stack/venvs/heat, so the deps be should in that, not in the
> global site-packages.

Aha, I did think that may be the case, but I'd already skipped to step (9)
by that point :D

> > 9. Give up and try to recreate issue on devstack
> 
> :)
> 
> > I'm aware there are probably solutions to all of these problems, but my
> > point is basically that devstack on my laptop already solves all of them,
> > so... maybe I can just use that?  That's my thinking, anyway.
> 
> Sure - its fine to use devstack. In fact, we don't *want* devtest to
> supplant devstack, they're solving different problems.
> 
> > E.g here's my tried, tested and comfortable workflow:
> >
> > 1. Run stack.sh on my laptop
> > 2. Do a heat stack-create
> > 3. Hit a problem, look at screen logs
> > 4. Fix problem, restart heat, re-test, git-review, done!
> >
> > I realize I'm swimming against the tide a bit here, so feel free to educate
> > me if there's an easier way to reduce the developer friction that exists
> > with devtest :)
> 
> Quite possibly there isn't. Some of your issues are ones we should not
> at all have, and I'd like to see those removed. But they are different
> tools for different scenarios, so I'd expect some impedance mismatch
> doing single-code-base-dev in a prod-deploy-context, and I only asked
> about the specifics to get a better understanding of whats up - I
> think its totally appropriate to be doing your main dev with devstack.

Ok, thanks for the confirmation - I'll report back if/when I get the full
overcloud working on devstack, given that it doesn't sound like a totally crazy
thing to spend a bit of time on :)

Steve