Yes, thank you.
I'm not sure if the videos weren't posted when I checked, or if I may have
accidentally been looking at the Grizzly summit video listing. Either way,
they're now where they belong (as long as one looks in the right place).
Regards,
Eric Windisch
On Tuesday, May 21, 2013
missing, are those
project wrap-up talks given by the various PTLs.
Perhaps someone (Stefano?) knows if those videos might be available? Having
videos such as these available following Hong Kong will be all so much more
important for those that fail to make it.
Regards,
Eric Windisch
Extending the rules to those things of cultural or political significance
would have established precedence with the 'Grizzly exception'.
If such an exception were useful in naming this release, I'd suggest it
become a standard part of the naming scheme.
On May 10, 2013 6:40 AM, Matt Joyce
think I want
that message processed ever.
For what it is worth, Grizzly introduces TTLs for individual messages as
they're injected into RabbitMQ and Qpid. This was already the behavior for
ZeroMQ, in Folsom.
Regards,
Eric Windisch
___
Mailing
Is there a good reason there is no Android app published for ODS?
I've use the website on my phone in the past and it is okay, but not great.
I see there is an iOS app, but sched.org offers applications for both
ecosystems.
Regards,
Eric Windisch
On Thursday, April 11, 2013 at 18:54 PM, Stefano Maffulli wrote:
On Thu 11 Apr 2013 03:22:46 PM PDT, Eric Windisch wrote:
Is there a good reason there is no Android app published for ODS?
I have no idea... is there supposed to be one?
I use no app, I'm in the I can't stand apps phase
Someone has just informed me of the @OpenStack twitter feed which reads:
Coming to the Summit? Download the new iphone app! (Android coming soon)
awe.sm/dE87S (http://awe.sm/dE87S)
Case closed, I guess ;-)
Regards,
Eric Windisch
On Thursday, April 11, 2013 at 19:48 PM, Eric Windisch wrote
with doing HTTPS push. Someone on the QA team could comment
on whether or not it is worth providing support.
More information:
https://groups.google.com/d/msg/repo-discuss/7BXB_t7cHs8/KQ6TCLKYEh4J
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net
help them succeed, and especially for those
individually elected seats -- can bring them to together.
I am deeply committed to the success of OpenStack and to open source cloud. I
thank you for your consideration and ask that you please vote for me.
Regards,
Eric Windisch
of the box with ZeroMQ selected.
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
collateral consequences?
I generally advise not to do this due to potential security concerns.
In practice, your concerns will be with deleting manually created volumes and
creating volumes that match the pattern set in the nova-volumes/cinder
configuration.
Regards,
Eric Windisch
). Colliding with
artifacts of your own software is better than colliding with local operator
configurations and preferences.
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe
believe OpenStack should have its own OUI.
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
consumption pattern.
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
not necessarily remain valid in an evolving
architecture.
I believe that OpenStack requires leaders with experience 'in the trenches' of
operations, implementation, and of course, leadership. I ask for your trust,
and your votes, in this coming Technical Committee election.
Thank you,
Eric Windisch
into creating
user-space character devices. One could also make FUSE work with Unix sockets
as an alternative to character devices…
None of this is out of the box, tested, or even in existence...
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net
. However, I'm not too confident of libguestfs, but I understand why
it is attractive in absence of good userspace filesystem tools. Several have
pointed to mtools as one, and I'll also add debug2fs to this list, for those of
strong conviction.
Regards,
Eric Windisch
of emerging proprietary and/or
corporate-sponsored distributions, it would not do the community a favor for
the foundation to create its own.
Regards,
Eric Windisch
(sent from my iPad)___
Mailing list: https://launchpad.net/~openstack
Post
-compliant service
endpoint, enforced or not… and the client API libraries need to be flexible
enough to handle a variety of services that might not be 100% identical. Just
like the HTTP servers and client libraries that we have today.
Regards,
Eric Windisch
of this, including ignoring any need for testing before doing a
large rollout…
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More
of reading filesystems that were uploaded by users into
glance. However, it is essentially the same thing.
I don't think we need to do this and don't think we should do this. Clearly,
however, someone somewhere, at some point, thought they wanted this.
Regards,
Eric Windisch
. In Grizzly, we would make the
rpc_backend variable mandatory in the configuration.
Mark McLoughlin wisely suggested this come before the mailing list, as it will
affect a great many people. I welcome feedback and discussion.
Regards,
Eric Windisch
. It could have a soft-default, via a prompt on first-run
unless defined in the localrc, similar to how passwords are currently handled.
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack
technical blunder.
Per the summit discussion Etherpad:
injecting files into a guest is a very popular desire.
Popular desires not necessary smart desires. We should remove all file
injection post-haste.
Regards,
Eric Windisch
___
Mailing list: https
is entirely userspace and can be run with some
safety on the host.
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https
glance… I'm assuming these are probably ext2/3/4 or
other Linux filesystems. Libguestfs might be the best option, besides simply
not having that feature.
Regards,
Eric windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack
illusions of mounting the filesystem anywhere via the kernel or FUSE.
--
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help
securely, but it isn't.
--
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
response/hearbeat of service daemons.
I see. For some additional context, I'm looking to use this managing consumers
of round-robin and fanout queues with the ZeroMQ driver, instead of the static
hashmap that is used currently.
Regards,
Eric Windisch
of the changes that
have already landed, or are expected to land within Folsom.
Common contains essential pieces to the success of OpenStack which are
currently lacking (official) leadership. Everyone's problem is nobody's problem.
Consider this my +1 on assigning a PTL for common.
Regards,
Eric Windisch
, the intention is to leave the matchmaker in and introduce
the membership modules. Then, the matchmaker would either use the new
membership modules as a backend, or even replaced entirely.
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net
.
Regards,
Eric Windisch
def stop(self, server):
Stop the server.
return self._action('os-stop', server, None)
def start(self, server):
Start the server.
self._action('os-start', server, None)
def pause(self, server):
Pause the server
. I think he would also be a great addition to nova-core.
+1. I've read through the list and gerrit. Sean seems to be doing a great job.
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack
,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
On Wednesday, July 18, 2012 at 19:10 PM, Vishvananda Ishaya wrote:
Hello Everyone!
Yun has been putting a lot of effort into cleaning up our state management,
and has been contributing a lot to reviews[1]. I think he would make a great
addition to nova-core.
+1
Regards,
Eric Windisch
without race conditions. If
we're calling kpartx, platform independence is unlikely to be an issue anyway.
However, if compatibility is desired, BSD/MacOS provide similar functionality
via kqueue, and Windows FindFirstChangeNotification.
Regards,
Eric Windisch
from the perspective of the queue-server buffs.
Let me know when you're ready to have a chat about it, it might do better to do
this on the phone or IRC than by email.
--
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post
it is acceptable to cut the
nova-volume code out for folsom.
Finally something I can put a +1 against.
--
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net
and included when
you run update.py?
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
and would love to see it working again.
There were already bugs filed for this and changes already in gerrit for
review, that once committed, should fix the tests.
The bigger issue is getting people to do the reviews...
--
Eric Windisch
___
Mailing
The bigger issue is getting people to do the reviews...
Here is the link for those that want to help:
https://review.openstack.org/#/q/status:open+project:openstack/openstack-common+branch:master+topic:bug/1021459,n,z
Regards,
Eric Windisch
://review.openstack.org/#/q/status:open+project:openstack/openstack-common+branch:master+topic:bug/1021459,n,z
--
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net
is broken, that code
review is not bypassed. Additionally, if there is a reasonable way to approach
the author of code, especially if there is already a patch in review, that
opposing patches aren't shoe-horned in without review or oversight.
Regards,
Eric Windisch
to properly updated that code and *ensure*
compatibility in your project
Isn't this what we get with git submodules? Sure, that version is just a
commit-id (or tag), but it isn't tracking HEAD, either. For stable releases, we
can tag and update the reference to point to that tag.
--
Eric Windisch
,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
commits.
--
Eric Windisch
On Tuesday, July 3, 2012 at 15:47 PM, Andrew Bogott wrote:
On 7/3/12 1:59 PM, Gabriel Hurley wrote:
The notion that copying code is any protection against APIs that may change
is a red herring. It's the exact same effect as pegging a version of a
dependency
for __future__.
--
Eric Windisch
On Thursday, June 28, 2012 at 13:48 PM, Timothy Daly wrote:
nova has tools/hacking.py, which looks like it does check some import stuff,
among other things.
-tim
On Jun 28, 2012, at 10:15 AM, Joshua Harlow wrote:
Hi all,
I remember hearing once
across a relaunched caller)
Anyway, in the ZeroMQ driver, we could have a local queue to track casts and
remove them when the send() coroutine completes. This would provide restart
protection for casts.
--
Eric Windisch
On Tuesday, June 12, 2012 at 09:55 AM, Johannes Erdfelt wrote:
As part
the remaining timeout.
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
PUSH.
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
will be able to
sufficiently provide the necessary security backports and hotfixes.
For this reason, the support for stable releases of the kFreeBSD releases, in a
sense, may be considered significantly shortened compared to standard Debian
releases.
--
Eric Windisch
On Monday, June 11
What implementation suboption would have your preference ? Is
nova-rootwrap now universally used ? Should we prefer compatibility or
absence of confusion ?
There is an issue of how to extend rootwrap from third-party backend drivers.
If this was (is?) addressed, universal use of
/2.
I'm inclined to suggest option #2 as it is a relatively simple improvement that
would give us short-term gains without much friction. This wouldn't exclude the
other options from being worked on and seems to be a requirement for #3, anyway.
--
Eric Windisch
-executed. Without
having any 'sudo' requirements, the nova user would be quite constrained,
relative to the current situation.
--
Eric Windisch
On Tuesday, June 5, 2012 at 21:18 PM, Yun Mao wrote:
Python is a scripting language. To get setuid work, you usually have
to give the setuid
/7921/2 # matchmaker
https://review.openstack.org/#/c/7770/ # new common rpc tests and fake_impl.py
bugfix
--
Eric Windisch
On Wednesday, May 23, 2012 at 11:34 AM, Eric Windisch wrote:
Looking for code reviews of the ZeroMQ driver:
https://review.openstack.org/#/c/7633/
I believe I
the matchmaker lands (this
can provide client-side balancing of servers).
--
Eric Windisch
On Friday, May 25, 2012 at 09:18 AM, Stephen Gran wrote:
Hello,
I am investigating various high availability options for a pending
deploy of open stack. One of the obvious services to make resilient
. this would be a win for Qpid as well) I'm clearly not
a die-hard RabbitMQ admin -- is there a reason to use clustering over a
decoupled solution for a greenfield application?
--
Eric Windisch
On Friday, May 25, 2012 at 17:54 PM, Sébastien Han wrote:
Why don't you use the RabbitMQ builtin
tests
(and a bug-fix for nova/rpc/impl_fake.py)
--
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net
configuration is necessary,
if dynamic is truly required, and how a method like get_workers should behave
on a statically configured system.
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack
/ in Nova/OpenStack
long-term. Currently, RabbitMQ is the default, but Essex introduced Qpid
messaging, and we'll have ZeroMQ messaging if we can get it out of review ;-)
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post
Exception.
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
The nova rpc implementation is moving into openstack common, I agree with using
this abstraction.
As per ZeroMQ, I'm the author of that plugin. There is a downloadable plugin
for Essex and I'm preparing to make a Folsom merge prop within the next week or
so, if all goes well.
Sent from my
that
while the zeromq driver is the newest, it is the only driver that meets all of
the above requirements, except, to the exceptions marked above.
Improving the other implementations should be done, but I don't know of anyone
committed to that work.
Regards,
Eric Windisch
on
the unit tests. This is basically what 'fake_rabbit' is now, anyway.
Thoughts?
--
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More
, then add any flags we
want.
C. not support testing flags on RPC drivers, have a common testing flag.
--
Eric Windisch
On Friday, May 4, 2012 at 6:08 PM, Russell Bryant wrote:
On 05/04/2012 11:53 AM, Eric Windisch wrote:
Russell,
FYI, with the flags patch, it is no longer possible to set
I guess another question is, why do you need to set ZeroMQ related flags
in fake_flags? I think those should only be settings that apply for
*all* unit tests. I would just register your flags in your unit tests.
https://github.com/openstack/nova/blob/master/nova/tests/rpc/test_qpid.py#L69
be safer.
--
Eric Windisch
On Sunday, April 29, 2012 at 7:41 PM, Andrew Bogott wrote:
As part of the plugin framework, I'm thinking about facilities for
adding commands to the nova-rootwrap list without directly editing the
code in nova-rootwrap. This is, naturally, super dangerous; I'm worried
+1
--
Eric Windisch
On Friday, April 27, 2012 at 11:09 AM, Dan Prince wrote:
Russell Bryant wrote the Nova Qpid rpc implementation and is a member of the
Nova security team. He has been helping chipping away at reviews and
contributing to discussions for some time now.
I'd like
.
Additionally, each RPC driver can provide a guide to complying with their
protocol, which extends beyond simply the transport (i.e. AMQP or ZeroMQ). This
might be harder than it sounds and might vary between, or even within, releases.
--
Eric Windisch
On Wednesday, April 25, 2012 at 1:24 PM
Sure, but then the contract becomes between the notifier and the client,
presumably? I'm not as familiar with the notification system as I should be.
I haven't written a ZeroMQ notifier yet, figuring that task would be better
delayed until the move to openstack-common.
--
Eric Windisch
rather that a
dash or underscore was used here, if possible.
Then, the ZeroMQ driver would just work with the existing notifier by
implementing fanout_cast() for notify().
--
Eric Windisch
On Wednesday, April 25, 2012 at 6:23 PM, Monsyne Dragon wrote:
The notification system is simply
Actually, I think JSON schema for our message-bus messages might be a really
good idea (tm). Violations could just be warnings until we get things locked
down... maybe I should propose a blueprint? (Although I have enough of a
blueprint backlog as it is...)
Pickles, but only because there was a bug in Essex
at one point, breaking JSON serialization)
--
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net
be able to
refactor some of the stuff in ampq.py to be more generically useful (maybe).
Right now, none of that is a huge concern to me, we can get it integrated and
do the DRY later.
--
Eric Windisch
___
Mailing list: https://launchpad.net
the
internal apis directly. The RPC and database can be made to scale in Nova, but
a REST endpoint won't be as reliable or scale as well.
--
Eric Windisch
On Monday, April 23, 2012 at 11:15 AM, Justin Santa Barbara wrote:
What's the advantage of replacing the native EC2 compatibility layer
On Monday, April 23, 2012 at 3:42 PM, Justin Santa Barbara wrote:
I didn't realize people were willing to do so.
Ah yes, well, that problem might still remain. There are certainly seem to be
volunteers to work on the versioning code, but defining, tagging, and adhering
to API contracts
On Monday, April 23, 2012 at 4:00 PM, Joshua Harlow wrote:
Re: [Openstack] Canonical AWSOME How are REST endpoints not reliable or
scalable ;-)
I’d like to know, seeing as the web is built on them :-)
The resiliency of the internet is actually built on BGP. REST endpoints fall
over
Glance seems to advertise some OVF support.
--
Eric Windisch
On Tuesday, April 10, 2012 at 11:52 AM, Scott Moser wrote:
On Tue, 10 Apr 2012, Andrew Bogott wrote:
I'm reviving this ancient thread to ask: Will there be a code summit session
about this? And/or are there plans to start
config-drive. The EC2 metadata service must remain.
The EC2 API is intended to mimic EC2 behavior and provide compatibility. The
OpenStack implementations should not diverge or break that compatibility.
--
Eric Windisch
On Tuesday, April 10, 2012 at 2:05 PM, Justin Santa Barbara wrote:
Config
I agree that it is important to access the limitations of the OpenStack EC2 API
implementation.
To that end, make sure to take a look at
https://github.com/cloudscaling/aws-compat
--
Eric Windisch
On Tuesday, April 10, 2012 at 7:39 PM, Joshua Harlow wrote:
EC2 compat. Hi all,
I’ve
.
--
Eric Windisch
On Tuesday, April 10, 2012 at 8:30 PM, Eric Windisch wrote:
I agree that it is important to access the limitations of the OpenStack EC2
API implementation.
To that end, make sure to take a look at
https://github.com/cloudscaling/aws-compat
--
Eric Windisch
to be involved, if only as a reviewer to ensure the queue abstraction layer
makes it over safely. [I still question if we need an rpc.notify()…]
--
Eric Windisch
On Wednesday, March 14, 2012 at 5:19 AM, Juan Antonio García Lebrijo wrote:
Hi,
we are thinking to contribute to increase
. I've done quite
a bit of analysis of this requirement and it simply isn't necessary. There is
some need in AMQP for this due to implementation-specific issues, but not
necessarily unsolvable. However, these problems simply do not exist for all RPC
implementations...
--
Eric Windisch
of least resistance as
long as we're committed to eventlet.
--
Eric Windisch
On Thursday, March 1, 2012 at 3:36 PM, Vishvananda Ishaya wrote:
Yes it does. We actually tried to use a pool at diablo release and it was
very broken. There was discussion about moving over to a pure-python mysql
the community in potentially devastating ways.
--
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
with Russell Bryant and his helpful reviews
this morning to polish up for inclusion, if it can get the approvals.
--
Eric Windisch
On Tuesday, February 7, 2012 at 4:05 PM, Eric Windisch wrote:
The ZeroMQ RPC driver is now feature-complete. I'm cleaning up for a
merge-proposal
.
It might be an interesting exercise to provide log messages in two languages
(one always being English), if we don't simply standardize on English.
--
Eric Windisch
On Monday, February 13, 2012 at 12:50 PM, Joshua Harlow wrote:
Question on i8ln? Hi all,
I was just wondering if I could get
useful for debugging
purposes.
--
Eric Windisch
On Monday, February 13, 2012 at 1:15 PM, Joshua Harlow wrote:
Re: [Openstack] Question on i8ln? Sure but to contribute they have to
understand python which itself is english based??
I can understand for sys-ops people that can’t understand
. Developers will understand English,
but the operations and especially the support team may not. Having native
language log messages has the potential to significantly decrease support costs
for users both domestic and abroad (where domestic users might outsource
support).
--
Eric Windisch
ways...
--
Eric Windisch
On Monday, February 13, 2012 at 2:41 PM, Joshua Harlow wrote:
Re: [Openstack] Question on i8ln? Agreed, I do that as well.
But I’m also a biased yankee, now a californian (not hippie/ster yet, haha).
On 2/13/12 2:37 PM, Andrew Bogott abog...@wikimedia.org wrote
The ZeroMQ RPC driver is now feature-complete. I'm cleaning up for a
merge-proposal!
--
Eric Windisch___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More
protocol to manage this. Currently, data is simply pickled. Perhaps for
Folsom we can create a blueprint for the signing verification of messages.
--
Regards,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack
.
It would be interesting exercise to allow the ZeroMQ driver to defer back to
the Kombu or Qpid driver for those messages which must remain centralized.
--
Eric Windisch
On Wednesday, January 25, 2012 at 1:18 AM, Alexis Richardson wrote:
On Wed, Jan 25, 2012 at 4:46 AM, Eric Windisch e
, tomorrow if I'm smart, lucky, and the store doesn't sell out of
RedBull. A two week grace would give me a nice buffer.
Thanks,
Eric Windisch
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https
-MQ
--
Eric Windisch
On Tuesday, January 24, 2012 at 5:20 PM, Yun Mao wrote:
Hi I'm curious and unfamiliar with the subject. What's the benefit of
0MQ vs Kombu? Thanks,
Yun
On Tue, Jan 24, 2012 at 7:08 PM, Eric Windisch e...@cloudscaling.com
(mailto:e...@cloudscaling.com) wrote
On Tuesday, January 24, 2012 at 6:05 PM, Zhongyue Luo wrote:
I assume the messages will be delivered directly to the destination rather
than piling up on a queue server?
Although the blueprint doesn't specify this level of detail, the intention had
originally been to deliver a
and
applications, rather than how much memory is set aside for Nova / VMs. If you
had 8GB and wanted to give Nova 6GB, you would reserve 2GB for your host OS.
This is a soft limit, your OS will happily take more memory absent cgroup
support as aforementioned.
--
Eric Windisch
their smart
filers have edge-cases preventing or breaking the use of these features.
Regards,
Eric Windisch
e...@cloudscaling.com
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https
You're involved in the tgt project and it is the tgt project's purgative to
add features as seen fit, but are you sure that you want to support this
feature?
Major spell check fail: prerogative ;-)
Regards,
Eric Windisch
e...@cloudscaling.com
to me.
I really don't see at all how Swift-as-block-device relates at all to (storage)
snapshots, other than the fact that this makes it possible to use Swift with
dm-snapshot.
Regards,
Eric Windisch
e...@cloudscaling.com
___
Mailing list: https
1 - 100 of 102 matches
Mail list logo
