#solum

datsun180b: you think this will only happen for halting env but not for destroy?

that's my theory, i'll have the results shortly

datsun180b: ok, I assume halt/destroy should not matter..once env is up rest of the process is same in both cases

well you have two errors arguing the opposite of that

in fact that line i added to install setuptools appears to be skipped anyway in a fresh install--pip just shrugs and says distribute is already satisfied

datsun180b: my guess is these errors will show up with destroy as well

they don't

i've destroyed/upped like four or five times just today

so before stack.sh the best freeze does is complain that it can't find an svn location for distribute==0.6.24dev-r0

datsun180b: ok, I dont' see any statements in vagrantfile that's specific to halt/destroy..any ideas on how they differ? if destroy/up is a cleaner, I will follow that from now onwards

well the difference is after a halt, all the things that were installed once are there

i'm betting that something devstack uses is pinning setuptools/distribute to an older version than what we had before

datsun180b: ok, if this don't happen with destroy/up then probably we don't have to fix this. This can happen later with other modules, may be in the doc we can say use destroy+up if halt+up fails with pkg error

well i would in general like to be able to successfully halt and up my environment

me destroying it is just a way of putting something off that may be as simple as just adding --upgrade in the right spot

i'm watching stack.sh do its thing and among other things it removes in inbuilt pip and drops in 1.4 in its place

morning

datsun180b: we may be able to fix this particular case but when stack.sh or solum adds new modules or changes module versions we may run into issues with halt again. May be we can add a test case to excercise halt+up scenario if we really want to support (probably low priority)

call it all maintenance i guess

A change was merged to stackforge/solum: Fix _delete_assembly in test_trigger_post functional test https://review.openstack.org/96189

oh i must have had the --take-forever flag on when i called stack.sh

haha :D

Invalid Registry endpoint: Get http://127.0.0.1:5042/v1/_ping: dial tcp 127.0.0.1:5042: connection refused

stack.sh is taking a lot of time to run today :|

ravips|lunch: ^^ how about that, looks like you were right

well 5/6 ain't bad

looks like destroying isn't as foolproof as i'd hoped either

datsun180b: hehe, similar situation here..destroyed my vm and its been 40mins, still waiting for provision to finish

did we get to some consensus re: pipeline/<other name> ?

I'll start with pipeline