, of course, is that users would not need
to contact the server using bay-show in order to obtain the UUID of their
bay.
Regards,
Eric Windisch
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
uniqueness (or as unique as UUID gets, anyway).
Regards,
Eric Windisch
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
in my free time.
I'll finish to say that I do think it's finally time to consider pulling it
back it. While doing so may not attract contributors, I know being in
stackforge has certainly been a deterrent both potential contributors and
users.
Regards,
Eric Windisch
From my experience, making fast moving changes is far easier when code is
split out. Changes occur too slowly when integrated.
I'd be +1 on splitting the code out. I expect you will get more done this
way.
Regards,
Eric Windisch
driver...
7. Need more technical documentation on the driver like [6].
I'm willing to prepare a current driver architecture overview with some
graphics UML charts, and to continue discuss the driver architecture.
Documentation has always been a sore point. +2
--
Regards,
Eric Windisch
ᐧ
conundrums and simplify principle of least privilege.
Regards,
Eric Windisch
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
, the Docker backend would work with both single docker hosts and
clusters of Docker machines powered by Swarm. It would be nice, however, if
scheduler hints could be passed from Magnum to Swarm.
Regards,
Eric Windisch
that made this possible!
Regards,
Eric Windisch
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman
are breaking
without manually checking Kibana, such as an email.
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I think for this cycle we really do need to focus on consolidating and
testing the existing driver design and fixing up the biggest
deficiency (1) before we consider moving forward with lots of new
+1
1) Outbound messaging connection re-use - right now every outbound
messaging creates
testing.
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
improves, or support in consuming projects and/or
oslo.messaging itself improves. I'd suggest that effort is better spent
there than building new bespoke tests.
Thanks and good luck! :)
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev
for a static configuration,
making tempest tests much easier to run and generally easier for anyone to
deploy, but it's intended to be an example of hooking into an inventory
service, not necessarily the defacto solution.
--
Regards,
Eric Windisch
___
OpenStack
up testing will be, in my opinion, better for any new
maintainers and users of this driver.
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
be useful for making sure that changes in the
upstream project doesn't break drivers, or that breakages could at least
invoke action by the driver team:
https://github.com/openstack/nova/blob/4ce3f55d169290015063131134f93fca236807ed/nova/tests/virt/test_ironic_api_contracts.py
--
Regards,
Eric
and having our own core team would be beneficial, but I wouldn't want
to do this unless it applied equally to all drivers.
--
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
On Tue, Aug 26, 2014 at 3:35 PM, Martinx - ジェームズ thiagocmarti...@gmail.com
wrote:
Hey Stackers! Wait! =)
Let me ask something...
Why are you guys using Docker within a VM?!?! What is the point of doing
such thing?!
I thought Docker was here to entirely replace the virtualization layer,
an environment similar to openstack-infra that can consistently
and reliably run on one's laptop, while bringing a devstack-managed
OpenStack installation online in 5-8 minutes.
Like other devstack-based installs, this is not for running production
OpenStack deployments.
--
Regards,
Eric Windisch
of the Linux containers features are disabled for
one reason or another.
--
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
of Nova more meaningful and would be a boon for Nova
security overall.
--
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
(and possibly write) plugins for
libswarm/swarmd to provide your scheduling. Your docker_endpoint would be
the IP/port of swarmd, and it would proxy those requests to the correct
backend Docker hosts.
--
Regards,
Eric Windisch
___
OpenStack-dev mailing list
at least one wikipage so far, it is far easier
if folks simply employ the correct usage from the beginning.
On wiki pages and other published medium -- absolutely.
For our daily use in IRC and other casual discussion? Lets not get pedantic.
--
Regards,
Eric Windisch
Given resource concerns, maybe just adding it to the experimental
pipeline would be sufficient?
For clarity, the discussed patch is to promote an existing experimental job
to silent.
Regards -Eric
___
OpenStack-dev mailing list
and usable from Docker.
The Heat plugin allow settings the CMD as a resource property. The
user-data is only passed to the instance that runs Docker, not the
containers. Configuring the CMD and/or environment variables for the
container is the correct approach.
--
Regards,
Eric Windisch
candidates for 3rd-party CI.
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Wed, Jul 16, 2014 at 12:55 PM, Roman Bogorodskiy
rbogorods...@mirantis.com wrote:
Eric Windisch wrote:
This thread highlights more deeply the problems for the FreeBSD folks.
First, I still disagree with the recommendation that they contribute to
libvirt. It's a classic example
to last
week's addition of the containers breakout room.
I suspect other containers-oriented folks might yet want to register. If
so, I think now would be the time to speak up.
--
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev
provides a certain awareness to the
container of the existence of that volume. It allows the container to
ATTEMPT to perform a mount operation, even if its denied by policy. That,
of course, is where seccomp would come into play...
--
Regards,
Eric Windisch
in
userspace.
References:
*
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/prctl/seccomp_filter.txt?id=HEAD
* http://chdir.org/~nico/seccomp-nurse/
--
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev
with the presumption there is value in having access to block
devices without filesystems, but that there would be additional utility
should we have a viable story for mounting filesystems.
--
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev
'software config' as I should be, although I attended a couple sessions on
it last week. I'm not sure how this solves the problem? Is the plan to have
the software-config-agent communicate over the network to/from Heat, and to
the instance's local unix socket?
--
Regards,
Eric Windisch
it on 0.8.1. I'll be updating the Dockerfile
and testing it throughly with the latest Docker release once we merge the
devstack patches.
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
What I hope to do is setup a check doing CI on devstack-f20 nodes[3],
this will setup a devstack based nova with the nova-docker driver and
can then run what ever tests make sense (currently only a minimal test,
Eric I believe you were looking at tempest support maybe it could be
hooked in
not
consolidate these into a single solution that is always fast for everyone,
all the time? Something used in dev and gating? Something that might reduce
the costs for running openstack-infra? That's what dockenstack is.
--
Regards,
Eric Windisch
variables in
devstack).
--
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
overlapped with the existing v2 failures. I'm not sure how
Russell or the community feels about skipping Tempest tests for v3, and I
would like to try making these pass, but I presently see it as lower
priority versus making v2 work and pass.
--
Regards,
Eric Windisch
of the container would be able to route correctly to the host and reach
the services.
Swapnil, try adding a value for HOST_IP into your localrc, matching your
machine's IP address.
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev
to 127.0.0.1 as the error that is received currently is certainty not
obvious enough.
--
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
, but wish
to confirm that this matches the error you're seeing.
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
don't expect it to be an issue. The monkey-patching
will cause eventlet.spawn to be called for threading.Thread. The code looks
eventlet-friendly enough on the surface. Error handing around file
read/write could be affected, but it also looks fine.
--
Regards,
Eric Windisch
and reproduce this myself.
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
docker-registry, or stopping it if it
is already running.
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
should take this off the developer list which is not for usage questions
(those usually go to the general list, operator list, or Ask OpenStack)
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org
and process, while not perfect, isn't
too dysfunctional. Attempting to move the EC2 or GCE code into a
Stackforge repository might kill them before they can reach that bar
you're looking to set.
What more is needed from the blueprint or the patch authors to proceed?
--
Regards,
Eric Windisch
offerings improvements and feature requests for
oslo.messaging.
--
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman kra...@gmail.com wrote:
Reminder: We are meting in about 15 minutes on #openstack-meeting channel.
I wasn't able to make it. Was meeting-bot triggered? Is there a log of
today's discussion?
Thank you,
Eric Windisch
stiffen innovation around
hypervisor-based virtualization. That isn't necessarily a bad thing,
it will help maintain stability in the project. However, the choice
and the implications shouldn't be ignored.
--
Regards,
Eric Windisch
___
OpenStack-dev mailing
.
--
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
as
standalone libraries. For these, it might make sense to aggressively
consider rolling some modules together?
One clear example would be log.py and log_handler.py, another would be
periodic_task.py and loopingcall.py
--
Regards,
Eric Windisch
___
OpenStack
of session.py. This
session management code is probably what you'll most have to decide is
worthwhile bringing in and if Glance really has such unique
requirements that it needs to bother with maintaining this code on its
own.
--
Regards,
Eric Windisch
here is we should be following the
principle of ask forgiveness, not permission. Try Python 3 and then
fallback to Python 2 whenever possible.
--
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
. These are private methods.
They can be broken for external consumers of these methods, because there
shouldn't be any. It will be a good lesson to anyone that tries to abuse
private methods.
--
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev
updating all the existing method calls that exist in
amqp.py, impl_kombu.py, and impl_qpid.py.
--
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
53 matches
Mail list logo
