On Tue, Oct 28, 2014 at 11:08:05PM +1300, Robert Collins wrote: > On 28 October 2014 22:51, Steven Hardy <sha...@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 _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev