Code review comment for lp:~wallyworld/juju-core/fix-instance-type-matching
Revision history for this message
| Ian Booth (wallyworld) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
Please take a look.
https:/
File environs/
https:/
environs/
with largest available memory was returned even if it didn't
On 2014/02/10 08:27:13, dimitern wrote:
> I don't think we need to explain how it was previously.
Done.
https:/
environs/
with largest available memory was returned even if it didn't
On 2014/02/10 08:27:13, dimitern wrote:
> I don't think we need to explain how it was previously.
Done.
https:/
environs/
On 2014/02/10 08:27:13, dimitern wrote:
> Why not just:
> cons.Mem = uint64(
> ?
Yeah, i refactored some stuff and left it in a bad state. Fixed. It does
need to be a pointer but there's no need for the intermediate object.
https:/
File environs/
https:/
environs/
specified, use that even though less than needed for mongodb",
On 2014/02/10 08:27:13, dimitern wrote:
> I think if the user overrode our minimum memory heuristic, we should
at least
> print out a warning, saying bootstrap might fail due to insufficient
memory for
> mongo.
Not sure about that. The user could also specify poorly speced systems
for charms and we don't emit anything there. This behaviour, allowing
the user to specify small memory, is not new - the tests are just being
improved. We have never in the past emitted a warning AFAIK.
https:/