Le 14/10/2014 01:46, Adam Lawson a écrit :
/I think Adam is talking about this bp:
https://blueprints.launchpad.net/nova/+spec/evacuate-instance-automatically/
Correct - yes. Sorry about that. ; )
So it would seem the question is not whether to support auto-evac but
how it should be
I was reminded that scapy is under GPLv2 license so we cannot make it as
the dependency of Neutron.
There are also some IPv6 utilities from ryu.lib.packet which can be
leveraged to send out neighbor advertisement. Is it OK to make ryu as a
dependency and make this as a binary and call it from
+1
Aleksey Kasatkin
Hi everyone!
>
> I would like to propose Igor Kalnitsky as a core reviewer on the
> Fuel-web team. Igor has been working on openstack patching,
> nailgun, fuel upgrade and provided a lot of good reviews [1]. In
> addition he's also very active in IRC and mailing list.
>
> Can
Jay Pipes wrote:
> On 10/13/2014 07:11 PM, Christopher Yeoh wrote:
>> I guess we could also start fleshing out in the repo how we'll work in
>> practice too (eg once the document is stable what process do we have
>> for making changes - two +2's is probably not adequate for something
>> like this).
Hi Everyone,
I have submitted a blueprint which targets the issues end-users are faces when
they are using Horizon in the old browsers. So, this blueprint targets to
overcome this problem by showing a small message on the Horizon login page.
I urge to all the Horizon community to take a look and
Hi everyone,
As outlined in the "Remove merge.py"[1] spec, Peter Belanyi and I have
built the templates for controller, nova compute, swift and cinder nodes
that can be deploying directly to Heat (i.e. no merge.py pass is necessary).
The patches:
https://review.openstack.org/#/c/123100/
http
On 14/10/2014 01:25, Nathan Kinder wrote:
>
>
> On 10/13/2014 01:17 PM, Morgan Fainberg wrote:
>> Description of the problem: Without attempting an action on an
>> endpoint with a current scoped token, it is impossible to know what
>> actions are available to a user.
>>
This is not unusual in
On 2014年10月14日 12:52, Christopher Yeoh wrote:
On Mon, 13 Oct 2014 22:20:32 -0400
Jay Pipes wrote:
On 10/13/2014 07:11 PM, Christopher Yeoh wrote:
On Mon, 13 Oct 2014 10:52:26 -0400
Jay Pipes wrote:
On 10/10/2014 02:05 AM, Christopher Yeoh wrote:
I agree with what you've written on the wik
On 10/14/2014 07:03 AM, Ian Wienand wrote:
> 1) changes for auto-detection. IMO, we should drop all these and just
>leave bashate as taking a list of files to check, and let
>test-harnesses fix it. Everyone using it at the moment seems fine
>without them
I am fine with this and aband
Hi Salvatore,
I like to propose a blueprint for the next Neutron release that permits to
dedicated an external network to a tenant. For that I though to rethink the
he conjunction of the two attributes `shared`
and `router:external' of the network resource.
I saw that you already initiate a work
On 10 Oct 2014, at 11:35, Vladimir Kuklin wrote:
> Hi, Fuelers
>
> As you may have noticed our project is growing continuously. And this imposes
> a requirement of increasing amount of core reviewers. I would like to propose
> Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core rev
On Tue, Oct 14, 2014 at 10:55:30AM +0200, Tomas Sedovic wrote:
> Hi everyone,
>
> As outlined in the "Remove merge.py"[1] spec, Peter Belanyi and I have built
> the templates for controller, nova compute, swift and cinder nodes that can
> be deploying directly to Heat (i.e. no merge.py pass is nec
On Tue, 14 Oct 2014, Angus Lees wrote:
2. I think we should separate out "run the server" from "do once-off setup".
Yes! Otherwise it feels like the entire point of using containers
and dockerfiles is rather lost.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cden
Thanks all.
Bogdan, Sergii - you were given +2 rights.
To merge the patch, you should do +2 and "+1 Approved" in gerrit.
On Tue, Oct 14, 2014 at 2:35 PM, Tomasz Napierala
wrote:
> On 10 Oct 2014, at 11:35, Vladimir Kuklin wrote:
>
> > Hi, Fuelers
> >
> > As you may have noticed our project is g
Forward to dev list for more discussion
-- Forwarded message --
From: Yaguang Tang
Date: Thu, Oct 9, 2014 at 10:32 AM
Subject: console.log grows indefinitely issue
To: "openst...@lists.openstack.org"
Hi all,
Here is a known issue for a long time
https://bugs.launchpad.net/nova
On 10/14/2014 12:43 PM, Steven Hardy wrote:
On Tue, Oct 14, 2014 at 10:55:30AM +0200, Tomas Sedovic wrote:
Hi everyone,
As outlined in the "Remove merge.py"[1] spec, Peter Belanyi and I have built
the templates for controller, nova compute, swift and cinder nodes that can
be deploying directly
Hi,
I am really in favor of this. The implementation looks great! Nova can
surely benefit from this and we can make Neutron allocations at the API
level and save a ton of complexity at the compute level.
Kudos!
Thanks
Gary
On 10/13/14, 11:31 PM, "Chuck Carlino" wrote:
>Hi,
>
>Is anyone working o
The QA and Documentation teams have adopted a liaison program similar to what
we did for Oslo during Juno. That means we need to provide someone from our
team to work with each of their teams. If you would like to volunteer for one
of the positions, put your name in the appropriate table on the
Hi crew,
Thank you very much to all of you. It's a honor to be "Core" in
fuel-library.
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
On Tue, Oct 14, 2014 at 1:02 PM, Mike Scherbakov
wrote:
> Thanks all.
> Bogdan, Sergii - you were given +2 rights.
> To merge the patch, you sh
On 10/14/2014 04:55 AM, Tomas Sedovic wrote:
Hi everyone,
As outlined in the "Remove merge.py"[1] spec, Peter Belanyi and I have
built the templates for controller, nova compute, swift and cinder nodes
that can be deploying directly to Heat (i.e. no merge.py pass is
necessary).
The patches:
On 10/14/2014 12:52 AM, Christopher Yeoh wrote:
On Mon, 13 Oct 2014 22:20:32 -0400
Jay Pipes wrote:
On 10/13/2014 07:11 PM, Christopher Yeoh wrote:
On Mon, 13 Oct 2014 10:52:26 -0400
Jay Pipes wrote:
On 10/10/2014 02:05 AM, Christopher Yeoh wrote:
I agree with what you've written on the w
Maybe this: https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/306693
Might want to manually fix runlevels to be 0 and 6 (not 1) using update-rc.d.
You can look at the LSB headers (comments at top of init script) in /etc.
On 10/11/14, 12:58 PM, "Nitika"
mailto:nitikaagarwa...@gmail.com>
On 10/14/2014 05:04 AM, Alex Xu wrote:
There is one reason to think about what projects *currently* do. When we
choice which convention we want.
For example, the CamelCase and snake_case, if the most project use
snake_case, then choice snake_case style
will be the right.
I would posit that the
Hi All,
Some of us are travelling this week so we'll need to cancel the hyper-v meeting
for today.
We will resume next week at the usual time.
p
Peter J. Pouliot CISSP
Sr. SDET OpenStack
Microsoft
New England Research & Development Center
1 Memorial Drive
Cambridge, MA 02142
P: 1.(857).4536436
First, some truth in advertising: I work on Congress (policy as a service), so
I’ve mostly given thought to this problem in that context.
1) I agree with the discussion below about creating a token that encodes all
the permitted actions for the user. The cons seem substantial.
(i) The token
On Tue, Oct 14, 2014 at 02:51:15PM +1100, Angus Lees wrote:
> 1. It would be good if the "interesting" code came from python sdist/bdists
> rather than rpms.
I agree in principal, although starting from packages right now lets
us ignore a whole host of issues. Possibly we'll hit that change down
Angus,
On 10/13/2014 08:51 PM, Angus Lees wrote:
I've been reading a bunch of the existing Dockerfiles, and I have two humble
requests:
1. It would be good if the "interesting" code came from python sdist/bdists
rather than rpms.
This will make it possible to rebuild the containers using code
On Oct 14, 2014, at 8:57 AM, Jay Pipes wrote:
> I personally think proposing patches to an openstack-api repository is the
> most effective way to make those proposals. Etherpads and wiki pages are fine
> for dumping content, but IMO, we don't need to dump content -- we already
> have plenty o
I found a couple of free times available for a weekly meeting if people are
interested:
https://review.openstack.org/#/c/128332/2
Not sure if a meeting time has been hashed out already or not, and if it
has I'll change the patch accordingly. If not, we can iterate on possible
meeting times in the
Hello everyone,
Due to two last-minute issues discovered in testing the published
Ceilometer 2014.2 RC2, we generated a new Juno release candidate. You
can find the list of bugfixes in this RC and a link to a source tarball at:
https://launchpad.net/ceilometer/juno/juno-rc3
At this point, only s
Hi everyone,
Inspired by the travels tips published for the HK summit, the French
OpenStack user group wrote a similar wiki page for Paris:
https://wiki.openstack.org/wiki/Summit/Kilo/Travel_Tips
Also note that if you want some local informations or want to talk about
user groups during
This came up briefly on the meeting yesterday, but I wanted to bring
it to a wider audience.
I know some folks out there are using the Heat templates I put
together for setting up a simple kubernetes environment. I have
recently added support for the Gluster shared filesystem; you'll find
it in t
Nice diagrams. :-) Thanks. Susanne
On Mon, Oct 13, 2014 at 4:18 PM, Phillip Toohill <
phillip.tooh...@rackspace.com> wrote:
> Diagrams in jpeg format..
>
> On 10/12/14 10:06 PM, "Phillip Toohill"
> wrote:
>
> >Hello all,
> >
> >Heres some additional diagrams and docs. Not incredibly detailed, bu
Absolutely this needs splitting out. I ran into an issue a few years ago with
this antipattern with the mythtv folks. The myth client on my laptop got
upgraded and it was overly helpful in that it connected directly to the
database and upgraded the schema for me, breaking the server, and all the
Hi,
When I have "OVS_PHYSICAL_BRIDGE=br-p1p1” defined in localrc, devstack creates
the OVS bridge "br-p1p1".
localadmin@qa4:~/devstack$ sudo ovs-vsctl show
5f845d2e-9647-47f2-b92d-139f6faaf39e
Bridge "br-p1p1" <
Port "phy-br-p1p1"
Interface "phy-br-p1p1"
I'm not sure User Agent detection is the best way to go.
Suppose you do UA sniffing and say "show the message unless the UA is one of
X". Then, if there's a browser which fully supports your feature set, but
doesn't have a known UA (or someone set a custom UA on their browser), the
message wil
On 10/14/2014 11:35 AM, Adrien Cunin wrote:
> Hi everyone,
>
> Inspired by the travels tips published for the HK summit, the
> French OpenStack user group wrote a similar wiki page for Paris:
>
> https://wiki.openstack.org/wiki/Summit/Kilo/Travel_Tips
>
> Also note that if you want some local in
On 10/14/14, 10:22 AM, "Everett Toews" wrote:
>On Oct 14, 2014, at 8:57 AM, Jay Pipes wrote:
>
>> I personally think proposing patches to an openstack-api repository is
>>the most effective way to make those proposals. Etherpads and wiki pages
>>are fine for dumping content, but IMO, we don't
Hi Doug,
do you know if the existing quota oslo-incubator module has already some
active consumers?
In the meanwhile I've pushed a spec to neutron-specs for improving quota
management there [1]
Now, I can either work on the oslo-incubator module and leverage it in
Neutron, or develop the quota mo
Hi Solly,
You are right with your questions about user setting custom UA on their
browser. And during my discussion with other Horizon community members on IRC,
we decided that Horizon should not care about user setting custom UA on for
their browser because it is not our job to identify that a
On 10/14/2014 10:49 AM, Lars Kellogg-Stedman wrote:
On Tue, Oct 14, 2014 at 02:51:15PM +1100, Angus Lees wrote:
1. It would be good if the "interesting" code came from python sdist/bdists
rather than rpms.
I agree in principal, although starting from packages right now lets
us ignore a whole h
Le 14/10/2014 18:29, Anita Kuno a écrit :
On 10/14/2014 11:35 AM, Adrien Cunin wrote:
Hi everyone,
Inspired by the travels tips published for the HK summit, the
French OpenStack user group wrote a similar wiki page for Paris:
https://wiki.openstack.org/wiki/Summit/Kilo/Travel_Tips
Also note
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/14/2014 10:22 AM, Everett Toews wrote:
>> I personally think proposing patches to an openstack-api repository is the
>> most effective way to make those proposals. Etherpads and wiki pages are
>> fine for dumping content, but IMO, we don't need
On 10/13/2014 05:59 PM, Russell Bryant wrote:
Nice timing. I was working on a blog post on this topic.
On 10/13/2014 05:40 PM, Fei Long Wang wrote:
I think Adam is talking about this bp:
https://blueprints.launchpad.net/nova/+spec/evacuate-instance-automatically
For now, we're using Nagios pr
The blueprint was untargeted mostly because the analysis indicated that
there was no easy solution, and that what we needed was a solution to do
some RBAC on neutron resources.
I think this would be a good addition to the Neutron resource model, and it
would be great if you could start the discuss
On 10/14/2014 12:40 PM, Sylvain Bauza wrote:
>
> Le 14/10/2014 18:29, Anita Kuno a écrit :
>> On 10/14/2014 11:35 AM, Adrien Cunin wrote:
>>> Hi everyone,
>>>
>>> Inspired by the travels tips published for the HK summit, the
>>> French OpenStack user group wrote a similar wiki page for Paris:
>>>
On 10/14/2014 07:42 AM, Tim Hinrichs wrote:
> First, some truth in advertising: I work on Congress (policy as a service),
> so I’ve mostly given thought to this problem in that context.
>
> 1) I agree with the discussion below about creating a token that encodes all
> the permitted actions for
Hi all,
I have been experimenting a lot with Heat software config to check out
what works today, and to think about potential next steps.
I've also worked on an internal project where we are leveraging software
config as of the Icehouse release.
I think what we can do now from a user's perspect
Adding yesterday discussion of JS libs for unit-testing in
#openstack-horizon: http://paste2.org/B9xN1yI4
On Mon, Oct 13, 2014 at 5:01 PM, Timur Sufiev wrote:
> Hello folks!
>
> Discussing the proposed Sinon.js dependency to Horizon on the last meeting
> has brought quite an expected question: w
On Tue, Oct 14, 2014 at 01:27:20PM +0200, Tomas Sedovic wrote:
> On 10/14/2014 12:43 PM, Steven Hardy wrote:
> >On Tue, Oct 14, 2014 at 10:55:30AM +0200, Tomas Sedovic wrote:
> >>Hi everyone,
> >>
> >>As outlined in the "Remove merge.py"[1] spec, Peter Belanyi and I have built
> >>the templates for
On Tue, Oct 14, 2014 at 12:33:42PM -0400, Jay Pipes wrote:
> Can I use your Dockerfiles to build Ubuntu/Debian images instead of only
> Fedora images?
Not easily, no.
> Seems to me that the image-based Docker system makes the
> resulting container quite brittle -- since a) you can't use configura
On Tuesday, October 14, 2014, Nathan Kinder wrote:
>
>
> On 10/14/2014 07:42 AM, Tim Hinrichs wrote:
> > First, some truth in advertising: I work on Congress (policy as a
> service), so I’ve mostly given thought to this problem in that context.
> >
> > 1) I agree with the discussion below about c
Hi, We are meeting in the #openstack-gbp channel today (10/14) 18.00 UTC to
jointly review some of the pending patches:
https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy+branch:master,n,z
Please join if you would like to provide feedback.
Thanks,
~Sumit.
Excerpts from Tomas Sedovic's message of 2014-10-14 08:55:30 +:
> James Slagle proposed something like this when I talked to him on IRC:
>
> 1. teach devtest about the new templates, driven by a
> OVERCLOUD_USE_MERGE_PY switch (defaulting to the merge.py-based templates)
> 2. Do a CI run of t
Hi,
Across these private External network/tenant :: floating IP can be shared ?
Keshava
From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Tuesday, October 14, 2014 10:33 PM
To: Édouard Thuleau
Cc: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [neutron] Private externa
Hi,
I used devstack to deploy multi-node OpenStack, with Controller + nova-compute
+ Network on one physical node (qa4),
and Compute on a separate physical node (qa5).
When I launch a VM which spun up on the Compute node (qa5), I cannot launch the
VM console, in both CLI and Horizon.
localadm
There is a specs/kilo directory [1] available now. I will be doing
plenty of reviewing and organizing this week! Please keep in mind of
stable priorities as you're proposing things [2].
--
Mike Perez
[1] - https://github.com/openstack/cinder-specs/tree/master/specs/kilo
[2] - https://etherpad.ope
On 10/13/2014 06:21 PM, Preston L. Bannister wrote:
Too-short token expiration times are one of my concerns, in my current
exercise.
Working on a replacement for Nova backup. Basically creating backups
jobs, writing the jobs into a queue, with a background worker that
reads jobs from the queu
Sure, feel free to put my response in the Blueprint page. Thanks for the quick
answer.
Best Regards,
Solly Ross
- Original Message -
> From: "Nikunj Aggarwal"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Cc: sr...@redhat.com
> Sent: Tuesday, October 14, 20
On 10/14/2014 01:13 PM, Thomas Spatzier wrote:
>
> Hi all,
>
> I have been experimenting a lot with Heat software config to check out
> what works today, and to think about potential next steps.
> I've also worked on an internal project where we are leveraging software
> config as of the Iceho
On 10/14/2014 01:28 PM, Lars Kellogg-Stedman wrote:
On Tue, Oct 14, 2014 at 12:33:42PM -0400, Jay Pipes wrote:
Can I use your Dockerfiles to build Ubuntu/Debian images instead of only
Fedora images?
Not easily, no.
Seems to me that the image-based Docker system makes the
resulting container
That was really helpful background. Thanks!
I’d be happy to look into using Congress to implement what we’ve discussed:
caching policy.json files, updating them periodically, and answering queries
about the roles required to be granted access to a certain kind of action. I
think we have the r
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: 14 October 2014 19:01
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] Automatic evacuate
>
> On 10/13/2014 05:59 PM, Russell Bryant wrote:
> > Nice timing. I was working on a blog post
+1 for doing now:
> we are going to implement something really simple, like updating plugin
attributes directly via api.
Then we can have discussions in parallel how we plan to evolve it.
Please confirm that we went this path.
Thanks,
On Mon, Oct 13, 2014 at 7:31 PM, Evgeniy L wrote:
> Hi,
>
On 10/14/2014 01:01 PM, Jay Pipes wrote:
>> 2) Looking forward, there is a lot of demand for doing this on a per
>> instance basis. We should decide on a best practice for allowing end
>> users to indicate whether they would like their VMs automatically
>> rescued by the infrastructure, or just le
On 2014-10-14 2:49 PM, Tim Bell wrote:
Nova is also not the right place to do the generic solution as many other parts
could be involved... neutron and cinder come to mind. Nova needs to provide the
basic functions but it needs something outside to make it all happen
transparently.
I would r
On Tue, Oct 14, 2014 at 02:45:30PM -0400, Jay Pipes wrote:
> With Docker, you are limited to the operating system of whatever the image
> uses.
See, that's the part I disagree with. What I was saying about ansible
and puppet in my email is that I think the right thing to do is take
advantage of t
There are two distinct permissions to be managed:
1. What can the user do.
2. What actions can this token be used to do.
2. is a subset of 1.
Just because I, Adam Young, have the ability to destroy the golden image
I have up on glance does not mean that I want to delegate that ability
ever
On 10/14/2014 03:10 PM, Lars Kellogg-Stedman wrote:
On Tue, Oct 14, 2014 at 02:45:30PM -0400, Jay Pipes wrote:
With Docker, you are limited to the operating system of whatever the image
uses.
See, that's the part I disagree with. What I was saying about ansible
and puppet in my email is that
On Tue, 14 Oct 2014, Jay Pipes wrote:
This means you now have to know the system administrative comments and setup
for two operating systems ... or go find a Fedora20 image for mysql
somewhere.
For sake of conversation and devil's advocacy let me ask, in
response to this paragraph, "why [do y
Same thing works with cloud init too...
I've been waiting on systemd working inside a container for a while. it seems
to work now.
The idea being its hard to write a shell script to get everything up and
running with all the interactions that may need to happen. The init system's
already desi
On Tue, Oct 14, 2014 at 03:25:56PM -0400, Jay Pipes wrote:
> I think the above strategy is spot on. Unfortunately, that's not how the
> Docker ecosystem works.
I'm not sure I agree here, but again nobody is forcing you to use this
tool.
> operating system that the image is built for. I see you di
On 10/14/2014 03:50 PM, Lars Kellogg-Stedman wrote:
On Tue, Oct 14, 2014 at 03:25:56PM -0400, Jay Pipes wrote:
I think the above strategy is spot on. Unfortunately, that's not how the
Docker ecosystem works.
I'm not sure I agree here, but again nobody is forcing you to use this
tool.
I know
Excerpts from Lars Kellogg-Stedman's message of 2014-10-14 12:50:48 -0700:
> On Tue, Oct 14, 2014 at 03:25:56PM -0400, Jay Pipes wrote:
> > I think the above strategy is spot on. Unfortunately, that's not how the
> > Docker ecosystem works.
>
> I'm not sure I agree here, but again nobody is forcin
On Tue, Oct 14, 2014 at 04:06:22PM -0400, Jay Pipes wrote:
> I understand that general feeling, but system administration tasks like
> debugging networking issues or determining and grepping log file locations
> or diagnosing packaging issues for OpenStack services or performing database
> logfile
Hello everyone,
Due to two issues discovered in testing of the published Neutron 2014.2
RC2, we generated a new Juno release candidate. You can find the list of
bugfixes in this RC and a link to a source tarball at:
https://launchpad.net/neutron/juno/juno-rc3
At this point, only show-stoppers wo
On Mon, Oct 13, 2014 at 3:01 PM, Elizabeth K. Joseph
wrote:
> The OpenStack Infrastructure (Infra) team is hosting our weekly
> meeting on Tuesday October 14th, at 19:00 UTC in #openstack-meeting
Meeting minutes and log are available here:
Minutes:
http://eavesdrop.openstack.org/meetings/infra/
On Tue, 14 Oct 2014 09:57:01 -0400
Jay Pipes wrote:
> On 10/14/2014 05:04 AM, Alex Xu wrote:
> > There is one reason to think about what projects *currently* do.
> > When we choice which convention we want.
> > For example, the CamelCase and snake_case, if the most project use
> > snake_case, then
Angus Lees wrote:
> I've been reading a bunch of the existing Dockerfiles, and I have two humble
> requests:
>
>
> 1. It would be good if the "interesting" code came from python sdist/bdists
> rather than rpms.
>
> This will make it possible to rebuild the containers using code from a
> priva
On Tue, 14 Oct 2014 10:29:34 -0500
Lance Bragstad wrote:
> I found a couple of free times available for a weekly meeting if
> people are interested:
>
> https://review.openstack.org/#/c/128332/2
>
> Not sure if a meeting time has been hashed out already or not, and if
> it has I'll change the p
Excerpts from Thomas Spatzier's message of 2014-10-14 10:13:27 -0700:
>
> Hi all,
>
> I have been experimenting a lot with Heat software config to check out
> what works today, and to think about potential next steps.
> I've also worked on an internal project where we are leveraging software
> c
On 15/10/14 06:13, Thomas Spatzier wrote:
Hi all,
I have been experimenting a lot with Heat software config to check out
what works today, and to think about potential next steps.
I've also worked on an internal project where we are leveraging software
config as of the Icehouse release.
I thin
On Tue, Oct 14, 2014 at 4:29 PM, Christopher Yeoh wrote:
> On Tue, 14 Oct 2014 10:29:34 -0500
> Lance Bragstad wrote:
>
> > I found a couple of free times available for a weekly meeting if
> > people are interested:
> >
> > https://review.openstack.org/#/c/128332/2
> >
> > Not sure if a meeting
- Original Message -
> Same thing works with cloud init too...
>
>
> I've been waiting on systemd working inside a container for a while. it seems
> to work now.
oh no...
> The idea being its hard to write a shell script to get everything up and
> running with all the interactions tha
Agreed on the requirements of test results to qualify the vendor plugin to
be listed in the upstream docs.
Is there any procedure/infrastructure currently available for this
purpose?..
Pls. fwd any link/pointers on those info.
Thanks,
Vad
--
On Mon, Oct 13, 2014 at 10:25 PM, Akihiro Motoki wrote
On Tue, Oct 14, 2014 at 5:14 PM, Vadivel Poonathan <
vadivel.openst...@gmail.com> wrote:
> Agreed on the requirements of test results to qualify the vendor plugin to
> be listed in the upstream docs.
> Is there any procedure/infrastructure currently available for this
> purpose?..
> Pls. fwd any l
On Oct 13, 2014, at 5:49 PM, Chris Dent wrote:
> On Tue, 7 Oct 2014, Sandy Walsh wrote:
>
>> Haven't had any time to get anything written down (pressing deadlines
>> with StackTach.v3) but open to suggestions. Perhaps we should just add
>> something to the olso.messaging etherpad to find time a
On 15/10/14 10:38, Clint Byrum wrote:
Excerpts from Thomas Spatzier's message of 2014-10-14 10:13:27 -0700:
Hi all,
I have been experimenting a lot with Heat software config to check out
what works today, and to think about potential next steps.
I've also worked on an internal project where we
From: Doug Hellmann [d...@doughellmann.com] Tuesday, October 14, 2014 7:19 PM
> It might be more appropriate to put it on the cross-project session list:
> https://etherpad.openstack.org/p/kilo-crossproject-summit-topics
Done ... thanks!
___
OpenStack
On Oct 14, 2014, at 12:31 PM, Salvatore Orlando wrote:
> Hi Doug,
>
> do you know if the existing quota oslo-incubator module has already some
> active consumers?
> In the meanwhile I've pushed a spec to neutron-specs for improving quota
> management there [1]
It looks like a lot of projects
Ok, why are you so down on running systemd in a container?
Pacemaker works, but its kind of a pain to setup compared just yum installing a
few packages and setting init to systemd. There are some benefits for sure, but
if you have to force all the docker components onto the same physical machine
On Tue, 14 Oct 2014 09:45:44 -0400
Jay Pipes wrote:
> On 10/14/2014 12:52 AM, Christopher Yeoh wrote:
> > On Mon, 13 Oct 2014 22:20:32 -0400
> > Jay Pipes wrote:
> >
> >> On 10/13/2014 07:11 PM, Christopher Yeoh wrote:
> >>> On Mon, 13 Oct 2014 10:52:26 -0400
> > And whilst I don't have a proble
On Oct 14, 2014, at 6:00 PM, Lance Bragstad wrote:
>
>
> On Tue, Oct 14, 2014 at 4:29 PM, Christopher Yeoh wrote:
> On Tue, 14 Oct 2014 10:29:34 -0500
> Lance Bragstad wrote:
>
> > I found a couple of free times available for a weekly meeting if
> > people are interested:
> >
> > https://re
Doug,
I totally agree with your findings on the policy module.
Neutron already has some "customizations" there and we already have a few
contributors working on syncing it back with oslo-incubator during the Kilo
release cycle.
However, my query was about the quota module.
>From what I gather it
- Original Message -
> Ok, why are you so down on running systemd in a container?
It goes against the grain.
>From a distributed systems view, we gain quite a bit of control by maintaining
"one service per container". Containers can be re-organised and re-purposed
dynamically.
If we ha
- Original Message -
> Ok, why are you so down on running systemd in a container?
>
> Pacemaker works, but its kind of a pain to setup compared just yum installing
> a few packages and setting init to systemd. There are some benefits for
> sure, but if you have to force all the docker co
Hi Phillip,
Adding my thoughts below. I’ll first answer the questions you raised with
what I think should be done, and then give my explanations to reason
through with those views.
1. Do we want to add logic in the plugin to call the FLIP association API?
>> We should implement the logic in
Thanks for the doc.
The floating IP could be hosted directly by the lb backend/lb appliance as well?
It depends on the appliance deployment.
From: Susanne Balle [mailto:sleipnir...@gmail.com]
Sent: 14 October 2014 21:15
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re:
>
> Nova is also not the right place to do the generic solution as many other
> parts could be involved... neutron and cinder come to mind. Nova needs to
> provide the basic functions but it needs something outside to make it all
> happen transparently.
> I would really like a shared solution rathe
Hi all, to my understanding we certainly don't want developers to
arbitrarily extend APIs which would lead to a lot of mess, however we still
need to find a way to standardize how we augment existing APIs since they
are not perfect either.
On Wed, Oct 15, 2014 at 7:02 AM, Doug Hellmann
wrote:
>
1 - 100 of 117 matches
Mail list logo
