Hi Chmouel,
I'll create it in case it is a real bug.
Thank you
Angelo
On 05/11/2014 05:35, JunJie Nan wrote:
I think it's a bug, rejion should work after unstack. And stack.sh is
need after clean.sh instead of unstack.sh.
Hi,
If you do ./unstack.sh you probably want to do ./stack.sh back
I don't think I know the precise answer to your question. My best guess is
that floating ips were one of the initial core L3 features implemented
before other advanced services existed. Implementing them in this way may
have been the path of least resistance at the time.
Are you suggesting a
@Germy Lure,
I cannot give you a direct answer as I am not a developer.
But let me point out that openstack can make use of many agents for l3 and
above and not just neutron-l3-agent. You may even create your own agent.
The 'neutron-l3-agent' works that way just to keep things simple. One point
Hi Salvatore,
A startup flag is really a simpler approach. But in what situation we
should set this flag to remove all flows? upgrade? restart manually?
internal fault?
Indeed, only at the time that there are inconsistent(incorrect, unwanted,
stable and so on) flows between agent and the ovs
Hi Dean,
I think that a lot of developers use devstack installed on a VM.
So the right WoW after perfroming ./unstack.sh is :
1)If you don't want that stack.sh overwrite your local configuration
set RECLONE=no
in local.conf
2)perform ./stack.sh
3)perform ./rejoin-stack.sh
Right?
Thank you
Hi Jorge,
I am still not convinced that we need to use logging for usage metrics. We can
also use the haproxy stats interface (which the haproxy team is willing to
improve based on our input) and/or iptables as Stephen suggested. That said
this probably needs more exploration.
From an HP
Hi,
I also agree, IMHO we need flow synchronization method so we can avoid network
downtime and stray flows.
Regards,
Erik
From: Germy Lure [mailto:germy.l...@gmail.com]
Sent: den 5 november 2014 10:46
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re:
Any but the 1400 utc
On Nov 4, 2014 8:48 AM, Doug Wiegley do...@a10networks.com wrote:
Hi LBaaS (and others),
We’ve been talking about possibly re-schedulng the LBaaS meeting to a time
to is less crazy early for those in the US. Alternately, we could also
start alternating times. For now,
Mandeep,
thanks a ton for setting it up. I just didn't see the email before I went
to sleep, so I didn't bother to get up for the session. Now I wish I had!
To affirm the attempt, Yi Sun opened up a google hangout for me today in
the split meeting. Even as crappy as the audio was from the mic on
Hi,
I like 16.00 UTC.
German
On Nov 3, 2014 11:42 PM, Doug Wiegley do...@a10networks.com wrote:
Hi LBaaS (and others),
We’ve been talking about possibly re-schedulng the LBaaS meeting to a time
to is less crazy early for those in the US. Alternately, we could also
start alternating times.
Hi folks,
I'd like to raise a discussion kept in irc and in gerrit recently:
https://review.openstack.org/#/c/131944/
The intention of the patch is to clean up particular scheduling
method/interface:
schedule_network.
Let me clarify why I think it needs to be done (beside code api consistency
I have no opposition to that, and I will be happy to assist reviewing the
code that will enable flow synchronisation (or to say it in an easier way,
punctual removal of flows unknown to the l2 agent).
In the meanwhile, I hope you won't mind if we go ahead and start making
flow reset optional -
I'm just a lurker, so pls don't optimize for me. FWIW, here's my reply, in
order of pref:
wed 1600 UTC
wed 1800 UTC
wed 1700 UTC
On Mon, Nov 3, 2014 at 11:42 PM, Doug Wiegley do...@a10networks.com wrote:
Hi LBaaS (and others),
We’ve been talking about possibly re-schedulng the LBaaS meeting
Hi All:
I replaced all*/db.instance_get_all_by_host()/*in nova and tested it
using *tox*.
Might it be useful? If so, Which is the better way to propose it to
OpenStack community?
Best regards,
Daniele
On 10/23/2014 09:01 PM, Dan Smith wrote:
When I fix some bugs, I found that
I guess this blueprint[1] attempted to implement the flow synchronization issue
during the agent restart.
But I see no progress/updates. It would be helpful to know about the progress
there.
[1] https://blueprints.launchpad.net/neutron/+spec/neutron-agent-soft-restart
On a different note, I
I also working on it and I am glad you can help this ,see
https://review.openstack.org/#/c/130744/ for some info though it's still
ongoing
if you want to know general rule ,I guess
https://wiki.openstack.org/wiki/How_To_Contribute can be a good place to
refer
Best Regards!
Kevin (Chen) Ji 纪 晨
Same steps I can get below results.
You may need debug into get_meters() in
ceilometer/storage/impl_sqlalchemy.py to see if some filters are taking
effect.
localadmin@ostest2:~/devstack$ ceilometer meter-list
I'm considering adding a function which takes a list and returns the first
non-null, non-empty value in that list.
So you could do EG:
some_thing:
config:
ControlVIP:
first_nonnull:
- {get_param: ControlVIP}
- {get_attr:
FWIW, this looks good to me - looking forward to using it in
keystonemiddleware
Steve
From: Davanum Srinivas dava...@gmail.com
To: openstack-dev@lists.openstack.org
Date: 11/05/2014 09:46 AM
Subject:[openstack-dev] [oslo][context] oslo.context repository
review request
Greetings ,
I would like to nominate Steve Heyman for the barbican-core team.
Steve is very active in Barbican code reviews and has been a regular
contributor of test related change requests as well as documentation.
As a reminder to barbican-core members, we use the voting process outlined
in
Hi Eugene thanks for bringing this up for discussion. My comments inline.
Thanks,
Armando
On 5 November 2014 12:07, Eugene Nikanorov enikano...@mirantis.com wrote:
Hi folks,
I'd like to raise a discussion kept in irc and in gerrit recently:
https://review.openstack.org/#/c/131944/
The
+1
Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C
From: Chad Lung chad.l...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: Wednesday, November 5, 2014 at
Hi All,
I would like to nominate Juan Antonio Osorio Robles to the barbican-core
team.
Juan has been consistently giving us very well thought out and constructive
reviews for Barbican, python-barbicanclient and barbican-specs. It’s
obvious from his reviews that he cares deeply for the quality
On Wed, Nov 05 2014, Davanum Srinivas wrote:
Sorry I missed the session (had a talk at that time).
At the Design Summit session for Oslo Library Graduation for Kilo, we
decided that oslo.context was a high priority item since oslo.log was
blocked. So here's a git repo [2], please take a look
jd__,
No issues. I followed the process in the wiki for creating a library
with minimal changes required to get the test running as documented.
we can do some of these in the openstack git when the project gets
created.
Please see notes from Doug on the etherpad on why leaving it in
oslo.log or
Hi,
We had a productive design session discussion on Tuesday. However, we
could not get to the point where we discussed all the next steps and
specific action items for Juno/Kilo GBP releases. We will be meeting
tomorrow (Thursday) morning from in the Le Meridian to cover these.
Time: 10 to 11
+1 for me.
From: Douglas Mendizabal
douglas.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com
Reply-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, November 5, 2014 at 4:53 PM
To: OpenStack List
+1 for me as well.
From: Douglas Mendizabal
douglas.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com
Reply-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, November 5, 2014 at 4:29 PM
To: OpenStack List
I am +1 for using cobbler as power management before we merge Ironic-based
stuff. It is essential part also for our HA and stop
provisioning/deployment mechanism.
On Tue, Nov 4, 2014 at 1:00 PM, Dmitriy Shulyak dshul...@mirantis.com
wrote:
Not long time ago we discussed necessity of power
Monitoring of the Fuel master's disk space is the special case. I really
wonder why Fuel master have no HA option, disk overflow can be predicted
but many other failures cannot. HA is a solution of the 'single point of
failure' problem.
The current monitoring recommendations (
My comments inline:
I would argue that it isn't, actually.
You may need to know the state of the network to make that placement
decision.
Yes, I could agree with that - and that's just a particular scheduling
implementation, not a requirement for the interface.
Just passing the id may
Hello,
As far as I can tell, disk space monitoring is pretty useless, unless Fuel
provides user with some means to automatically cleanup of stored data (i.e.
remove obsolete diagnostic snapshots, etc). Otherwise, it will be only
useful for experienced Fuel developers who know how to properly
That would be very useful. It would eliminate a few more places where I've
needed the aws if function.
It would be good to keep the get_ prefix for consistency.
Id vote for seperate function. Its cleaner.
Thanks,
Kevin
From: Lee, Alexis
Sent: Wednesday,
Ok, I don’t mind starting with the simplistic approach.
Regards,
Erik
From: Gariganti, Sudhakar Babu [mailto:sudhakar-babu.gariga...@hp.com]
Sent: den 5 november 2014 12:14
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][TripleO] Clear
Thanks German,
It looks like the conversation is going towards using the HAProxy stats
interface and/or iptables. I just wanted to explore logging a bit. That said,
can you and Stephen share your thoughts on how we might implement that
approach? I'd like to get a spec out soon because I
I would be open to making this toggle switch available, however I feel that
doing it via static configuration can introduce unnecessary burden to the
operator. Perhaps we could explore a way where the agent can figure which
state it's supposed to be in based on its reported status?
Armando
On 5
Even one additional hardware node required to host the Fuel master is seen
by many users as excessive. Unless you can come up with an architecture
that adds HA capability to Fuel without increasing its hardware footprint
by 2 more nodes, it's just not worth it.
The only operational aspect of the
Keshava,
This sounds like you're asking how you might do service function chaining with
Neutron. Is that a fair way to characterize your thoughts? I think the concept
of service chain provisioning in Neutron is worth some discussion, keeping in
mind Neutron is not a fabric controller.
-Ryan
Please join us on Friday in the Glance track - free format session, to discuss
supporting OVF/OVA in OpenStack.
Poll:
1) How interested are you in this feature? 0 - 10
2) Interested enough to help develop the feature?
Artifacts are ready for use.
We are considering defining an
Hi,All
I have a simple question.
Acording to the commit comment(*1),human_id is human-friendly ID.
And that is a slugified form of the model.
slugified means like url slugfy.
It replace the space between the string to hyphen and remove non
charactor string.
For example, a b c is replaced to
We have a template usability session at 9am this morning, and we'll be
covering these sort of utility functions as part of that session. If you
don't make it we can follow up later.
On 05/11/14 15:46, Lee, Alexis wrote:
I’m considering adding a function which takes a list and returns the
For us in Israel, the earlier the better.
The current meeting time is very good for us, although I understand it too
early for some.
-Sam.
From: Gregory Lebovitz [mailto:gregory.i...@gmail.com]
Sent: Wednesday, November 05, 2014 1:10 PM
To: OpenStack Development Mailing List (not for usage
Excerpts from Lee, Alexis's message of 2014-11-05 15:46:43 +0100:
I'm considering adding a function which takes a list and returns the first
non-null, non-empty value in that list.
So you could do EG:
some_thing:
config:
ControlVIP:
first_nonnull:
I think we're missing the point here. What I meant adding a simple
monitoring system that informed the user via UI/CLI/email/whatever of
low resources on fuel master node. That's it. HA here is not an option
-- if, despite of warnings, the user still continues to use fuel and
disk becomes
44 matches
Mail list logo
