You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recent builds of the core/mongodb package are significantly larger than previous builds had been, which causes a number of unintended consequences that affect the national parks demo:
The time it takes to run a hab svc load core/mongodb can be quite long
Running the package in a local studio (particularly the docker studio on mac) can fail in a difficult to diagnose way -- the supervisor never starts the service or any constituent services until the supervisor is terminated and relaunched.
The second bullet here is the real killer -- particularly because it's inconsistent. Sometimes bumping the memory allocation to docker can fix it, and sometimes not.
As a short-term solution, @jvogt called out that pinning to an earlier release, particularly core/mongodb/3.2.10/20171016003652, solves this issue.
The problem is on the hab team's radar, but low priority. Recommend we update configs to use this release for the time being to make demo life more manageable.
The text was updated successfully, but these errors were encountered:
@ChefRycar have you started to use core/mongodb/3.2.10/20171016003652 when demoing NatParks? Could be a legit story, "When installing MongoDB into my studio I can specify the exact version that is running in prod..."
@smford22 I have not. I only became aware when I described weird behavior I experienced in my analyst demo, and he was able to suss out the culprit. Haven't poked at it too much since, but I could definitely see a story there.
@jvogt outside of avoiding the odd supervisor behavior, what kind of time savings are we talking vs. the latest package?
Also, is there an issue open for core-plans on this? Should probably reference it somewhere too if so.
@ChefRycar I have been testing today and it is significantly faster during the local dev story. Recently I had been doing demos by hab svc load core/mongodb before the demo began to cut time. With the version specified by @jvogt I can do that live again.
As for Terraform, there is a decent reduction in provision time as well. I will have a PR together shortly.
Recent builds of the
core/mongodb
package are significantly larger than previous builds had been, which causes a number of unintended consequences that affect the national parks demo:hab svc load core/mongodb
can be quite longThe second bullet here is the real killer -- particularly because it's inconsistent. Sometimes bumping the memory allocation to docker can fix it, and sometimes not.
As a short-term solution, @jvogt called out that pinning to an earlier release, particularly
core/mongodb/3.2.10/20171016003652
, solves this issue.The problem is on the hab team's radar, but low priority. Recommend we update configs to use this release for the time being to make demo life more manageable.
The text was updated successfully, but these errors were encountered: