Re: [openstack-dev] [ceilometer] unable to collect compute.node.cpu.* data

[Du Jun]

Nothing shows when I type command:

vcap@ubuntu:~$ ceilometer sample-list --meter compute.node.cpu

+-+--+--++--+---+

| Resource ID | Name | Type | Volume | Unit | Timestamp |

+-+--+--++--+---+

+-+--+--++--+---+


So, I guess there is no sample data concerning on "compute.node.cpu" in the
database.


I assume the problem is about the "pipeline.yaml", the pipeline in my
devstack system is:


---

sources:

- name: meter_source

  interval: 600

  meters:

  - "*"

  sinks:

  - meter_sink

- name: cpu_source

  interval: 600

  meters:

  - "cpu"

  sinks:

  - cpu_sink

- name: disk_source

  interval: 600

  meters:

  - "disk.read.bytes"

  - "disk.read.requests"

  - "disk.write.bytes"

  - "disk.write.requests"

  sinks:

  - disk_sink

- name: network_source

  interval: 600

  meters:

  - "network.incoming.bytes"

  - "network.incoming.packets"

  - "network.outgoing.bytes"

  - "network.outgoing.packets"

  sinks:

  - network_sink

sinks:

- name: meter_sink

  transformers:

  publishers:

  - notifier://

- name: cpu_sink

  transformers:

  - name: "rate_of_change"

parameters:

target:

name: "cpu_util"

unit: "%"

type: "gauge"

scale: "100.0 / (10**9 * (resource_metadata.cpu_number
or 1))"

  publishers:

  - notifier://

- name: disk_sink

  transformers:

  - name: "rate_of_change"

parameters:

source:

map_from:

name: "disk\\.(read|write)\\.(bytes|requests)"

unit: "(B|request)"

target:

map_to:

name: "disk.\\1.\\2.rate"

unit: "\\1/s"

type: "gauge"

  publishers:

  - notifier://

- name: network_sink

  transformers:

  - name: "rate_of_change"

parameters:

source:

   map_from:

   name:
"network\\.(incoming|outgoing)\\.(bytes|packets)"

   unit: "(B|packet)"

target:

map_to:

name: "network.\\1.\\2.rate"

unit: "\\1/s"

type: "gauge"

  publishers:

  - notifier://

Can anyone tell me whether it's true?

@hangliu, would you please show me your pipeline.yaml, if possible. Thanks!

--
Regards,
Frank

2014-11-06 22:37 GMT+08:00 Neal, Phil :

> Frank, I'd echo Hang Liu's suggestion, but also encourage you to take this
> question to the general OpenStack mailing
> list (see https://wiki.openstack.org/wiki/Mailing_Lists).
>
> - Phil
>
> From: Hang H Liu [mailto:hang...@cn.ibm.com]
> Sent: Wednesday, November 05, 2014 7:36 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [ceilometer] unable to collect
> compute.node.cpu.* data
>
> 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
>
> +-++-+--+--+--+
> | Name| Type   | Unit| Resource ID
>  | User ID  | Project ID
> |
>
> +-++-+--+--+--+
> | compute.node.cpu.frequency  | gauge  | MHz | ostest2_ostest2
>  | None | None
> |
> | compute.node.cpu.idle.percent   | gauge  | %   | ostest2_ostest2
>  | None | None
> |
> | compute.node.cpu.idle.time  | cumulative | ns  | ostest2_ostest2
>  | None | None
> |
> | compute.node.cpu.iowait.percent | gauge  | %   | ostest2_ostest2
>  | None | None
> |
> | compute.node.cpu.iowait.time| cumulative | ns  | ostest2_ostest2
>  | None | None
> |
> | compute.node.cpu.kernel.percent | gauge  | %   | ostest2_ostest2
>  | None

Re: [openstack-dev] [neutron][TripleO] Clear all flows when ovs agent start? why and how avoid?

[Germy Lure]

Hi Armando,
Static configuration really introduces unnecessary burden to the operator.
But I can't understand your "explore a way", although it sounds
interesting. Can you explain it in detail? Thank you.

BTW, as Sudhakar wrote, [1] attempted to implement the flow
synchronization, but without any progress/updates. So how to remind the
register. Or if I want to participate in it even work on it alone, what I
need do? register another BP?

[1]
https://blueprints.launchpad.net/neutron/+spec/neutron-agent-soft-restart

BR,
Germy


On Thu, Nov 6, 2014 at 2:59 AM, Armando M.  wrote:

> 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 November 2014 12:09, Salvatore Orlando  wrote:
>
>> 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 - so that we stop causing downtime upon agent restart.
>>
>> Salvatore
>>
>> On 5 November 2014 11:57, Erik Moe  wrote:
>>
>>>
>>>
>>> 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: [openstack-dev] [neutron][TripleO] Clear all flows when
>>> ovs agent start? why and how avoid?
>>>
>>>
>>>
>>> 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 related, we
>>> need refresh flows. But the problem is how we know this? I think a startup
>>> flag is too rough, unless we can tolerate the inconsistent situation.
>>>
>>>
>>>
>>> Of course, I believe that turn off startup reset flows action can
>>> resolve most problem. The flows are correct most time after all. But
>>> considering NFV 5 9s, I still recommend flow synchronization approach.
>>>
>>>
>>>
>>> BR,
>>>
>>> Germy
>>>
>>>
>>>
>>> On Wed, Nov 5, 2014 at 3:36 PM, Salvatore Orlando 
>>> wrote:
>>>
>>> From what I gather from this thread and related bug report, the change
>>> introduced in the OVS agent is causing a data plane outage upon agent
>>> restart, which is not desirable in most cases.
>>>
>>>
>>>
>>> The rationale for the change that introduced this bug was, I believe,
>>> cleaning up stale flows on the OVS agent, which also makes some sense.
>>>
>>>
>>>
>>> Unless I'm missing something, I reckon the best way forward is actually
>>> quite straightforward; we might add a startup flag to reset all flows and
>>> not reset them by default.
>>>
>>> While I agree the "flow synchronisation" process proposed in the
>>> previous post is valuable too, I hope we might be able to fix this with a
>>> simpler approach.
>>>
>>>
>>>
>>> Salvatore
>>>
>>>
>>>
>>> On 5 November 2014 04:43, Germy Lure  wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> Consider the triggering of restart agent, I think it's nothing but:
>>>
>>> 1). only restart agent
>>>
>>> 2). reboot the host that agent deployed on
>>>
>>>
>>>
>>> When the agent started, the ovs may:
>>>
>>> a.have all correct flows
>>>
>>> b.have nothing at all
>>>
>>> c.have partly correct flows, the others may need to be reprogrammed,
>>> deleted or added
>>>
>>>
>>>
>>> In any case, I think both user and developer would happy to see that the
>>> system recovery ASAP after agent restarting. The best is agent only push
>>> those incorrect flows, but keep the correct ones. This can ensure those
>>> business with correct flows working during agent starting.
>>>
>>>
>>>
>>> So, I suggest two solutions:
>>>
>>> 1.Agent gets all flows from ovs and compare with its local flows after
>>> restarting. And agent only corrects the different ones.
>>>
>>> 2.Adapt ovs and agent. Agent just push all(not remove) flows every time
>>> and ovs prepares two tables for flows switch(like RCU lock).
>>>
>>>
>>>
>>> 1 is recommended because of the 3rd vendors.
>>>
>>>
>>>
>>> BR,
>>>
>>> Germy
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Oct 31, 2014 at 10:28 PM, Ben Nemec 
>>> wrote:
>>>
>>> On 10/29/2014 10:17 AM, Kyle Mestery wrote:
>>> > On Wed, Oct 29, 2014 at 7:25 AM, Hly  wrote:
>>> >>
>>> >>
>>> >> Sent from my iPad
>>> >>
>>> >> On 2014-10-29, at 下午8:01, Robert van Leeuwen <
>>> robert.vanleeu...@spilgames.com> wrote:
>>> >>
>>> > I 

Re: [openstack-dev] OVF/OVA support

[Georgy Okrokvertskhov]

Hi Malini,

I am interested in OVa support for applications. Specifically Ova to Heat
as this is whay we usually do in Murano project.

When is free format session for Glance? Should we add this to session
etherpad?

Thanks,
Gosha
On Nov 5, 2014 6:06 PM, "Bhandaru, Malini K" 
wrote:

>  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 artifact for OVF/OVA.
>
> What should the scope of this work be? Who are our fellow travelers?
>
> Intel is interested in parsing OVF meta data associated with images – to
> ensure that a VM image lands on the most appropriate hardware in the cloud
> instance, to ensure optimal performance.
>
> The goal is to remove the need to manually specify image meta data, allow
> the appliance provider to specify HW requirements, and in so doing reduce
> human error.
>
> Are any partners interested in writing an OVF/OVA artifact => stack
> deployment? Along the lines of heat?
>
> As a first pass, Intel we could at least
>
> 1)  Defining artifact for OVA, parsing the OVF in it, pulling out the
> images therein and storing them in the glance image database and attaching
> meta data to the same.
>
> 2)  Do not want to imply that OpenStack supports OVA/OVF -- need to
> be clear on this.
>
> 3)  An OpenStack user could create a heat template using the images
> registered in step -1
>
> 4)  OVA to Heat – there may be a loss in translation! Should we
> attempt this?
>
> 5)  What should we do with multiple volume artifacts?
>
> 6)  Are volumes read-only? Or on cloning, make copies of them?
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron]why FIP is integrated into router not as a separated service like XxxaaS?

[Germy Lure]

Hi Henry,

Thanks for your suggestion. As you wrote, your approach can solve part
problem.
I believe there's a good reason(Maybe Carl's guess is right. It's a
programmer's "good" habit to leave something for latecomers :).) for AT
coupled with Router, but on the face of it, AT should be separated from
Router, at least SNAT. IMHO it's better to provide a unified service
including all kinds of AT, such as FIP, SNAT and DNAT.

BR,
Germy

On Fri, Nov 7, 2014 at 2:42 PM, Germy Lure  wrote:

> Hi Akilesh,
> Thanks for your response. I have some comments inline.
>
> BR,
> Germy
>
> On Thu, Nov 6, 2014 at 10:56 PM, Akilesh K  wrote:
>
>> Hi Geremy,
>>
>> It is necessary to not think of openstack as a way to replace all
>> functionality of your enterprise data center, but rather to better utilize
>> your resources. So I believe you should still continue to use your
>> enterprise devices to do Address Translation outside of OpenStack. Why I
>> say so is Address Translation is not necessarily a 'cloud' service. All you
>> want in your cloud is servers, private and public networks, and firewall to
>> secure them.
>>
> As you said,  we really need private and public networks. And we also need
> communication between them, from private to public and the opposite
> direction. So how to do this without AT? I think this is just the reason
> that the community introduces AT into Neutron so early, although, it is a
> little simple IMO.
>
>>
>> Anything more than that should be kept external and decoupled to
>> OpenStack. But as I said before OpenStack is to an extent modular and I
>> believe its getting better. As of now if you are using just
>> 'neutron-l3-agent' it will do 'snat' to the ip address of your router
>> attaching to 'external network' , but you can always add an extra service
>> on top of 'neutron-l3-agent' to do address translation alone as per your
>> needs.
>>
> Good idea. But I think as a cloud platform, a flexible and extendable
> architecture is more important. Agent-style or Controller-style is just an
> implementation for the architecture. People can always deal with such a
> problem. My ugly extension and your "add an extra service" are both one of
> those "solution". But they should not be the Neutron's solution. I don't
> think Neutron's goal is keeping AT external.
>
>>
>> On Thu, Nov 6, 2014 at 6:28 PM, Henry  wrote:
>>
>>> So, do you mean that we need a better way to control snat ip address? I
>>> think it make sense, but maybe simple attribute extension can solve part
>>> problem, no need to separate it at this time. For example, add a snat-ip
>>> field in the route, like fip.
>>>
>>> However if multiple snat ip is needed, and control which tenant ip is
>>> served by each snat ip, separate plugin may be needed.
>>>
>>>
>>> Sent from my iPad
>>>
>>> On 2014-11-6, at 下午6:21, Germy Lure  wrote:
>>>
>>> Hi Carl and Akilesh,
>>>
>>> Thank you for your response and explanation.
>>> My manager tells me that enterprises usually use several IP addresses
>>> and ports for AT while Neutron just use external gateway port fixed IP for
>>> SNAT. I found that if I extended the SNAT attributes, the L3 plugin will be
>>> very complex. So I must tolerate this to provider more useful SNAT feature
>>> which is really what customer needs.
>>> I think as a separated service, SNAT will be easier to do this or even
>>> it can support those scenarios.
>>> We known that VPNaaS and FwaaS dependent on L3 route service but not AT
>>> which also dependents on L3. From this point, L2 is the core of network
>>> service and L3 is the core of other advanced services. ML3 is coming.
>>> Besides, It's strange that L3's API contains a field called
>>> "snat_enable". Isn't  it?
>>>
>>> BR,
>>> Germy
>>>
>>> On Wed, Nov 5, 2014 at 5:37 PM, Akilesh K  wrote:
>>>
 @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 to consider is that Tenants may share same network space. So it
 becomes necessary to tie a router which belongs to a tenant to the tenant's
 security groups. If you try to distribute routing and firewall service you
 might end up making it too complicated.


 On Wed, Nov 5, 2014 at 2:40 PM, Carl Baldwin 
 wrote:

> 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 change?  What change?  What advantages would your
> change bring?  Do you see something fundamentally wrong with the current
> approach?  Does it have some deficiency 

Re: [openstack-dev] [Neutron]why FIP is integrated into router not as a separated service like XxxaaS?

[Germy Lure]

Hi Akilesh,
Thanks for your response. I have some comments inline.

BR,
Germy

On Thu, Nov 6, 2014 at 10:56 PM, Akilesh K  wrote:

> Hi Geremy,
>
> It is necessary to not think of openstack as a way to replace all
> functionality of your enterprise data center, but rather to better utilize
> your resources. So I believe you should still continue to use your
> enterprise devices to do Address Translation outside of OpenStack. Why I
> say so is Address Translation is not necessarily a 'cloud' service. All you
> want in your cloud is servers, private and public networks, and firewall to
> secure them.
>
As you said,  we really need private and public networks. And we also need
communication between them, from private to public and the opposite
direction. So how to do this without AT? I think this is just the reason
that the community introduces AT into Neutron so early, although, it is a
little simple IMO.

>
> Anything more than that should be kept external and decoupled to
> OpenStack. But as I said before OpenStack is to an extent modular and I
> believe its getting better. As of now if you are using just
> 'neutron-l3-agent' it will do 'snat' to the ip address of your router
> attaching to 'external network' , but you can always add an extra service
> on top of 'neutron-l3-agent' to do address translation alone as per your
> needs.
>
Good idea. But I think as a cloud platform, a flexible and extendable
architecture is more important. Agent-style or Controller-style is just an
implementation for the architecture. People can always deal with such a
problem. My ugly extension and your "add an extra service" are both one of
those "solution". But they should not be the Neutron's solution. I don't
think Neutron's goal is keeping AT external.

>
> On Thu, Nov 6, 2014 at 6:28 PM, Henry  wrote:
>
>> So, do you mean that we need a better way to control snat ip address? I
>> think it make sense, but maybe simple attribute extension can solve part
>> problem, no need to separate it at this time. For example, add a snat-ip
>> field in the route, like fip.
>>
>> However if multiple snat ip is needed, and control which tenant ip is
>> served by each snat ip, separate plugin may be needed.
>>
>>
>> Sent from my iPad
>>
>> On 2014-11-6, at 下午6:21, Germy Lure  wrote:
>>
>> Hi Carl and Akilesh,
>>
>> Thank you for your response and explanation.
>> My manager tells me that enterprises usually use several IP addresses and
>> ports for AT while Neutron just use external gateway port fixed IP for
>> SNAT. I found that if I extended the SNAT attributes, the L3 plugin will be
>> very complex. So I must tolerate this to provider more useful SNAT feature
>> which is really what customer needs.
>> I think as a separated service, SNAT will be easier to do this or even it
>> can support those scenarios.
>> We known that VPNaaS and FwaaS dependent on L3 route service but not AT
>> which also dependents on L3. From this point, L2 is the core of network
>> service and L3 is the core of other advanced services. ML3 is coming.
>> Besides, It's strange that L3's API contains a field called
>> "snat_enable". Isn't  it?
>>
>> BR,
>> Germy
>>
>> On Wed, Nov 5, 2014 at 5:37 PM, Akilesh K  wrote:
>>
>>> @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 to consider is that Tenants may share same network space. So it
>>> becomes necessary to tie a router which belongs to a tenant to the tenant's
>>> security groups. If you try to distribute routing and firewall service you
>>> might end up making it too complicated.
>>>
>>>
>>> On Wed, Nov 5, 2014 at 2:40 PM, Carl Baldwin  wrote:
>>>
 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 change?  What change?  What advantages would your
 change bring?  Do you see something fundamentally wrong with the current
 approach?  Does it have some deficiency that you can point out?  Basically,
 we need a suggested modification with some good justification to spend time
 making that modification.

 Carl
 Hi,

 Address Translation(FIP, snat and dnat) looks like an advanced service.
 Why it is integrated into L3 router? Actually, this is not how it's done in
 practice. They are usually provided by Firewall device but not router.

 What's the design concept?

 Thanks&Regards,
 Germy

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org

[openstack-dev] cinder.brick.initiator

[Nikesh Kumar Mahalka]

What are the volume operations which will touch code base in
cinder.brick.initiator?

I am using a LVMISCSIDriver and tgtadm as a iscsi_helper.
I want to use hardware acceleration for iscsi target on cinder block
storage node.


Any help or suggestion will be really helpful.





Regards
Nikesh
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Cinder State Machine - Kilo Design Summit Talk - November 5

[Vilobh Meshram]

I have updated https://etherpad.openstack.org/p/cinder-enforcement-of-states  - 
Cinder Enforcement of States with the write-up (in an easily understandable 
way) for Dynamic state diagram generation depending on the way the flow has 
been layed out in the code.
Interested people have a look.
Thanks,Vilobh

 

 From: Vilobh Meshram 
 To: "openst...@lists.openstack.org"  
Cc: Vilobh Meshram  
 Sent: Tuesday, November 4, 2014 2:55 PM
 Subject: [Cinder] Cinder State Machine - Kilo Design Summit Talk - November 5
   
Following Etherpad links will be used for the talk :-
https://etherpad.openstack.org/p/cinder-state-machine-and-rolling-upgrades  - 
Cinder State Machine and Rolling upgrades

https://etherpad.openstack.org/p/cinder-enforcement-of-states  - Cinder 
Enforcement of States

Thanks,Vilobh


   

  ___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] pci pass through turing complete config options?

[Ian Wienand]

On 10/29/2014 12:42 AM, Doug Hellmann wrote:

Another way to do this, which has been used in some other projects,
is to define one option for a list of “names” of things, and use
those names to make groups with each field


I've proposed that in [1].  I look forward to some -1's :)


OTOH, oslo.config is not the only way we have to support
configuration. This looks like a good example of settings that are
more complex than what oslo.config is meant to handle, and that
might be better served in a separate file with the location of that
file specified in an oslo.config option.


My personal opinion is that yet-another-config-file in possibly
yet-another-format is just a few lines of code, but has a pretty high
cost for packagers, testers, admins, etc.  So I feel like that's
probably a last-resort.

-i

[1] https://review.openstack.org/133138

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] How to expose the error messages if the heat stack creation fails with software config/software deployment

[Hang H Liu]

I am using devstack, which should be juno version.

Best Regards,
Liu, Hang(Henry)

 --
 hang...@cn.ibm.com | Tel: +8610-58748871   | ITN: 6-9058871
 --
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Tao Tao  写于 2014/11/07 11:17:49:

> From: Tao Tao 
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> 
> Date: 2014/11/07 11:21
> Subject: Re: [openstack-dev] [heat] How to expose the error messages
> if the heat stack creation fails with software config/software deployment
>
> Hi, Henry:
>
> Appreciate very much for your kind reply!
>
> Yes, this is what I want, however, I am not seeing the detailed
> error message as you are seeing.
>
> I am still using OpenStack Icehouse, are you using OpenStack Juno
orIcehouse?
>
> [root@openstack-03 heat(keystone_admin)]# heat stack-show LCH_test1
> +--
>
+--

> +
> | Property | Value
|
> +--
>
+

> |
> | stack_status_reason  | Resource CREATE failed: Error: Deployment
> to server
|
> |  | failed: deploy_status_code : Deployment
> exited with
|
> |  | non-zero status code: 1
|
>
|
> +--
>
+--

> +
>
>
> Thanks,
> Tao Tao, Ph.D.
> IBM T. J. Watson Research Center
> 1101 Kitchawan Road
> Yorktown Heights, NY 10598
> Phone: (914) 945-4541
> Email: t...@us.ibm.com
>
> [图像已删除] Hang H Liu ---11/06/2014 09:53:40 PM---Hi, Tao Tao,
> Here is an example,
>
> From: Hang H Liu 
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> 
> Date: 11/06/2014 09:53 PM
> Subject: Re: [openstack-dev] [heat] How to expose the error messages
> if the heat stack creation fails with software config/software deployment
>
>
>
> Hi, Tao Tao,
>
> Here is an example,
>
> DEBUG (session) REQ: curl -i -X GET http://9.186.100.22:8004/v1/
> f334fc078b944b60a08d121022fae0f0/stacks/s1  ... ...
>
> RESP BODY:
> { "stack" : { "capabilities" : [  ],
>
>  ... ...
>
>  "parent" : null,
>  "stack_name" : "s1",
>  "stack_owner" : "admin",
>  "stack_status" : "CREATE_FAILED",
>  "stack_status_reason" : "Resource CREATE failed: Error:
> Resource CREATE failed: Forbidden: Quota exceeded for instances:
> Requested 1, but already used 4 of 4 instances (HTTP 403) (Request-
> ID: req-02784ecc-4713-4601-84b5-099586d7b436)",
>  "template_description" : "Creates an autoscaling application
> using Ceilometer.",
>  "timeout_mins" : null,
>  "updated_time" : null
>} }
>
>
> Whether "stack_status_reason" can satisfy your requirement?
>
>
> Best Regards,
> Liu, Hang(Henry)
>
> --
> hang...@cn.ibm.com | Tel: +8610-58748871   | ITN: 6-9058871
> --
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> Tao Tao  写于 2014/11/07 08:08:17:
>
> > From: Tao Tao 
> > To: "OpenStack Development Mailing List \(not for usage questions\)"
> > 
> > Date: 2014/11/07 08:11
> > Subject: Re: [openstack-dev] [heat] How to expose the error messages
> > if the heat stack creation fails with software config/software
deployment
> >
> > Hi, Ton:
> >
> > Thanks for your kind reply.
> >
> > What I really mean is how to expose the error messages so that I can
> > use Heat REST API to find the error messages?
> >
> > In another word, how would a user to be able to find out the
> > specific error message as a Heat client?
> >
> >
> > Thanks,
> > Tao Tao, Ph.D.
> > IBM T. J. Watson Research Center
> > 1101 Kitchawan Road
> > Yorktown Heights, NY 10598
> > Phone: (914) 945-4541
> > Email: t...@us.ibm.com
> >
> > [图像已删除] Ton Ngo---11/06/2014 07:04:30 PM---Hi Tao Tao,If
> > you use Ubuntu image, you can check /var/log/syslog
> >
> > From: Ton Ngo/Watson/IBM@IBMUS
> > To: "OpenStack Development Mailing List \(not for usage questions\)"
> > 
> > Date: 11/06/2014 07:04 PM
> > Subject: Re: [openstack-dev] [heat] How to expose the error messages
> > if the heat stack creation fails with software config/software
deployment
> >
> >
> >
> > Hi Tao Tao,
> >   If you use Ubuntu image, you can check /var/log/syslog
> > Look for section like:
> > Running /opt/stack/os-config-ref

Re: [openstack-dev] [heat] How to expose the error messages if the heat stack creation fails with software config/software deployment

[Tao Tao]

Hi, Henry:

Appreciate very much for your kind reply!

Yes, this is what I want, however, I am not seeing the detailed error
message as you are seeing.

I am still using OpenStack Icehouse, are you using OpenStack Juno or
Icehouse?

[root@openstack-03 heat(keystone_admin)]# heat stack-show LCH_test1
+--+--+

| Property | Value
|
+--+
|
| stack_status_reason  | Resource CREATE failed: Error: Deployment to
server
|
|  | failed: deploy_status_code : Deployment exited
with
|
|  | non-zero status code: 1
|
|
+--+--+


Thanks,
Tao Tao, Ph.D.
IBM T. J. Watson Research Center
1101 Kitchawan Road
Yorktown Heights, NY 10598
Phone: (914) 945-4541
Email: t...@us.ibm.com



From:   Hang H Liu 
To: "OpenStack Development Mailing List \(not for usage questions
\)" 
Date:   11/06/2014 09:53 PM
Subject:Re: [openstack-dev] [heat] How to expose the error messages if
the heat stack creation fails with software config/software
deployment



Hi, Tao Tao,

Here is an example,

DEBUG (session) REQ: curl -i -X GET
http://9.186.100.22:8004/v1/f334fc078b944b60a08d121022fae0f0/stacks/s1
... ...

RESP BODY:
{ "stack" : { "capabilities" : [  ],

  ... ...

  "parent" : null,
  "stack_name" : "s1",
  "stack_owner" : "admin",
  "stack_status" : "CREATE_FAILED",
  "stack_status_reason" : "Resource CREATE failed: Error: Resource
CREATE failed: Forbidden: Quota exceeded for instances: Requested 1, but
already used 4 of 4 instances (HTTP 403) (Request-ID:
req-02784ecc-4713-4601-84b5-099586d7b436)",
  "template_description" : "Creates an autoscaling application using
Ceilometer.",
  "timeout_mins" : null,
  "updated_time" : null
} }


Whether "stack_status_reason" can satisfy your requirement?


Best Regards,
Liu, Hang(Henry)

--
hang...@cn.ibm.com | Tel: +8610-58748871   | ITN: 6-9058871
--
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Tao Tao  写于 2014/11/07 08:08:17:

> From: Tao Tao 
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> 
> Date: 2014/11/07 08:11
> Subject: Re: [openstack-dev] [heat] How to expose the error messages
> if the heat stack creation fails with software config/software deployment
>
> Hi, Ton:
>
> Thanks for your kind reply.
>
> What I really mean is how to expose the error messages so that I can
> use Heat REST API to find the error messages?
>
> In another word, how would a user to be able to find out the
> specific error message as a Heat client?
>
>
> Thanks,
> Tao Tao, Ph.D.
> IBM T. J. Watson Research Center
> 1101 Kitchawan Road
> Yorktown Heights, NY 10598
> Phone: (914) 945-4541
> Email: t...@us.ibm.com
>
> [图像已删除] Ton Ngo---11/06/2014 07:04:30 PM---Hi Tao Tao,If
> you use Ubuntu image, you can check /var/log/syslog
>
> From: Ton Ngo/Watson/IBM@IBMUS
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> 
> Date: 11/06/2014 07:04 PM
> Subject: Re: [openstack-dev] [heat] How to expose the error messages
> if the heat stack creation fails with software config/software deployment
>
>
>
> Hi Tao Tao,
>   If you use Ubuntu image, you can check /var/log/syslog
> Look for section like:
> Running /opt/stack/os-config-refresh/configure.d/20-os-apply-config
> You should see the logs for running the script, error message, script
> output
> The scripts are stored on the VM instance
> in:  /var/lib/heat-config/heat-config-script
> Ton Ngo,
>
>
>
> From: Tao Tao/Watson/IBM@IBMUS
> To: "OpenStack List" 
> Date: 11/06/2014 12:09 PM
> Subject: [openstack-dev] [heat] How to expose the error messages if the
>heat stack creation fails with software config/software
>deployment
>
>
>
> Hi, All:
>
> When the heat stack creation fails due to software config/software
> deployment with scripts/chef/puppet, we are not able to locate the error
> message with Heat REST APIs.
>
> What is the best practice to solve this problem?
>
>
> Thanks,
> Tao Tao, Ph.D.
> IBM T. J. Watson Research Center
> 1101 Kitchawan Road
> Yorktown Heights, NY 10598
> Phone: (914) 945-4541
> Email: t...@us.ibm.com___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] How to expose the error messages if the heat stack creation fails with software config/software deployment

[Hang H Liu]

Hi, Tao Tao,

Here is an example,

DEBUG (session) REQ: curl -i -X GET
http://9.186.100.22:8004/v1/f334fc078b944b60a08d121022fae0f0/stacks/s1
... ...

RESP BODY:
{ "stack" : { "capabilities" : [  ],

  ... ...

  "parent" : null,
  "stack_name" : "s1",
  "stack_owner" : "admin",
  "stack_status" : "CREATE_FAILED",
  "stack_status_reason" : "Resource CREATE failed: Error: Resource
CREATE failed: Forbidden: Quota exceeded for instances: Requested 1, but
already used 4 of 4 instances (HTTP 403) (Request-ID:
req-02784ecc-4713-4601-84b5-099586d7b436)",
  "template_description" : "Creates an autoscaling application using
Ceilometer.",
  "timeout_mins" : null,
  "updated_time" : null
} }


Whether "stack_status_reason" can satisfy your requirement?


Best Regards,
Liu, Hang(Henry)

--
hang...@cn.ibm.com | Tel: +8610-58748871   | ITN: 6-9058871
--
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Tao Tao  写于 2014/11/07 08:08:17:

> From: Tao Tao 
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> 
> Date: 2014/11/07 08:11
> Subject: Re: [openstack-dev] [heat] How to expose the error messages
> if the heat stack creation fails with software config/software deployment
>
> Hi, Ton:
>
> Thanks for your kind reply.
>
> What I really mean is how to expose the error messages so that I can
> use Heat REST API to find the error messages?
>
> In another word, how would a user to be able to find out the
> specific error message as a Heat client?
>
>
> Thanks,
> Tao Tao, Ph.D.
> IBM T. J. Watson Research Center
> 1101 Kitchawan Road
> Yorktown Heights, NY 10598
> Phone: (914) 945-4541
> Email: t...@us.ibm.com
>
> [图像已删除] Ton Ngo---11/06/2014 07:04:30 PM---Hi Tao Tao,If
> you use Ubuntu image, you can check /var/log/syslog
>
> From: Ton Ngo/Watson/IBM@IBMUS
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> 
> Date: 11/06/2014 07:04 PM
> Subject: Re: [openstack-dev] [heat] How to expose the error messages
> if the heat stack creation fails with software config/software deployment
>
>
>
> Hi Tao Tao,
>   If you use Ubuntu image, you can check /var/log/syslog
> Look for section like:
> Running /opt/stack/os-config-refresh/configure.d/20-os-apply-config
> You should see the logs for running the script, error message, script
> output
> The scripts are stored on the VM instance
> in:  /var/lib/heat-config/heat-config-script
> Ton Ngo,
>
>
>
> From: Tao Tao/Watson/IBM@IBMUS
> To: "OpenStack List" 
> Date: 11/06/2014 12:09 PM
> Subject: [openstack-dev] [heat] How to expose the error messages if the
>heat stack creation fails with software config/software
>deployment
>
>
>
> Hi, All:
>
> When the heat stack creation fails due to software config/software
> deployment with scripts/chef/puppet, we are not able to locate the error
> message with Heat REST APIs.
>
> What is the best practice to solve this problem?
>
>
> Thanks,
> Tao Tao, Ph.D.
> IBM T. J. Watson Research Center
> 1101 Kitchawan Road
> Yorktown Heights, NY 10598
> Phone: (914) 945-4541
> Email: t...@us.ibm.com___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] dvr l3_snat

[Li Tianqing]

Oh, thanks, i finally find it.
it's all here.
https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr


Thanks a lot.



--

Best
Li Tianqing

At 2014-11-06 20:47:39, "Henry"  wrote:

Have you read previous posts? This topic had been discussed for a while. 

Sent from my iPad

On 2014-11-6, at 下午6:18, "Li Tianqing"  wrote:


Hello,
   why we put l3_snat on network node to handle North/South snat, and why don't 
we put it  on compute node? 
   Does it possible to put l3_agent on all compute_node for North/South snat, 
dnat, and east/west l3 routing? 





--

Best
Li Tianqing



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] How to expose the error messages if the heat stack creation fails with software config/software deployment

[Tao Tao]

Hi, Ton:

Thanks for your kind reply.

What I really mean is how to expose the error messages so that I can use
Heat REST API to find the error messages?

In another word, how would a user to be able to find out the specific error
message as a Heat client?


Thanks,
Tao Tao, Ph.D.
IBM T. J. Watson Research Center
1101 Kitchawan Road
Yorktown Heights, NY 10598
Phone: (914) 945-4541
Email: t...@us.ibm.com



From:   Ton Ngo/Watson/IBM@IBMUS
To: "OpenStack Development Mailing List \(not for usage questions
\)" 
Date:   11/06/2014 07:04 PM
Subject:Re: [openstack-dev] [heat] How to expose the error messages if
the heat stack creation fails with software config/software
deployment



Hi Tao Tao,
   If you use Ubuntu image, you can check /var/log/syslog
Look for section like:

Running /opt/stack/os-config-refresh/configure.d/20-os-apply-config
You should see the logs for running the script, error message, script
output
The scripts are stored on the VM instance
in:  /var/lib/heat-config/heat-config-script
Ton Ngo,



From:Tao Tao/Watson/IBM@IBMUS
To:  "OpenStack List" 
Date:11/06/2014 12:09 PM
Subject: [openstack-dev] [heat] How to expose the error messages
if the
heat stack creation fails with software config/software
deployment



Hi, All:

When the heat stack creation fails due to software config/software
deployment with scripts/chef/puppet, we are not able to locate the error
message with Heat REST APIs.

What is the best practice to solve this problem?


Thanks,
Tao Tao, Ph.D.
IBM T. J. Watson Research Center
1101 Kitchawan Road
Yorktown Heights, NY 10598
Phone: (914) 945-4541
Email: t...@us.ibm.com___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] How to expose the error messages if the heat stack creation fails with software config/software deployment

[Ton Ngo]

Hi Tao Tao,
   If you use Ubuntu image, you can check /var/log/syslog
Look for section like:
Running /opt/stack/os-config-refresh/configure.d/20-os-apply-config
You should see the logs for running the script, error message, script
output
The scripts are stored on the VM instance
in:  /var/lib/heat-config/heat-config-script
Ton Ngo,



From:   Tao Tao/Watson/IBM@IBMUS
To: "OpenStack List" 
Date:   11/06/2014 12:09 PM
Subject:[openstack-dev] [heat] How to expose the error messages if the
heat stack creation fails with software config/software
deployment



Hi, All:

When the heat stack creation fails due to software config/software
deployment with scripts/chef/puppet, we are not able to locate the error
message with Heat REST APIs.

What is the best practice to solve this problem?


Thanks,
Tao Tao, Ph.D.
IBM T. J. Watson Research Center
1101 Kitchawan Road
Yorktown Heights, NY 10598
Phone: (914) 945-4541
Email: t...@us.ibm.com___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] New function: first_nonnull

[Zane Bitter]

On 06/11/14 20:44, Steven Hardy wrote:

On Wed, Nov 05, 2014 at 02:46:43PM +, Lee, Alexis wrote:

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: [ControlVirtualIP, fixed_ips, 0,
ip_address]}]}


I'm open to other names, EG "some", "or", "fallback_list" etc.

Steve Hardy suggested building this into get_attr or Fn::Select. My
feeling is that those each do one job well right now, I'm happy to
take a steer though.


Ah, from our IRC discussion I was thinking you wanted primarily list
filtering of get_attr output, thus thinking an optional argument would make
more sense than a new function.

I see now that you're actually looking for something of a poor-mans
conditional, so you choose either the ControlVIP parameter, or the
ControlVirtualIP attribute, for which your proposal is probably cleaner -
my concern is just that we avoid a proliferation of different list
select/filter functions, when we could just have one.



Crazy thought: why not just implement conditionals? We had a proto-spec 
for them started at one point...



To clarify I wasn't suggesting we add anything into Fn::Select, but
possibly implementing a native alternative which does what Fn::Select does
and includes optional list filtering, e.g something flexible which can do
more than just select a non-null value, e.g something like:

 list_select:
 - {get_param: ControlVIP}
 - {get_attr: [ControlVirtualIP, fixed_ips, 0, ip_address]}]}
 - 0
 - non_null

This would take any number of list arguments, join them, then take an
index value, and an optional filter value.  Maybe we could even make the
"0" optional and default to zero, provided there's a non-overlapping range
of input allowed for the index and filter arguments.

Don't have a very strong opinion on the name, but FWIW I prefer
first_nonnull over coalesce, just because the latter is really clear
if you know the mysql function, and really not if you don't :)

Happy to hear other ideas, but I think it's good that we discuss this
before committing to an interface (either here or in a spec review).

Steve

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] [neutron] social event

[xico loco]

I WANNA GO

2014-11-06 19:52 GMT-02:00 Armando M. :

> Thanks for everyone who turned up!
>
> It was nice seeing you there, it was last minute planning...but we manage
> to squeeze in okay!
>
> Cheers,
> Armando
>
> On 6 November 2014 17:16, Oleg Bondarev  wrote:
>
>> Please count me in.
>>
>> Thanks,
>> Oleg
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] LeastNetwork scheduling for DHCP

[Itsuro ODA]

+1

IMHO, it is enough for [1][3] to fix by issuing a bug report.

Thanks
Itsuro Oda

On Thu, 6 Nov 2014 17:20:57 +0100
ZZelle  wrote:

> Hi,
> 
> 
> iiuc,
> 
> It seems [1][3] share exactly the same objective and implementation
> intention:
>  - define an common abstract dhcp scheduler class
>  - define a dhcp LeastNetworkScheduler
> 
> [2] proposes to
> - define a dhcp LeastVmScheduler (networks are scheduled on the dhcp agent
> supporting the least vms (=>ports?))
> 
> 
> So i am not sure we need an umbrella spec as [1][3] can be merged in [1]
> (the older wins?)
> and [2] can become a daughter spec or can be merged with previous spec?
> 
> 
> Cedric,
> ZZelle@IRC
> 
> 
> [1] https://review.openstack.org/104587
> [2] https://review.openstack.org/111210
> [3] https://review.openstack.org/130912
> 
> 
> 
> 
> On Thu, Nov 6, 2014 at 4:39 PM, Narasimhan, Vivekanandan <
> vivekanandan.narasim...@hp.com> wrote:
> 
> >  Hi Neutron Stackers,
> >
> >
> >
> > There is an interest among vendors to bring Least Networks scheduling for
> > DHCP into Openstack Neutron.
> >
> >
> >
> > Currently there are the following blueprints lying there, all of them
> > trying to address this issue:
> >
> > https://review.openstack.org/111210
> >
> > https://review.openstack.org/#/c/130912/
> >
> > https://review.openstack.org/104587
> >
> >
> >
> > We are trying  to pull together all these BPs as one Umbrella BP, on which
> > we
> >
> > can pour volunteers from every side, to clear out this BP itself as
> > initial step.
> >
> >
> >
> > So we would like to collaborate, to plan BP approval for these.
> >
> >
> >
> > Please respond if you are interested.
> >
> >
> >
> > --
> >
> > Thanks,
> >
> >
> >
> > Vivek
> >
> >
> >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >

-- 
Itsuro ODA 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 team summit meetup

[Brian Bowen (brbowen)]

Count me in,

Brian B.

From: Xuhan Peng mailto:pengxu...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, November 6, 2014 at 4:18 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Neutron] IPv6 team summit meetup

Hey,

Since we don't have any slot for ipv6 in summit to meet up, can we have a lunch 
meetup together tomorrow (11/7 Friday)?

We can meet at 12:30 at the meet up place Neuilly lobby of Le Meridien and go 
to lunch together after that.

Xu Han


—
Sent from Mailbox for iPhone
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] social event

[Brian Bowen (brbowen)]

Thanks for getting everyone together. It all worked out well.

Brian B.

From: "Armando M." mailto:arma...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, November 6, 2014 at 10:52 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>, 
openstack mailto:openst...@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] social event

Thanks for everyone who turned up!

It was nice seeing you there, it was last minute planning...but we manage to 
squeeze in okay!

Cheers,
Armando

On 6 November 2014 17:16, Oleg Bondarev 
mailto:obonda...@mirantis.com>> wrote:

Please count me in.

Thanks,
Oleg

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] L2 Gateway discussion

[Igor Cardoso]

I was at Maruti's presentation and it was very interesting. I have
developed a similar PoC so I got even more interested.

The main difference between them, from my understanding during the
presentation, is that my PoC tries to encompass very heteogeneous kinds of
networking equipment. Say, making use of an old old switch from some
vendor, or a different equipment that doesn't even use VLANs.

This is possible due to a pluggable architecture that makes it possible to
develop complete drivers to deal with any network switch/router and
L2-extend their physical/legacy networks towards Neutron (and vice-versa).
One of the drivers I have developed is for OpenWrt, which also allows
instantiating wireless SSIDs remotely (via Neutron) and map them to
specific Neutron networks.

I would like to join you tomorrow. Unfortunately, by that time, I will be
heading back to my home country. Nevertheless, I will be staying on par, as
soon as I get reconnected.

Cheers,

On 6 November 2014 15:54, Kamat, Maruti Haridas  wrote:

>  + Christian
>
>
>
> Hi Everyone,
>
>
>
> The slide-deck is placed at:
> https://drive.google.com/file/d/0B6wARyYJHf0ZRDJvdkJYVjVLVzQ/view?usp=sharing
>
>  References:
>
> https://review.openstack.org/#/c/93613/
>
> https://review.openstack.org/#/c/100278/
>
> https://review.openstack.org/#/ c/87825
> 
>
>
>
> Thanks,
>
> Maruti
>
>
>
> *From:* Sukhdev Kapur [mailto:sukh...@arista.com]
> *Sent:* Thursday, November 06, 2014 2:59 PM
> *To:* Armando M.
> *Cc:* Shiv Haris; Akihiro Motoki; Sukhdev Kapur; rmada...@brocade.com;
> Kamat, Maruti Haridas; isaku yamahata
> *Subject:* Re: L2 gateway spinout
>
>
>
> Folks,
>
>
>
> FYI...
>
> There were more people in the circle discussing this.
>
>
>
> I had sent the same message on dev list to ensure that everybody has
> opportunity to participate - see here
>
>
> http://lists.openstack.org/pipermail/openstack-dev/2014-November/049907.html
>
>
>
> Please reply to that email than this - so that wider audience gets the
> exposure to this discussion.
>
>
>
> regards..
>
> -Sukhdev
>
>
>
>
>
>
>
>
>
> On Nov 6, 2014 1:42 PM, "Armando M."  wrote:
>
> Hi Shiv,
>
>
>
> Thanks for starting this up.
>
>
>
> Can we put together all the references that might be relevant to this
> effort on this mail thread? This is what I got so far:
>
>
>
> https://review.openstack.org/#/c/93613/
>
> https://review.openstack.org/#/c/100278/
>
>
>
> Cheers,
>
> Armando
>
>
>
> On 6 November 2014 13:26, Shiv Haris  wrote:
>
>
>
> After the L2 lightening talk some folks got interested in getting together
> for a spinout of this project.
>
>
>
> We will be meeting on Friday at 9:30 am outside the Neutron Session area.
>
>
>
> See you there if you are interested in participating in this.
>
>
>
> Please forward this email to all interested.
>
>
>
> Thanks,
>
>
>
> Shiv Haris
>
> irc: shivharis
>
>
>
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Igor Duarte Cardoso.
http://igordcard.com
@igordcard 
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 team summit meetup

[Henry Gessau]

Count me in.

On 11/6/2014 4:18 PM, Xuhan Peng wrote:
> Hey, 
>
> Since we don't have any slot for ipv6 in summit to meet up, can we have a
> lunch meetup together tomorrow (11/7 Friday)?
>
> We can meet at 12:30 at the meet up place Neuilly lobby of Le Meridien and
> go to lunch together after that.
>
> Xu Han 
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] social event

[Armando M.]

Thanks for everyone who turned up!

It was nice seeing you there, it was last minute planning...but we manage
to squeeze in okay!

Cheers,
Armando

On 6 November 2014 17:16, Oleg Bondarev  wrote:

> Please count me in.
>
> Thanks,
> Oleg
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 team summit meetup

[Collins, Sean]

Looking forward to it, see you all then!

--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] How to expose the error messages if the heat stack creation fails with software config/software deployment

[Tao Tao]

Hi, All:

When the heat stack creation fails due to software config/software
deployment with scripts/chef/puppet, we are not able to locate the error
message with Heat REST APIs.

What is the best practice to solve this problem?


Thanks,
Tao Tao, Ph.D.
IBM T. J. Watson Research Center
1101 Kitchawan Road
Yorktown Heights, NY 10598
Phone: (914) 945-4541
Email: t...@us.ibm.com___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] [neutron] local.conf for devstack using neutron on home network

[Kyle Mestery]

On Thu, Nov 6, 2014 at 1:24 PM, Chris Dent  wrote:
>
> I seem to be struggling to cook a neutron configuration for my little
> home network that doesn't end in a variety of failures (devstack errors
> out, floating ips are on an unexpected (and unrouted) network, etc).
> I recognize that neutron is going to be complex out of necessity, so
> I'm not complaining, I just don't know what to do.
>
> I've fought with this in a variety of ways, getting the sense that I'm
> just doing it completely wrong, so I thought perhaps I should just ask
> if someone can produce a config for my network (described below).
>
> If you do help I'll be eternally grateful and owe you virtual beer and
> you'll get the satisfaction of knowing you've helped to educate someone
> out of the pit of ignorance.
>
> I have a wifi network 192.168.1.0/24
>
> I have a mac mini on that network.
>
> I use "internet sharing" to have an ethernet network (192.168.2.0/24)
> behind the mac. Out the etherport is a switch with two additional hosts
> (2.2 and 2.3), on each of which I'd like to run devstack on bare-metal
> with floating ips on the 192.168.2 network.
>
> Internet sharing is satisfactory for me. I don't need to reach the
> devstack hosts or their guests from beyond the mac, but I would like to
> reach them from the mac.
>
> Each devstack host has one physical interface, eth0, with a static
> IP. I'd like compute instances to get floating ips from a portion of
> that network.
>
> Using nova-networking I can make this work without issue:
>
> ```
> [[local|localrc]]
> HOST_IP=192.168.2.3
> FLOATING_RANGE=192.168.2.128/26
> ```
>
> What transformation is needed to get similar functionality with
> neutron?
>
Keep the above in your local.conf, and add the following:

Q_PLUGIN=ml2
Q_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch,logger
Q_AGENT=openvswitch
enable_service q-agt
ENABLE_TENANT_TUNNELS=True

That will enable GRE tunnels between your hosts using your HOST_IP as
the tunnel endpoint. And it should setup floating IPs per the range
you have specified as well.

Thanks.
Kyle

> Thanks.
>
> --
> Chris Dent tw:@anticdent freenode:cdent
> https://tank.peermore.com/tanks/cdent
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] New function: first_nonnull

[Steven Hardy]

On Wed, Nov 05, 2014 at 02:46:43PM +, Lee, Alexis wrote:
>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: [ControlVirtualIP, fixed_ips, 0,
>ip_address]}]}
> 
> 
>I'm open to other names, EG "some", "or", "fallback_list" etc.
> 
>Steve Hardy suggested building this into get_attr or Fn::Select. My
>feeling is that those each do one job well right now, I'm happy to
>take a steer though.

Ah, from our IRC discussion I was thinking you wanted primarily list
filtering of get_attr output, thus thinking an optional argument would make
more sense than a new function.

I see now that you're actually looking for something of a poor-mans
conditional, so you choose either the ControlVIP parameter, or the
ControlVirtualIP attribute, for which your proposal is probably cleaner -
my concern is just that we avoid a proliferation of different list
select/filter functions, when we could just have one.

To clarify I wasn't suggesting we add anything into Fn::Select, but
possibly implementing a native alternative which does what Fn::Select does
and includes optional list filtering, e.g something flexible which can do
more than just select a non-null value, e.g something like:

list_select:
- {get_param: ControlVIP}
- {get_attr: [ControlVirtualIP, fixed_ips, 0, ip_address]}]}
- 0
- non_null

This would take any number of list arguments, join them, then take an
index value, and an optional filter value.  Maybe we could even make the
"0" optional and default to zero, provided there's a non-overlapping range
of input allowed for the index and filter arguments.

Don't have a very strong opinion on the name, but FWIW I prefer
first_nonnull over coalesce, just because the latter is really clear
if you know the mysql function, and really not if you don't :)

Happy to hear other ideas, but I think it's good that we discuss this
before committing to an interface (either here or in a spec review).

Steve

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa] [neutron] local.conf for devstack using neutron on home network

[Chris Dent]

I seem to be struggling to cook a neutron configuration for my little
home network that doesn't end in a variety of failures (devstack errors
out, floating ips are on an unexpected (and unrouted) network, etc).
I recognize that neutron is going to be complex out of necessity, so
I'm not complaining, I just don't know what to do.

I've fought with this in a variety of ways, getting the sense that I'm
just doing it completely wrong, so I thought perhaps I should just ask
if someone can produce a config for my network (described below).

If you do help I'll be eternally grateful and owe you virtual beer and
you'll get the satisfaction of knowing you've helped to educate someone
out of the pit of ignorance.

I have a wifi network 192.168.1.0/24

I have a mac mini on that network.

I use "internet sharing" to have an ethernet network (192.168.2.0/24)
behind the mac. Out the etherport is a switch with two additional hosts
(2.2 and 2.3), on each of which I'd like to run devstack on bare-metal
with floating ips on the 192.168.2 network.

Internet sharing is satisfactory for me. I don't need to reach the
devstack hosts or their guests from beyond the mac, but I would like to
reach them from the mac.

Each devstack host has one physical interface, eth0, with a static
IP. I'd like compute instances to get floating ips from a portion of
that network.

Using nova-networking I can make this work without issue:

```
[[local|localrc]]
HOST_IP=192.168.2.3
FLOATING_RANGE=192.168.2.128/26
```

What transformation is needed to get similar functionality with
neutron?

Thanks.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Octavia] Mid-cycle hack-a-thon

[Stephen Balukoff]

Adam: I've heard from multiple people that the following week is worse for
their schedules.

Susanne: I was hoping for 5 days of coding. But if you can't make it for
all of that, we'll take what we can get, eh. :)

On Thu, Nov 6, 2014 at 8:09 AM, Susanne Balle  wrote:

> Are we talking about a 5 day Hackathon or 3 day with 2 days (Mon & Fri)
> for travel?
>
> On Thu, Nov 6, 2014 at 10:10 AM, Adam Harwell 
> wrote:
>
>>  Any chance it could actually be the week AFTER? Or is that to close to
>> the holidays? <_<
>> On Nov 6, 2014 7:21 AM, Stephen Balukoff  wrote:
>>
>> I have just learned that there will be a Neutron hack-a-thon the week of
>> Dec 8 in Salt Lake City. Since we don't want to conflict with that, I would
>> like to do the Octavia hack-a-thon the previous week: Dec. 1 through 5 in
>> Seattle.
>> On Nov 5, 2014 11:05 PM, "Adam Harwell" 
>> wrote:
>>
>>>   I can probably make it up there to attend.
>>>
>>>   --Adam
>>>
>>>  https://keybase.io/rm_you
>>>
>>>
>>>   From: Stephen Balukoff 
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>> questions)" 
>>> Date: Tuesday, November 4, 2014 3:46 AM
>>> To: "OpenStack Development Mailing List (not for usage questions)" <
>>> openstack-dev@lists.openstack.org>
>>> Subject: [openstack-dev] [Octavia] Mid-cycle hack-a-thon
>>>
>>>   Howdy, folks!
>>>
>>> We are planning to have a mid-cycle hack-a-thon in Seattle from the 8th
>>> through the 12th of December. This will be at the HP corporate offices
>>> located in the Seattle convention center.
>>>
>>> During this week we will be concentrating on Octavia code and hope to
>>> make significant progress toward our v0.5 milestone.
>>>
>>> If you are interested in attending, please e-mail me. If you are
>>> interested in participating but can't travel to Seattle that week, please
>>> also let me know, and we will see about using other means to collaborate
>>> with you in real time.
>>>
>>> Thanks!
>>> Stephen
>>>
>>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>


-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Rating] Informal CloudKitty meetup

[Stephane Albert]

Hi,

We've had an amazing feedback from what we've shown of CloudKitty during
this summit.

We want to go further and gather some feedbacks, ideas, and use cases
from you guys. As tomorrow is meetups day I would like to organize an
informal one so we can exchange on the subject and create a working
group around the rating subject.

If you are interested in adding an Open Source rating component to
OpenStack please join us tomorrow in the Developers lounge.

Cheers,
Stéphane

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [FUEL] Mirror reporting

[Roman Vyalov]

Sergii,
I agree with you . We need information about the changes between mirrors.
This task is already in the process. Soon as we implement lay out
information about changes in the packages (changelog). This will easily
find out what changes are included in the ISO

On Thu, Nov 6, 2014 at 7:17 PM, Sergii Golovatiuk 
wrote:

> Hi,
>
> We have discussed the process of building our packages and how we update
> production mirrors. We have the process with staging and production
> mirrors. However, that would be nice to have a simple 'diff' reporting to
> understand what packages were updated in production mirrors. It will be
> really helpful as we'll be able to see added/removed packages so we'll be
> able to understand performance degradations or some other bugs even when
> have +1 from CI. Thank you.
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [FUEL] Mirror reporting

[Sergii Golovatiuk]

Hi,

We have discussed the process of building our packages and how we update
production mirrors. We have the process with staging and production
mirrors. However, that would be nice to have a simple 'diff' reporting to
understand what packages were updated in production mirrors. It will be
really helpful as we'll be able to see added/removed packages so we'll be
able to understand performance degradations or some other bugs even when
have +1 from CI. Thank you.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Glance] Paris Kilo summit update on contributors' meetup on Friday

[Nikhil Komawar]

Hi,

As a result of the team having outstanding questions from the summit sessions 
as well as discussions prior and during the summit, the contributor's meetup 
has some planned discussion items. The schedule is posted at the etherpad [0]. 
Please reach out to Brian (cc-ed) herewith for any questions, requests and 
concerns.

[0] https://etherpad.openstack.org/p/kilo-glance

Thanks,
-Nikhil
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] LeastNetwork scheduling for DHCP

[ZZelle]

Hi,


iiuc,

It seems [1][3] share exactly the same objective and implementation
intention:
 - define an common abstract dhcp scheduler class
 - define a dhcp LeastNetworkScheduler

[2] proposes to
- define a dhcp LeastVmScheduler (networks are scheduled on the dhcp agent
supporting the least vms (=>ports?))


So i am not sure we need an umbrella spec as [1][3] can be merged in [1]
(the older wins?)
and [2] can become a daughter spec or can be merged with previous spec?


Cedric,
ZZelle@IRC


[1] https://review.openstack.org/104587
[2] https://review.openstack.org/111210
[3] https://review.openstack.org/130912




On Thu, Nov 6, 2014 at 4:39 PM, Narasimhan, Vivekanandan <
vivekanandan.narasim...@hp.com> wrote:

>  Hi Neutron Stackers,
>
>
>
> There is an interest among vendors to bring Least Networks scheduling for
> DHCP into Openstack Neutron.
>
>
>
> Currently there are the following blueprints lying there, all of them
> trying to address this issue:
>
> https://review.openstack.org/111210
>
> https://review.openstack.org/#/c/130912/
>
> https://review.openstack.org/104587
>
>
>
> We are trying  to pull together all these BPs as one Umbrella BP, on which
> we
>
> can pour volunteers from every side, to clear out this BP itself as
> initial step.
>
>
>
> So we would like to collaborate, to plan BP approval for these.
>
>
>
> Please respond if you are interested.
>
>
>
> --
>
> Thanks,
>
>
>
> Vivek
>
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [FUEL] Mirror reporting

[Sergii Golovatiuk]

Hi,

We have discussed the process of building our packages and how we update
production mirrors. We have the process with staging and production
mirrors. However, that would be nice to have a simple 'diff' reporting to
understand what packages were updated in production mirrors. It will be
really helpful as we'll be able to see added/removed packages so we'll be
able to understand performance degradations or some other bugs even when
have +1 from CI. Thank you.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] social event

[Oleg Bondarev]

Please count me in.

Thanks,
Oleg
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Octavia] Mid-cycle hack-a-thon

[Susanne Balle]

Are we talking about a 5 day Hackathon or 3 day with 2 days (Mon & Fri) for
travel?

On Thu, Nov 6, 2014 at 10:10 AM, Adam Harwell 
wrote:

>  Any chance it could actually be the week AFTER? Or is that to close to
> the holidays? <_<
> On Nov 6, 2014 7:21 AM, Stephen Balukoff  wrote:
>
> I have just learned that there will be a Neutron hack-a-thon the week of
> Dec 8 in Salt Lake City. Since we don't want to conflict with that, I would
> like to do the Octavia hack-a-thon the previous week: Dec. 1 through 5 in
> Seattle.
> On Nov 5, 2014 11:05 PM, "Adam Harwell" 
> wrote:
>
>>   I can probably make it up there to attend.
>>
>>   --Adam
>>
>>  https://keybase.io/rm_you
>>
>>
>>   From: Stephen Balukoff 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Tuesday, November 4, 2014 3:46 AM
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Subject: [openstack-dev] [Octavia] Mid-cycle hack-a-thon
>>
>>   Howdy, folks!
>>
>> We are planning to have a mid-cycle hack-a-thon in Seattle from the 8th
>> through the 12th of December. This will be at the HP corporate offices
>> located in the Seattle convention center.
>>
>> During this week we will be concentrating on Octavia code and hope to
>> make significant progress toward our v0.5 milestone.
>>
>> If you are interested in attending, please e-mail me. If you are
>> interested in participating but can't travel to Seattle that week, please
>> also let me know, and we will see about using other means to collaborate
>> with you in real time.
>>
>> Thanks!
>> Stephen
>>
>>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] social event

[Christian Daudt]

I plan to be there also. In Atlanta the turnout was over 30 or 40 so a
table for 12 won't do...
On Nov 6, 2014 2:10 PM, "Doug Wiegley"  wrote:

>  I will be there.
>
>  doug
>
>
>  On Nov 6, 2014, at 1:45 PM, Armando M.  wrote:
>
>  I have just realized that I should have cross-reference this mail on
> both ML's. Same message for the dev mailing list.
>
>  Thanks,
> Armando
>
> On 6 November 2014 00:32, Armando M.  wrote:
>
>> Hi there,
>>
>>  I know this may be somewhat short notice, but a few of us have wondered
>> if we should continue the tradition of having a social gathering of Neutron
>> folks to have a few drinks and talk about work in a slightly less boring
>> setting.
>>
>>  I was looking at:
>>
>>  https://plus.google.com/+PlayOffWagramParis/about?hl=en
>>
>>  It seems close enough to the conference venue, and spacious enough to
>> hold a dozen of people or so. I would suggest we go over there right after
>> the end of the summit session or thereabouts, say 6.30pm.
>>
>>  RSVP
>>
>>  Cheers,
>> Armando
>>
>
>   ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] LeastNetwork scheduling for DHCP

[IWAMOTO Toshihiro]

At Thu, 6 Nov 2014 15:39:25 +,
Narasimhan, Vivekanandan wrote:
> 
> Hi Neutron Stackers,
> 
> 
> 
> There is an interest among vendors to bring Least Networks scheduling for 
> DHCP into Openstack Neutron.
> 
> 
> 
> Currently there are the following blueprints lying there, all of them trying 
> to address this issue:
> 
> https://review.openstack.org/111210
> 
> https://review.openstack.org/#/c/130912/
> 
> https://review.openstack.org/104587
> 

> We are trying  to pull together all these BPs as one Umbrella BP, on which we
> can pour volunteers from every side, to clear out this BP itself as initial 
> step.

> So we would like to collaborate, to plan BP approval for these.

> Please respond if you are interested.

Oui/Yes.

But, OTOH, this doesn't need to be very complex.
I have code that does the job based on the L3 HA scheduler code at
home.

--
IWAMOTO Toshihiro

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] New function: first_nonnull

[Fox, Kevin M]

Except it penalizes us bad spellers. ;)

Kevin


From: Clint Byrum
Sent: Wednesday, November 05, 2014 11:26:43 PM
To: openstack-dev
Subject: Re: [openstack-dev] [Heat] New function: first_nonnull

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:
> - {get_param: ControlVIP}
> - {get_attr: [ControlVirtualIP, fixed_ips, 0, ip_address]}]}
>
> I'm open to other names, EG "some", "or", "fallback_list" etc.
>
> Steve Hardy suggested building this into get_attr or Fn::Select. My feeling
> is that those each do one job well right now, I'm happy to take a steer
> though.
>
> What do you think please?
>

Yes this is super useful for writing responsive, reusable templates.

I'd like to suggest that this be called 'coalesce' as that is what SQL
calls it.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] LeastNetwork scheduling for DHCP

[Narasimhan, Vivekanandan]

Hi Neutron Stackers,



There is an interest among vendors to bring Least Networks scheduling for DHCP 
into Openstack Neutron.



Currently there are the following blueprints lying there, all of them trying to 
address this issue:

https://review.openstack.org/111210

https://review.openstack.org/#/c/130912/

https://review.openstack.org/104587



We are trying  to pull together all these BPs as one Umbrella BP, on which we

can pour volunteers from every side, to clear out this BP itself as initial 
step.



So we would like to collaborate, to plan BP approval for these.



Please respond if you are interested.



--

Thanks,



Vivek





___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Manila] Team Meetup in Paris

[Ben Swartzlander]

I announced this during several of our session, but just in case anyone 
missed that I want to let people know that I intend to hold a Manila 
team meetup tomorrow (Friday) from 1:40PM - 5:10PM in the developer 
lounge area. The agenda we will start with is what we agreed to last 
week and put on the etherpad. I'm open to discussing anything though. 
Everyone is welcome to join.


https://etherpad.openstack.org/p/kilo-manila-summit-topics

-Ben Swartzlander


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] IPv6 team summit meetup

[Xuhan Peng]

Hey, 

Since we don't have any slot for ipv6 in summit to meet up, can we have a lunch 
meetup together tomorrow (11/7 Friday)?


We can meet at 12:30 at the meet up place Neuilly lobby of Le Meridien and go 
to lunch together after that.


Xu Han 




—
Sent from Mailbox for iPhone___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Octavia] Mid-cycle hack-a-thon

[Adam Harwell]

Any chance it could actually be the week AFTER? Or is that to close to the 
holidays? <_<

On Nov 6, 2014 7:21 AM, Stephen Balukoff  wrote:

I have just learned that there will be a Neutron hack-a-thon the week of Dec 8 
in Salt Lake City. Since we don't want to conflict with that, I would like to 
do the Octavia hack-a-thon the previous week: Dec. 1 through 5 in Seattle.

On Nov 5, 2014 11:05 PM, "Adam Harwell" 
mailto:adam.harw...@rackspace.com>> wrote:
I can probably make it up there to attend.

--Adam

https://keybase.io/rm_you


From: Stephen Balukoff mailto:sbaluk...@bluebox.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 4, 2014 3:46 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Octavia] Mid-cycle hack-a-thon


Howdy, folks!

We are planning to have a mid-cycle hack-a-thon in Seattle from the 8th through 
the 12th of December. This will be at the HP corporate offices located in the 
Seattle convention center.

During this week we will be concentrating on Octavia code and hope to make 
significant progress toward our v0.5 milestone.

If you are interested in attending, please e-mail me. If you are interested in 
participating but can't travel to Seattle that week, please also let me know, 
and we will see about using other means to collaborate with you in real time.

Thanks!
Stephen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron]why FIP is integrated into router not as a separated service like XxxaaS?

[Akilesh K]

Hi Geremy,

It is necessary to not think of openstack as a way to replace all
functionality of your enterprise data center, but rather to better utilize
your resources. So I believe you should still continue to use your
enterprise devices to do Address Translation outside of OpenStack. Why I
say so is Address Translation is not necessarily a 'cloud' service. All you
want in your cloud is servers, private and public networks, and firewall to
secure them.

Anything more than that should be kept external and decoupled to OpenStack.
But as I said before OpenStack is to an extent modular and I believe its
getting better. As of now if you are using just 'neutron-l3-agent' it will
do 'snat' to the ip address of your router attaching to 'external network'
, but you can always add an extra service on top of 'neutron-l3-agent' to
do address translation alone as per your needs.

On Thu, Nov 6, 2014 at 6:28 PM, Henry  wrote:

> So, do you mean that we need a better way to control snat ip address? I
> think it make sense, but maybe simple attribute extension can solve part
> problem, no need to separate it at this time. For example, add a snat-ip
> field in the route, like fip.
>
> However if multiple snat ip is needed, and control which tenant ip is
> served by each snat ip, separate plugin may be needed.
>
>
> Sent from my iPad
>
> On 2014-11-6, at 下午6:21, Germy Lure  wrote:
>
> Hi Carl and Akilesh,
>
> Thank you for your response and explanation.
> My manager tells me that enterprises usually use several IP addresses and
> ports for AT while Neutron just use external gateway port fixed IP for
> SNAT. I found that if I extended the SNAT attributes, the L3 plugin will be
> very complex. So I must tolerate this to provider more useful SNAT feature
> which is really what customer needs.
> I think as a separated service, SNAT will be easier to do this or even it
> can support those scenarios.
> We known that VPNaaS and FwaaS dependent on L3 route service but not AT
> which also dependents on L3. From this point, L2 is the core of network
> service and L3 is the core of other advanced services. ML3 is coming.
> Besides, It's strange that L3's API contains a field called "snat_enable".
> Isn't  it?
>
> BR,
> Germy
>
> On Wed, Nov 5, 2014 at 5:37 PM, Akilesh K  wrote:
>
>> @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 to consider is that Tenants may share same network space. So it
>> becomes necessary to tie a router which belongs to a tenant to the tenant's
>> security groups. If you try to distribute routing and firewall service you
>> might end up making it too complicated.
>>
>>
>> On Wed, Nov 5, 2014 at 2:40 PM, Carl Baldwin  wrote:
>>
>>> 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 change?  What change?  What advantages would your
>>> change bring?  Do you see something fundamentally wrong with the current
>>> approach?  Does it have some deficiency that you can point out?  Basically,
>>> we need a suggested modification with some good justification to spend time
>>> making that modification.
>>>
>>> Carl
>>> Hi,
>>>
>>> Address Translation(FIP, snat and dnat) looks like an advanced service.
>>> Why it is integrated into L3 router? Actually, this is not how it's done in
>>> practice. They are usually provided by Firewall device but not router.
>>>
>>> What's the design concept?
>>>
>>> Thanks&Regards,
>>> Germy
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.op

[openstack-dev] [Neutron] L2 Gateway discussion

[Kamat, Maruti Haridas]

+ Christian

Hi Everyone,

The slide-deck is placed at: 
https://drive.google.com/file/d/0B6wARyYJHf0ZRDJvdkJYVjVLVzQ/view?usp=sharing
References:
https://review.openstack.org/#/c/93613/
https://review.openstack.org/#/c/100278/
https://review.openstack.org/#/c/87825

Thanks,
Maruti

From: Sukhdev Kapur [mailto:sukh...@arista.com]
Sent: Thursday, November 06, 2014 2:59 PM
To: Armando M.
Cc: Shiv Haris; Akihiro Motoki; Sukhdev Kapur; rmada...@brocade.com; Kamat, 
Maruti Haridas; isaku yamahata
Subject: Re: L2 gateway spinout

Folks,

FYI...
There were more people in the circle discussing this.

I had sent the same message on dev list to ensure that everybody has 
opportunity to participate - see here
http://lists.openstack.org/pipermail/openstack-dev/2014-November/049907.html

Please reply to that email than this - so that wider audience gets the exposure 
to this discussion.

regards..
-Sukhdev




On Nov 6, 2014 1:42 PM, "Armando M." 
mailto:arma...@gmail.com>> wrote:
Hi Shiv,

Thanks for starting this up.

Can we put together all the references that might be relevant to this effort on 
this mail thread? This is what I got so far:

https://review.openstack.org/#/c/93613/
https://review.openstack.org/#/c/100278/

Cheers,
Armando

On 6 November 2014 13:26, Shiv Haris 
mailto:shivha...@gmail.com>> wrote:

After the L2 lightening talk some folks got interested in getting together for 
a spinout of this project.

We will be meeting on Friday at 9:30 am outside the Neutron Session area.

See you there if you are interested in participating in this.

Please forward this email to all interested.

Thanks,

Shiv Haris
irc: shivharis



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Devstack start

[Pradip Mukhopadhyay]

Rim,


Is it possible to share urs local.conf once?

You can view the logs using screen -x stack though.



--pradip




On Thu, Nov 6, 2014 at 7:18 PM, Rim Chol (rimc)  wrote:

> Greetings!
>
> I am sending this email because I have some problems with starting the
> devstack.
>
> I cloned the devstack repository in my laptop and ran ./stack.sh in the
> devstack directory.
> But the konsole complains about that and some of the error messages are
> shown below.
> + screen -S stack -p g-api -X stuff '/usr/local/bin/glance-api
> --config-file=/etc/glance/glance-api.conf & echo $!
> >/opt/stack/status/stack/g-api.pid; fg || echo "g-api failed to start" |
> tee "/opt/stack/s'atus/stack/g-api.failure"
> + echo 'Waiting for g-api (160.85.231.43:9292) to start...'
> Waiting for g-api (160.85.231.43:9292) to start...
> + wait_for_service 60 http://160.85.231.43:9292
> + local timeout=60
> + local url=http://160.85.231.43:9292
> + timeout 60 sh -c 'while ! curl -k --noproxy '\''*'\'' -s
> http://160.85.231.43:9292 >/dev/null; do sleep 1; done'
> + die 317 'g-api did not start'
> + local exitcode=0
> + set +o xtrace
> [Call Trace]
> ./stack.sh:1186:start_glance
> /home/chol/OpenStack/devstack/lib/glance:317:die
> [ERROR] /home/chol/OpenStack/devstack/lib/glance:317 g-api did not
> start
> Error on exit
> World dumping... see ./worlddump-2014-11-06-133528.txt for details\
>
> I can not find any helpful materials on this over the Internet.
> Could anyone of you help me fix this?
> I would really appreciate your help
>
> Chol.
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] L2 Gateway discussion

[Sukhdev Kapur]

Can we put together all the references that might be relevant to this
effort on this mail thread? This is what I got so far:

https://review.openstack.org/#/c/93613/
https://review.openstack.org/#/c/100278/

Cheers,
Armando
resending with with the correct subject

On Thu, Nov 6, 2014 at 12:22 PM, Sukhdev Kapur 
wrote:

> Folks,
>
> After Maruti's lighting talk on L2 Gateway, bunch of people/vendors
> expressed interest in coming up with an API for this service. The goal is
> to come up with a basic set of API which can be implemented in Kilo time
> frame and build upon it over time in the future.
> Armando, Akihiro, and others present in this small discussion decided to
> get together tomorrow morning (Friday) in the Pods area (outside Degas
> Room) at 9:30am.
>
> If anybody has any interest in this discussion or can add value to this
> discussion, this will be a great opportunity to stop by.
>
> Thanks
> Sukhdev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] unable to collect compute.node.cpu.* data

[Neal, Phil]

Frank, I'd echo Hang Liu's suggestion, but also encourage you to take this 
question to the general OpenStack mailing 
list (see https://wiki.openstack.org/wiki/Mailing_Lists). 

- Phil

From: Hang H Liu [mailto:hang...@cn.ibm.com] 
Sent: Wednesday, November 05, 2014 7:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ceilometer] unable to collect compute.node.cpu.* 
data

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
+-++-+--+--+--+
| Name                            | Type       | Unit    | Resource ID          
                | User ID                          | Project ID                 
      |
+-++-+--+--+--+
| compute.node.cpu.frequency      | gauge      | MHz     | ostest2_ostest2      
                | None                             | None                       
      |
| compute.node.cpu.idle.percent   | gauge      | %       | ostest2_ostest2      
                | None                             | None                       
      |
| compute.node.cpu.idle.time      | cumulative | ns      | ostest2_ostest2      
                | None                             | None                       
      |
| compute.node.cpu.iowait.percent | gauge      | %       | ostest2_ostest2      
                | None                             | None                       
      |
| compute.node.cpu.iowait.time    | cumulative | ns      | ostest2_ostest2      
                | None                             | None                       
      |
| compute.node.cpu.kernel.percent | gauge      | %       | ostest2_ostest2      
                | None                             | None                       
      |
| compute.node.cpu.kernel.time    | cumulative | ns      | ostest2_ostest2      
                | None                             | None                       
      |
| compute.node.cpu.percent        | gauge      | %       | ostest2_ostest2      
                | None                             | None                       
      |
| compute.node.cpu.user.percent   | gauge      | %       | ostest2_ostest2      
                | None                             | None                       
      |
| compute.node.cpu.user.time      | cumulative | ns      | ostest2_ostest2      
                | None                      



"Lu, Lianhao"  写于 2014/11/05 15:23:14:

> From: "Lu, Lianhao" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 2014/11/05 15:31
> Subject: Re: [openstack-dev] [ceilometer] unable to collect 
> compute.node.cpu.* data
> 
> Hi Frank,
>  
> Could you try ‘celometer sample-list’ to see if the compute.node.cpu
> samples are there?
>  
> -Lianhao
>  
> From: Du Jun [mailto:dj199...@gmail.com] 
> Sent: Wednesday, November 05, 2014 3:44 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [ceilometer] unable to collect 
> compute.node.cpu.* data
>  
> Hi all,
>  
> I attempt to collect compute.node.cpu as the following link mentions:
>  
> http://docs.openstack.org/developer/ceilometer/measurements.html#compute-nova
>  
> I set:
>  
> compute_monitors = ComputeDriverCPUMonitor
>  
> in /etc/nova/nova.conf and restart nova-compute, nova-scheduler, 
> ceilometer-agent-notification, ceilometer-api, ceilometer-collector. 
>  
> From ceilometer-agent-notification's log, I can see agent transform 
> and publish data samples compute.node.cpu.*
>  
> What's more, from ceilometer database, I can see all the meters 
> compute.node.cpu.*
>  
> mysql> select * from meter;
> ++-++---+
> | id | name                            | type       | unit      |
> ++-++---+
> | 39 | compute.node.cpu.frequency      | gauge      | MHz       |
> | 41 | compute.node.cpu.idle.percent   | gauge      | %         |
> | 38 | compute.node.cpu.idle.time      | cumulative | ns        |
> | 45 | compute.node.cpu.iowait.percent | gauge      | %         |
> | 42 | compute.node.cpu.iowait.time    | cumulative | ns        |
> | 36 | compute.node.cpu.kernel.percent | gauge      | %         |
> | 44 | compute.node.cpu.kernel.time    | cumulative | ns        |
> | 37 | compute.node.cpu.percent        | gauge      | %         |
> | 43 | compute.node.cpu.user.percent   | gauge      | %         |
> | 40 | compute.node.cpu.user.time      | cumulative | ns        |
>  
>  
> However, when I type
>  
> ceilometer meter-list
>  
> It shows nothing about 

Re: [openstack-dev] [neutron] dvr l3_snat

[Li Tianqing]

i search in goolge by useing key words neutron dvr l3_snat mailing list, and do 
not find the thread you said about.
Can you give me some urls? 
Thanks
--

Best
Li Tianqing

At 2014-11-06 20:47:39, "Henry"  wrote:

Have you read previous posts? This topic had been discussed for a while. 

Sent from my iPad

On 2014-11-6, at 下午6:18, "Li Tianqing"  wrote:


Hello,
   why we put l3_snat on network node to handle North/South snat, and why don't 
we put it  on compute node? 
   Does it possible to put l3_agent on all compute_node for North/South snat, 
dnat, and east/west l3 routing? 





--

Best
Li Tianqing



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [swift] Swift Browser 0.1.0 released

[Martin Geisler]

Hi everybody,

I'm happy to announce the release of Swift Browser 0.1.0. Swift Browser
is a JavaScript based interface for Swift. You will find a pre-built
tarball and zip file here:

  https://github.com/zerovm/swift-browser/releases/tag/0.1.0

They are ready to be unpacked and uploaded to your Swift installation.

This first release includes a basic feature set which allows you to:

* Authenticate using Keystone and LiteAuth.
* Browse containers and pseudo-directories.
* Create and delete containers.
* Edit object content and metadata.
* Upload and delete objects.

-- 
Martin Geisler

http://google.com/+MartinGeisler


pgpP1c8E_QNji.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements

[Stephen Balukoff]

Hi Jorge,

So, one can query a pre-defined UDP socket or "stats HTTP service" (which
can be an in-band service, by the way) and HAProxy will give all kinds of
useful stats on the current listener, its pools, its members, etc. We will
probably be querying this service in any case to detect things like members
going down, etc. for sending notifications upstream. The problem is this
interface presently resets state whenever haproxy is reloaded, which needs
to happen whenever there's a configuration change. I was able to meet with
the HAProxy team (including Willy Tarreau), and they're interested in
making improvements to HAProxy that we would find useful. Foremost on their
list was the ability to preserve this state information between restarts.

Until that's ready and in a stable release of haproxy, it's also pretty
trivial to parse out IP addresses and listening ports from the haproxy
config, and use these to populate a series of IPtables chains whose entire
purpose is to gather bandwidth I/O data. These tables won't give you things
like max connnection counts, etc., but if you're billing on raw bandwidth
usage, these stats are guaranteed to be accurate and survive through
haproxy restarts. It also does not require one to scan logs, and is
available cheaply in real time. (This is how we bill for bandwidth on our
current software load balancer product.)

My vote would be to use the IPTables approach for now until HAProxy is able
to retain state between restarts. For other stats data (eg. max connection
counts, total number of requests), I would recommend gathering this data
from the haproxy daemon, and keeping an external state file that we update
immediately before restarting haproxy. (Yes, this means we lose some
information on connections that are still open when haproxy restarts, but
it gives us an "approximate" good value since we anticipate haproxy
restarts being relatively rare in comparison to serving actual requests).

Logs are still very handy, and I agree that if extreme accuracy in billing
is required, this is the way to get that data. Logs are also very handy for
users to have for troubleshooting purposes. But I think logs are not well
suited to providing data which will be consumed in real time (eg. stuff
which will populate a dashboard.)

What do y'all think of this?

Stephen

On Wed, Nov 5, 2014 at 10:25 AM, Jorge Miramontes <
jorge.miramon...@rackspace.com> wrote:

>   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 believe metric
> gathering can be worked on in parallel with the rest of the project. In
> fact, I was hoping to get my hands dirty on this one and contribute some
> code, but a strategy and spec are needed first before I can start that ;)
>
>  Cheers,
> --Jorge
>
>   From: , German 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Wednesday, November 5, 2014 3:50 AM
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements
>
>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 perspective the full logs on the load balancer are mostly
> interesting for the user of the loadbalancer – we only care about
> aggregates for our metering. That said we would be happy to just move them
> on demand to a place the user can access.
>
>
>
> Thanks,
>
> German
>
>
>
>
>
> *From:* Jorge Miramontes [mailto:jorge.miramon...@rackspace.com
> ]
> *Sent:* Tuesday, November 04, 2014 8:20 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage
> Requirements
>
>
>
> Hi Susanne,
>
>
>
> Thanks for the reply. As Angus pointed out, the one big item that needs to
> be addressed with this method is network I/O of raw logs. One idea to
> mitigate this concern is to store the data locally for the
> operator-configured granularity, process it and THEN send it to cielometer,
> etc. If we can't engineer a way to deal with the high network I/O that will
> inevitably occur we may have to move towards a polling approach. Thoughts?
>
>
>
> Cheers,
>
> --Jorge
>
>
>
> *From: *Susanne Balle 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Tuesday, November 4, 2014 11:10 AM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re

Re: [openstack-dev] Introducing Project Cue

[Vipul Sabhaya]

We will be meeting folks that are interested in discussing Cue at *10 AM on
Friday at the Trove Pod* in the “Program Pods” section of the Design Summit.

Looking forward to seeing folks there!
-Vipul
HP

On Tue, Nov 4, 2014 at 10:26 AM, Vipul Sabhaya  wrote:

> Hello Everyone,
>
> I would like to introduce Cue, a new Openstack project aimed at
> simplifying the application developer responsibilities by providing a
> managed service focused on provisioning and lifecycle management of
> message-oriented middleware services like RabbitMQ.
>
> Messaging is a common development pattern for building loosely coupled
> distributed systems. Provisioning and supporting Messaging Brokers for an
> individual application can be a time consuming and painful experience. This
> product aims to simplify the provisioning and management of message
> brokers, providing High Availability, management, and auto-healing
> capabilities to the end user, while providing tenant-level isolation.
>
> More details, including the scope of the project can be found here:
> https://wiki.openstack.org/wiki/Cue
>
> We’ve started writing code: https://github.com/vipulsabhaya/cue — the
> plan is to make it a Stackforge project in the coming weeks.
>
> I work for HP, and we’ve built a team within HP to build Cue.  I am in
> Paris for the Summit, and would appreciate feedback either on the mailing
> list or in person.
>
> If you are interested in helping build Cue, or have any questions/concerns
> around the project vision, I plan to host a meetup in the design summit
> area of the Le Meridien on *Friday morning*.  More details to come.
>
> Thanks!
> -Vipul Sabhaya
> HP
>
>
>
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Devstack start

[Rim Chol (rimc)]

Greetings!

I am sending this email because I have some problems with starting the devstack.

I cloned the devstack repository in my laptop and ran ./stack.sh in the 
devstack directory.
But the konsole complains about that and some of the error messages are shown 
below.
+ screen -S stack -p g-api -X stuff '/usr/local/bin/glance-api 
--config-file=/etc/glance/glance-api.conf & echo $! 
>/opt/stack/status/stack/g-api.pid; fg || echo "g-api failed to start" | tee 
"/opt/stack/s'atus/stack/g-api.failure"
+ echo 'Waiting for g-api (160.85.231.43:9292) to start...'
Waiting for g-api (160.85.231.43:9292) to start...
+ wait_for_service 60 http://160.85.231.43:9292
+ local timeout=60
+ local url=http://160.85.231.43:9292
+ timeout 60 sh -c 'while ! curl -k --noproxy '\''*'\'' -s 
http://160.85.231.43:9292 >/dev/null; do sleep 1; done'
+ die 317 'g-api did not start'
+ local exitcode=0
+ set +o xtrace
[Call Trace]
./stack.sh:1186:start_glance
/home/chol/OpenStack/devstack/lib/glance:317:die
[ERROR] /home/chol/OpenStack/devstack/lib/glance:317 g-api did not start
Error on exit
World dumping... see ./worlddump-2014-11-06-133528.txt for details\

I can not find any helpful materials on this over the Internet.
Could anyone of you help me fix this?
I would really appreciate your help

Chol.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Devstack start

[Rim Chol (rimc)]

Greetings!

I am sending this email because I have some problems with starting the devstack.

I cloned the devstack repository in my laptop and ran ./stack.sh in the 
devstack directory.
But the konsole complains about that and some of the error messages are shown 
below.
+ screen -S stack -p g-api -X stuff '/usr/local/bin/glance-api 
--config-file=/etc/glance/glance-api.conf & echo $! 
>/opt/stack/status/stack/g-api.pid; fg || echo "g-api failed to start" | tee 
"/opt/stack/s'atus/stack/g-api.failure"
+ echo 'Waiting for g-api (160.85.231.43:9292) to start...'
Waiting for g-api (160.85.231.43:9292) to start...
+ wait_for_service 60 http://160.85.231.43:9292
+ local timeout=60
+ local url=http://160.85.231.43:9292
+ timeout 60 sh -c 'while ! curl -k --noproxy '\''*'\'' -s 
http://160.85.231.43:9292 >/dev/null; do sleep 1; done'
+ die 317 'g-api did not start'
+ local exitcode=0
+ set +o xtrace
[Call Trace]
./stack.sh:1186:start_glance
/home/chol/OpenStack/devstack/lib/glance:317:die
[ERROR] /home/chol/OpenStack/devstack/lib/glance:317 g-api did not start
Error on exit
World dumping... see ./worlddump-2014-11-06-133528.txt for details\

I can not find any helpful materials on this over the Internet.
Could anyone of you help me fix this?
I would really appreciate your help

Chol.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] rescheduling meeting

[Stephen Balukoff]

The current meeting time is too early for me (in PST8PDT time zone). I
prefer the 16:00 UTC time or later.

Stephen
On Nov 6, 2014 8:22 AM, "Samuel Bercovici"  wrote:

>  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 questions); Doug
> Wiegley
> *Subject:* Re: [openstack-dev] [neutron][lbaas] rescheduling meeting
>
>
>
> 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 
> 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, let’s see if we can find a slot that
> works every week.  Please respond with any time slots that you can NOT
> attend:
>
> Monday, 1600UTC
> Monday, 1700UTC
> Tuesday, 1600UTC (US pacific, 8am)
> Tuesday, 1700UTC
> Tuesday, 1800UTC
> Wednesday, 1600UTC (US pacific, 8am)
> Wednesday, 1700UTC
> Wednesday, 1800UTC
> Thursday, 1400UTC (US pacific, 6am)
>
>
> Note that many of these slots will require the approval of the
> #openstack-meeting-4 channel:
>
> https://review.openstack.org/#/c/132629/
>
> https://review.openstack.org/#/c/132630/
>
>
> Thanks,
> Doug
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> --
>
> 
> Open industry-related email from
> Gregory M. Lebovitz
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer] Timeout should be added when call http request

[ZhiQiang Fan]

Hi, devs,

I noticed that Ceilometer project uses lots of other OpenStack services,
and other thirdparty services APIs, but rare of them set timeout when call
http request, this is not a good behavior because many pollsters run in one
of threads, if one is every slow or stuckd, then others will not be able to
work too.

The worst case is if Ceilometer thread is stuckd, then when outside service
becomes normal, Ceilometer cannot recover itself, cloud operator will need
to restart the service manually, that is bad.

I have reported a bug, see:
https://bugs.launchpad.net/ceilometer/+bug/1388778
and uploaded a patch, see: https://review.openstack.org/#/c/132974/

What's your opinion?

And *I need help for writing test code for this patch* (the main reason why
I write this mail), is there any idea to test timeout case? I don't want
the unit test to be very slow, so a real timeout like sleep is not my
current choice.

Thanks
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Octavia] Mid-cycle hack-a-thon

[Stephen Balukoff]

I have just learned that there will be a Neutron hack-a-thon the week of
Dec 8 in Salt Lake City. Since we don't want to conflict with that, I would
like to do the Octavia hack-a-thon the previous week: Dec. 1 through 5 in
Seattle.
On Nov 5, 2014 11:05 PM, "Adam Harwell"  wrote:

>   I can probably make it up there to attend.
>
>   --Adam
>
>  https://keybase.io/rm_you
>
>
>   From: Stephen Balukoff 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, November 4, 2014 3:46 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [Octavia] Mid-cycle hack-a-thon
>
>   Howdy, folks!
>
> We are planning to have a mid-cycle hack-a-thon in Seattle from the 8th
> through the 12th of December. This will be at the HP corporate offices
> located in the Seattle convention center.
>
> During this week we will be concentrating on Octavia code and hope to make
> significant progress toward our v0.5 milestone.
>
> If you are interested in attending, please e-mail me. If you are
> interested in participating but can't travel to Seattle that week, please
> also let me know, and we will see about using other means to collaborate
> with you in real time.
>
> Thanks!
> Stephen
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] social event

[Doug Wiegley]

I will be there.

doug


On Nov 6, 2014, at 1:45 PM, Armando M. 
mailto:arma...@gmail.com>> wrote:

I have just realized that I should have cross-reference this mail on both ML's. 
Same message for the dev mailing list.

Thanks,
Armando

On 6 November 2014 00:32, Armando M. 
mailto:arma...@gmail.com>> wrote:
Hi there,

I know this may be somewhat short notice, but a few of us have wondered if we 
should continue the tradition of having a social gathering of Neutron folks to 
have a few drinks and talk about work in a slightly less boring setting.

I was looking at:

https://plus.google.com/+PlayOffWagramParis/about?hl=en

It seems close enough to the conference venue, and spacious enough to hold a 
dozen of people or so. I would suggest we go over there right after the end of 
the summit session or thereabouts, say 6.30pm.

RSVP

Cheers,
Armando

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron]why FIP is integrated into router not as a separated service like XxxaaS?

[Henry]

So, do you mean that we need a better way to control snat ip address? I think 
it make sense, but maybe simple attribute extension can solve part problem, no 
need to separate it at this time. For example, add a snat-ip field in the 
route, like fip.

However if multiple snat ip is needed, and control which tenant ip is served by 
each snat ip, separate plugin may be needed.


Sent from my iPad

On 2014-11-6, at 下午6:21, Germy Lure  wrote:

> Hi Carl and Akilesh,
> 
> Thank you for your response and explanation.
> My manager tells me that enterprises usually use several IP addresses and 
> ports for AT while Neutron just use external gateway port fixed IP for SNAT. 
> I found that if I extended the SNAT attributes, the L3 plugin will be very 
> complex. So I must tolerate this to provider more useful SNAT feature which 
> is really what customer needs.
> I think as a separated service, SNAT will be easier to do this or even it can 
> support those scenarios.
> We known that VPNaaS and FwaaS dependent on L3 route service but not AT which 
> also dependents on L3. From this point, L2 is the core of network service and 
> L3 is the core of other advanced services. ML3 is coming.
> Besides, It's strange that L3's API contains a field called "snat_enable". 
> Isn't  it?
> 
> BR,
> Germy
> 
> On Wed, Nov 5, 2014 at 5:37 PM, Akilesh K  wrote:
> @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 
> to consider is that Tenants may share same network space. So it becomes 
> necessary to tie a router which belongs to a tenant to the tenant's security 
> groups. If you try to distribute routing and firewall service you might end 
> up making it too complicated. 
> 
> 
> On Wed, Nov 5, 2014 at 2:40 PM, Carl Baldwin  wrote:
> 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 change?  What change?  What advantages would your change 
> bring?  Do you see something fundamentally wrong with the current approach?  
> Does it have some deficiency that you can point out?  Basically, we need a 
> suggested modification with some good justification to spend time making that 
> modification.
> 
> Carl
> 
> Hi,
> 
> Address Translation(FIP, snat and dnat) looks like an advanced service. Why 
> it is integrated into L3 router? Actually, this is not how it's done in 
> practice. They are usually provided by Firewall device but not router.
> 
> What's the design concept?
> 
> Thanks&Regards,
> Germy
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] CI report : 18/10/2014 - 31/10/2014

[Derek Higgins]

Hi All,

The week before last saw no problems with CI

But last week we had 3 separate problems causing tripleo CI tests to
fail until they were dealt with

1. pypi.openstack.org is no longer being maintained, which we were using
in tripleo-ci, we've now moved to pypi.python.org
2. nova started using oslo concurrency and in the process removed
nova/openstack/common/lockutils.py which was being imported from ironic
3. keystone removed a deprecated class which we had been using

See more details on the etherpad
https://etherpad.openstack.org/p/tripleo-ci-breakages

thanks,
Derek.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] dvr l3_snat

[Henry]

Have you read previous posts? This topic had been discussed for a while. 

Sent from my iPad

On 2014-11-6, at 下午6:18, "Li Tianqing"  wrote:

> Hello,
>why we put l3_snat on network node to handle North/South snat, and why 
> don't we put it  on compute node? 
>Does it possible to put l3_agent on all compute_node for North/South snat, 
> dnat, and east/west l3 routing? 
> 
> 
> 
> 
> --
> Best
> Li Tianqing
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Fw: [neutron] social event

[Armando M.]

I have just realized that I should have cross-reference this mail on both
ML's. Same message for the dev mailing list.

Thanks,
Armando

On 6 November 2014 00:32, Armando M.  wrote:

> Hi there,
>
> I know this may be somewhat short notice, but a few of us have wondered if
> we should continue the tradition of having a social gathering of Neutron
> folks to have a few drinks and talk about work in a slightly less boring
> setting.
>
> I was looking at:
>
> https://plus.google.com/+PlayOffWagramParis/about?hl=en
>
> It seems close enough to the conference venue, and spacious enough to hold
> a dozen of people or so. I would suggest we go over there right after the
> end of the summit session or thereabouts, say 6.30pm.
>
> RSVP
>
> Cheers,
> Armando
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] L2 Gateway discussion

[Sukhdev Kapur]

resending with with the correct subject

On Thu, Nov 6, 2014 at 12:22 PM, Sukhdev Kapur 
wrote:

> Folks,
>
> After Maruti's lighting talk on L2 Gateway, bunch of people/vendors
> expressed interest in coming up with an API for this service. The goal is
> to come up with a basic set of API which can be implemented in Kilo time
> frame and build upon it over time in the future.
> Armando, Akihiro, and others present in this small discussion decided to
> get together tomorrow morning (Friday) in the Pods area (outside Degas
> Room) at 9:30am.
>
> If anybody has any interest in this discussion or can add value to this
> discussion, this will be a great opportunity to stop by.
>
> Thanks
> Sukhdev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] (no subject)

[Sukhdev Kapur]

Folks,

After Maruti's lighting talk on L2 Gateway, bunch of people/vendors
expressed interest in coming up with an API for this service. The goal is
to come up with a basic set of API which can be implemented in Kilo time
frame and build upon it over time in the future.
Armando, Akihiro, and others present in this small discussion decided to
get together tomorrow morning (Friday) in the Pods area (outside Degas
Room) at 9:30am.

If anybody has any interest in this discussion or can add value to this
discussion, this will be a great opportunity to stop by.

Thanks
Sukhdev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Nominating Steve Heyman for barbican-core

[John Wood]

+1

Thanks,
John


From: Nathan Reller [rellerrel...@yahoo.com]
Sent: Thursday, November 06, 2014 3:35 AM
To: Openstack-Dev
Subject: Re: [openstack-dev] [Barbican] Nominating Steve Heyman for 
barbican-core

+1 for me

-Nate

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Nominating Juan Antonio Osorio Robles for barbican-core

[John Wood]

+1

Thanks,
John


From: Chad Lung [chad.l...@gmail.com]
Sent: Thursday, November 06, 2014 4:06 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Barbican] Nominating Juan Antonio Osorio Robles for 
barbican-core


+1

Chad Lung




Date: Wed, 5 Nov 2014 15:53:02 +
From: Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>
To: "OpenStack Development Mailing List (not for usage questions)"

mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Barbican] Nominating Juan Antonio Osorio
Robles  for barbican-core
Message-ID: 
mailto:d0800668.369fa%25douglas.mendiza...@rackspace.com>>
Content-Type: text/plain; charset="utf-8"

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 of the
Barbican project, and I think he will be a great addition to the core team.

As a reminder to barbican-core members, we use the voting process outlined
in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our
team.

References:

http://stackalytics.com/report/contribution/barbican-group/90

Thanks,
Douglas


Douglas Mendiz?bal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] fuel master monitoring

[Przemyslaw Kaminski]

I didn't mean a robust monitoring system, just something simpler. 
Notifications is a good idea for FuelWeb.


P.

On 11/06/2014 09:59 AM, Anton Zemlyanov wrote:
We can add a notification to FuelWeb, no additional software or user 
actions are required. I would not overestimate this method though, it 
is in no way the robust monitoring system. Forcing user to do 
something on a regular basis is unlikely to work.


Anton

On Thu, Nov 6, 2014 at 11:55 AM, Przemyslaw Kaminski 
mailto:pkamin...@mirantis.com>> wrote:


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 full, it's the user's fault. By adding these
warnings we have a way of saying "We told you so!" Without
warnings we get bugs like [1] I mentioned in the first post.

Of course user can check disk space by hand but since we do have a
full-blown UI telling the user to periodically log in to the
console and check disks by hand seems a bit of a burden.

We can even implement such monitoring functionality as a Nailgun
plugin -- installing it would be optional and at the same time we
would grow our plugin ecosystem.

P.


On 11/05/2014 08:42 PM, Dmitry Borodaenko wrote:

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 Fuel master node that you
don't want to lose even for a short while is logging. You'd be
better off redirecting OpenStack environments' logs to a
dedicated highly available logging server (which, of course, you
already have in your environment), and deal with Fuel master node
failures by restoring it from backups.

On Wed, Nov 5, 2014 at 8:26 AM, Anton Zemlyanov
mailto:azemlya...@mirantis.com>> wrote:

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

(http://docs.openstack.org/openstack-ops/content/logging_monitoring.html)
are based on analyzing logs and manual checks, that are
rather reactive way of fixing problems. Zabbix is quite good
for preventing failures that are predictable but for the
abrupt problems Zabbix just reports them 'post mortem'.

The only way to remove the single failure point is to
implement redundancy/HA

Anton

On Tue, Nov 4, 2014 at 6:26 PM, Przemyslaw Kaminski
mailto:pkamin...@mirantis.com>> wrote:

Hello,

In extension to my comment in this bug [1] I'd like to
discuss the possibility of adding Fuel master node
monitoring. As I wrote in the comment, when disk is full
it might be already too late to perform any action since
for example Nailgun could be down because DB shut itself
down. So we should somehow warn the user that disk is
running low (in the UI and fuel CLI on stderr for
example) before it actually happens.

For now the only meaningful value to monitor would be
disk usage -- do you have other suggestions? If not then
probably a simple API endpoint with statvfs calls would
suffice. If you see other usages of this then maybe it
would be better to have some daemon collecting the stats
we want.

If we opted for a daemon, then I'm aware that the user
can optionally install Zabbix server although looking at
blueprints in [2] I don't see anything about monitoring
Fuel master itself -- is it possible to do? Though the
installation of Zabbix though is not mandatory so it
still doesn't completely solve the problem.

[1] https://bugs.launchpad.net/fuel/+bug/1371757
[2]
https://blueprints.launchpad.net/fuel/+spec/monitoring-system

Przemek

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Ceilometer][MongoDB] Using native time to live feature in MongoDB

[ZhiQiang Fan]

+1

On Thu, Nov 6, 2014 at 6:27 PM, Igor Degtiarov 
wrote:

> Hi stackers,
>
> I'm working on solving bug [1]. Time to live feature has native
> implementation in MongoDB thru index.
>
> Now we remove docs from resource table if they have no relations with
> existing samples in meter table while samples are removed when time to
> live is expired. So it seems that we can use ttl index also in
> resource table and remove reduce operation from the code.
>
> We update field last_sample_timestamp in resource table with every new
> sample that is received from certain resource. So adding ttl index to
> that field gives the same result as reduce operation in
> clear_expired_metering_data, but it will work in background with low
> priority and won't block database.
>
> Change request with implementation of ttl index in resource table [2].
>
> [1] https://bugs.launchpad.net/ceilometer/+bug/1270779
> [2] https://review.openstack.org/#/c/132988/
>
> Cheers, Igor.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] neutron roadmap

[Elzur, Uri]

Hi Salvatore

Would like to discuss with you your views on what services are needed and when 
and how to architect it etc
I’d like to meet in Palo Alto, maybe 11/19?

Thx

Uri (“Oo-Ree”)
C: 949-378-7568
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][context] oslo.context repository review request

[Davanum Srinivas]

LOL. thanks jd__ :)

On Thu, Nov 6, 2014 at 11:44 AM, Julien Danjou  wrote:
> On Thu, Nov 06 2014, Doug Hellmann wrote:
>
>> The main reasons for splitting code into its own library are dependency
>> management, API ownership, the logical separation of the contents of the 
>> library
>> within the application stack and between other libraries, and review ACLs 
>> within
>> gerrit.
>>
>> We have a couple of libraries (oslo.log and oslo.messaging) that want to 
>> specify
>> an API via the context base class, so the class can’t live in either of those
>> places.
>>
>> The utils library is actually used by some of the clients now, so we need to 
>> be
>> conscious of adding dependencies there. I don’t think context will bring in 
>> any
>> real dependencies for now, but it also doesn’t seem to be a general-purpose
>> utility. We’re going to need to add some thread-local caches for setting and
>> fetching the current context, I think, either within context or in some of 
>> the
>> other libraries with callbacks invoked by the context constructor. So for
>> logical separation, a different library seemed to make more sense.
>>
>> It’s also possible that the applications will find other uses for a shared
>> context base class, and so we’ll want to build a review team for it that 
>> isn’t
>> limited to the oslo-core team, but that’s less important than the logical
>> considerations in my mind.
>
> Ok, I can agree with all of that.
>
> I'm just not sure the burden of having yet another lib/repo/team is
> worth it for this lib. But you seem pretty confident about it and I
> don't have any massive objection.
>
> (And anyway I'll still have this mailing list thread to refer in a few
> months for an I-told-you-so just in case. :-)
>
> So that repo LGTM dims.
>
> --
> Julien Danjou
> ;; Free Software hacker
> ;; http://julien.danjou.info
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] I am not able to get the developer mails.

[Singh, Gangadhar S]

Pl help.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][context] oslo.context repository review request

[Julien Danjou]

On Thu, Nov 06 2014, Doug Hellmann wrote:

> The main reasons for splitting code into its own library are dependency
> management, API ownership, the logical separation of the contents of the 
> library
> within the application stack and between other libraries, and review ACLs 
> within
> gerrit.
>
> We have a couple of libraries (oslo.log and oslo.messaging) that want to 
> specify
> an API via the context base class, so the class can’t live in either of those
> places.
>
> The utils library is actually used by some of the clients now, so we need to 
> be
> conscious of adding dependencies there. I don’t think context will bring in 
> any
> real dependencies for now, but it also doesn’t seem to be a general-purpose
> utility. We’re going to need to add some thread-local caches for setting and
> fetching the current context, I think, either within context or in some of the
> other libraries with callbacks invoked by the context constructor. So for
> logical separation, a different library seemed to make more sense.
>
> It’s also possible that the applications will find other uses for a shared
> context base class, and so we’ll want to build a review team for it that isn’t
> limited to the oslo-core team, but that’s less important than the logical
> considerations in my mind.

Ok, I can agree with all of that.

I'm just not sure the burden of having yet another lib/repo/team is
worth it for this lib. But you seem pretty confident about it and I
don't have any massive objection.

(And anyway I'll still have this mailing list thread to refer in a few
months for an I-told-you-so just in case. :-)

So that repo LGTM dims.

-- 
Julien Danjou
;; Free Software hacker
;; http://julien.danjou.info


signature.asc
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][context] oslo.context repository review request

[Doug Hellmann]

On Nov 6, 2014, at 11:13 AM, Julien Danjou  wrote:

> On Wed, Nov 05 2014, Davanum Srinivas wrote:
> 
>> Please see notes from Doug on the etherpad on why leaving it in
>> oslo.log or oslo.utils was not considered.
>> https://etherpad.openstack.org/p/kilo-oslo-library-proposals
> 
> I only get that it might be related to db at some point, but I only
> skimmed through the linked blueprint at it's not clear to me how that
> prevent this to be in oslo.utils for example. Sorry to be a pain. :)

The main reasons for splitting code into its own library are dependency 
management, API ownership, the logical separation of the contents of the 
library within the application stack and between other libraries, and review 
ACLs within gerrit.

We have a couple of libraries (oslo.log and oslo.messaging) that want to 
specify an API via the context base class, so the class can’t live in either of 
those places.

The utils library is actually used by some of the clients now, so we need to be 
conscious of adding dependencies there. I don’t think context will bring in any 
real dependencies for now, but it also doesn’t seem to be a general-purpose 
utility. We’re going to need to add some thread-local caches for setting and 
fetching the current context, I think, either within context or in some of the 
other libraries with callbacks invoked by the context constructor. So for 
logical separation, a different library seemed to make more sense.

It’s also possible that the applications will find other uses for a shared 
context base class, and so we’ll want to build a review team for it that isn’t 
limited to the oslo-core team, but that’s less important than the logical 
considerations in my mind.

Doug


> 
> -- 
> Julien Danjou
> -- Free Software hacker
> -- http://julien.danjou.info
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer][MongoDB] Using native time to live feature in MongoDB

[Igor Degtiarov]

Hi stackers,

I'm working on solving bug [1]. Time to live feature has native
implementation in MongoDB thru index.

Now we remove docs from resource table if they have no relations with
existing samples in meter table while samples are removed when time to
live is expired. So it seems that we can use ttl index also in
resource table and remove reduce operation from the code.

We update field last_sample_timestamp in resource table with every new
sample that is received from certain resource. So adding ttl index to
that field gives the same result as reduce operation in
clear_expired_metering_data, but it will work in background with low
priority and won't block database.

Change request with implementation of ttl index in resource table [2].

[1] https://bugs.launchpad.net/ceilometer/+bug/1270779
[2] https://review.openstack.org/#/c/132988/

Cheers, Igor.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron]why FIP is integrated into router not as a separated service like XxxaaS?

[Germy Lure]

Hi Carl and Akilesh,

Thank you for your response and explanation.
My manager tells me that enterprises usually use several IP addresses and
ports for AT while Neutron just use external gateway port fixed IP for
SNAT. I found that if I extended the SNAT attributes, the L3 plugin will be
very complex. So I must tolerate this to provider more useful SNAT feature
which is really what customer needs.
I think as a separated service, SNAT will be easier to do this or even it
can support those scenarios.
We known that VPNaaS and FwaaS dependent on L3 route service but not AT
which also dependents on L3. From this point, L2 is the core of network
service and L3 is the core of other advanced services. ML3 is coming.
Besides, It's strange that L3's API contains a field called "snat_enable".
Isn't  it?

BR,
Germy

On Wed, Nov 5, 2014 at 5:37 PM, Akilesh K  wrote:

> @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 to consider is that Tenants may share same network space. So it
> becomes necessary to tie a router which belongs to a tenant to the tenant's
> security groups. If you try to distribute routing and firewall service you
> might end up making it too complicated.
>
>
> On Wed, Nov 5, 2014 at 2:40 PM, Carl Baldwin  wrote:
>
>> 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 change?  What change?  What advantages would your
>> change bring?  Do you see something fundamentally wrong with the current
>> approach?  Does it have some deficiency that you can point out?  Basically,
>> we need a suggested modification with some good justification to spend time
>> making that modification.
>>
>> Carl
>> Hi,
>>
>> Address Translation(FIP, snat and dnat) looks like an advanced service.
>> Why it is integrated into L3 router? Actually, this is not how it's done in
>> practice. They are usually provided by Firewall device but not router.
>>
>> What's the design concept?
>>
>> Thanks&Regards,
>> Germy
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] dvr l3_snat

[Li Tianqing]

Hello,
   why we put l3_snat on network node to handle North/South snat, and why don't 
we put it  on compute node? 
   Does it possible to put l3_agent on all compute_node for North/South snat, 
dnat, and east/west l3 routing? 





--

Best
Li Tianqing___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][context] oslo.context repository review request

[Davanum Srinivas]

jd__,

No sweat, we can talk in the next oslo weekly meeting

-- dims

On Thu, Nov 6, 2014 at 11:13 AM, Julien Danjou  wrote:
> On Wed, Nov 05 2014, Davanum Srinivas wrote:
>
>> Please see notes from Doug on the etherpad on why leaving it in
>> oslo.log or oslo.utils was not considered.
>> https://etherpad.openstack.org/p/kilo-oslo-library-proposals
>
> I only get that it might be related to db at some point, but I only
> skimmed through the linked blueprint at it's not clear to me how that
> prevent this to be in oslo.utils for example. Sorry to be a pain. :)
>
> --
> Julien Danjou
> -- Free Software hacker
> -- http://julien.danjou.info



-- 
Davanum Srinivas :: https://twitter.com/dims

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][context] oslo.context repository review request

[Julien Danjou]

On Wed, Nov 05 2014, Davanum Srinivas wrote:

> Please see notes from Doug on the etherpad on why leaving it in
> oslo.log or oslo.utils was not considered.
> https://etherpad.openstack.org/p/kilo-oslo-library-proposals

I only get that it might be related to db at some point, but I only
skimmed through the linked blueprint at it's not clear to me how that
prevent this to be in oslo.utils for example. Sorry to be a pain. :)

-- 
Julien Danjou
-- Free Software hacker
-- http://julien.danjou.info


signature.asc
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Barbican] Nominating Juan Antonio Osorio Robles for barbican-core

[Chad Lung]

+1

Chad Lung




Date: Wed, 5 Nov 2014 15:53:02 +
> From: Douglas Mendizabal 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [Barbican] Nominating Juan Antonio Osorio
> Robles  for barbican-core
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
>
> 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 of the
> Barbican project, and I think he will be a great addition to the core team.
>
> As a reminder to barbican-core members, we use the voting process outlined
> in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our
> team.
>
> References:
>
> http://stackalytics.com/report/contribution/barbican-group/90
>
> Thanks,
> Douglas
>
> 
> Douglas Mendiz?bal
> IRC: redrobot
> PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.db] Marker based paging

[Heald, Mike]

Unfortunately, ordering on anything but the timestamp
results in problems with usability and results consistency.

Example: Ordering on priority so I can see all my high priority tasks
first, then medium, then low.

Works ok, as long as the underlying data is geared so that the priorities
are ordered that way. But I have no way of skipping pages to find
them if they're not, and if the task that that we're using as the marker
changes priority as I page, I'm jumped to somewhere else in the list and I
have no way of knowing where I am in the list. I'd either see a load of
repeated data (with no way of skipping it)  or miss out on a lot of data
with no indication that this has happened.

So that's quite specific to Storyboard, but think of a situation where
you've ordered your instances in horizon by status so you can see
all that are spawning, running, deleting, etc. grouped together.
As you page, the marker's instance goes from spawning to running,
or running to deleting.

These aren't edge cases. The nature of the data we deal with forces
us to handle results that are going to change beneath us.

Now, I'm in no way suggesting that offset/limit would be a better solution!
But we do need to document these use cases somewhere and make sure
our paging solution can fulfil them, because Storyboard cannot provide the
user experience it needs to with the current pagination method in oslo.db.

Cheers,
Mike


From: Jay Pipes [jaypi...@gmail.com]
Sent: 04 November 2014 07:07
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [oslo.db] Marker based paging

On 11/04/2014 01:08 AM, Heald, Mike wrote:
> Thanks for that, Steven :)
>
> So just to clarify, results are ordered by the relevant timestamps to
> ensure consistent order and so that new records would never show on
> previous "pages" and be missed, and we're limited to just a "next
> page" navigation, and we cannot order the entire result set on any
> column but the timestamps, as this would break the paging because we
> can't do the comparisons we need to if the results aren't in that
> order. Have I got that correct?

No, that's not correct. There's nothing limiting one from ordering on
other columns than timestamp. We always ensure that there is a secondary
order on a column with unique values (like the primary key), in order to
ensure that pages of results are strictly ordered even when the sort
field is non-unique (like timestamp).

We're limited to next-previous pagination by choice because of the
scalability and performance limitations of a limit-offset pagination
strategy.

Best,
jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Nominating Steve Heyman for barbican-core

[Nathan Reller]

+1 for me

-Nate

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Nominating Juan Antonio Osorio Robles for barbican-core

[Nathan Reller]

+1 for me

-Nate

-

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 of the
Barbican project, and I think he will be a great addition to the core team.

As a reminder to barbican-core members, we use the voting process outlined
in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our
team.

References:

http://stackalytics.com/report/contribution/barbican-group/90

Thanks,
Douglas

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][nova] New specs on routed networking

[Rohit Agarwalla (roagarwa)]

A reminder for folks interested that we'll have a BoF discussion on Routed
Network model (without L2) at 12.30 pm today.
I'll have the Neutron placard on one of the table outside Manet room (at
Le Meridien) for folks to find us.

https://etherpad.openstack.org/p/RoutedNetworking


Thanks
Rohit

On 10/28/14 2:50 PM, "Carl Baldwin"  wrote:

>On Tue, Oct 28, 2014 at 3:07 PM, Rohit Agarwalla (roagarwa)
> wrote:
>> Agreed. The way I'm thinking about this is that tenants shouldn't care
>>what
>> the underlying implementation is - L2 or L3. As long as the connectivity
>> requirements are met using the model/API, end users should be fine.
>> The data center network design should be an administrators decision
>>based on
>> the implementation mechanism that has been configured for OpenStack.
>
>Many API users won't care about the L2 details.  This could be a
>compelling alternative for them.  However, some do.  The L2 details
>seem to matter an awful lot to many NFV use cases.  It might be that
>this alternative is just not compelling for those.  Not to say it
>isn't compelling overall though.
>
>Carl
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Nominating Steve Heyman for barbican-core

[Paul Kehrer]

+1

On Nov 5, 2014, at 4:17 PM, Chad Lung 
mailto:chad.l...@gmail.com>> wrote:

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 
https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our team.

Thanks,

Chad Lung

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Nominating Juan Antonio Osorio Robles for barbican-core

[Paul Kehrer]

+1

On Nov 5, 2014, at 4:53 PM, Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>> 
wrote:

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 of the Barbican project, 
and I think he will be a great addition to the core team.

As a reminder to barbican-core members, we use the voting process outlined in 
https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our team.

References:

http://stackalytics.com/report/contribution/barbican-group/90

Thanks,
Douglas


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] fuel master monitoring

[Anton Zemlyanov]

We can add a notification to FuelWeb, no additional software or user
actions are required. I would not overestimate this method though, it is in
no way the robust monitoring system. Forcing user to do something on a
regular basis is unlikely to work.

Anton

On Thu, Nov 6, 2014 at 11:55 AM, Przemyslaw Kaminski  wrote:

>  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
> full, it's the user's fault. By adding these warnings we have a way of
> saying "We told you so!" Without warnings we get bugs like [1] I mentioned
> in the first post.
>
> Of course user can check disk space by hand but since we do have a
> full-blown UI telling the user to periodically log in to the console and
> check disks by hand seems a bit of a burden.
>
> We can even implement such monitoring functionality as a Nailgun plugin --
> installing it would be optional and at the same time we would grow our
> plugin ecosystem.
>
> P.
>
>
> On 11/05/2014 08:42 PM, Dmitry Borodaenko wrote:
>
> 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 Fuel master node that you don't want to
> lose even for a short while is logging. You'd be better off redirecting
> OpenStack environments' logs to a dedicated highly available logging server
> (which, of course, you already have in your environment), and deal with
> Fuel master node failures by restoring it from backups.
>
> On Wed, Nov 5, 2014 at 8:26 AM, Anton Zemlyanov 
> wrote:
>
>>  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 (
>> http://docs.openstack.org/openstack-ops/content/logging_monitoring.html)
>> are based on analyzing logs and manual checks, that are rather reactive way
>> of fixing problems. Zabbix is quite good for preventing failures that are
>> predictable but for the abrupt problems Zabbix just reports them 'post
>> mortem'.
>>
>>  The only way to remove the single failure point is to implement
>> redundancy/HA
>>
>>  Anton
>>
>> On Tue, Nov 4, 2014 at 6:26 PM, Przemyslaw Kaminski <
>> pkamin...@mirantis.com> wrote:
>>
>>> Hello,
>>>
>>> In extension to my comment in this bug [1] I'd like to discuss the
>>> possibility of adding Fuel master node monitoring. As I wrote in the
>>> comment, when disk is full it might be already too late to perform any
>>> action since for example Nailgun could be down because DB shut itself down.
>>> So we should somehow warn the user that disk is running low (in the UI and
>>> fuel CLI on stderr for example) before it actually happens.
>>>
>>> For now the only meaningful value to monitor would be disk usage -- do
>>> you have other suggestions? If not then probably a simple API endpoint with
>>> statvfs calls would suffice. If you see other usages of this then maybe it
>>> would be better to have some daemon collecting the stats we want.
>>>
>>> If we opted for a daemon, then I'm aware that the user can optionally
>>> install Zabbix server although looking at blueprints in [2] I don't see
>>> anything about monitoring Fuel master itself -- is it possible to do?
>>> Though the installation of Zabbix though is not mandatory so it still
>>> doesn't completely solve the problem.
>>>
>>> [1] https://bugs.launchpad.net/fuel/+bug/1371757
>>> [2] https://blueprints.launchpad.net/fuel/+spec/monitoring-system
>>>
>>> Przemek
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>  Dmitry Borodaenko
>
>
> ___
> OpenStack-dev mailing 
> listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Schedule] how to schedule vms(like database VM, vs web server VM) to different resource pool(either LVM or GlusterFs)?

[Chen CH Ji]

I think you can refer to following for more info
http://blog.csdn.net/tantexian/article/details/39055889
http://blog.russellbryant.net/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/

And this is mail list for developers ,so you can ask openstack mail list if
you have configuration or questions next time :)

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   "zhang xiaobin" <14050...@cnsuning.com>
To: openstack-dev 
Date:   11/06/2014 04:23 PM
Subject:[openstack-dev] [Nova][Schedule] how to schedule vms(like
databaseVM, vs web server VM) to different resource pool
(either LVM or  GlusterFs)?



 Greeting,

 I have some hosts in one availability zone, some hosts are solely based on
 LVM, which means their root images will be sitting on LVM;
 while other hosts are setup with GlusterFS, which means their root image
 will be allocated on Gluster.

 My question is: what's the best way to let VM be scheduled to the right
 resource pool(either LVM-based, or GlusterFs-based?)
 how to configure and which kind of schedule filter to be used? can we use
 image metadata function to achieve this?

 Many thanks!
 本邮件（包括其附件）可能含有保密、专有或保留著作权的信息。如果您并非本邮件
 指定接受人，请即刻通知发送人并将本邮件从您的系统中删除，您不得散布、保
 留、复制、披露或以其他方式使用本邮件任何相关信息，并且通过邮件告知我们此次
 错误投递。发送人在本邮件下表达的观点并不一定代表苏宁云商集团股份有限公司的
 观点。苏宁云商集团股份有限公司并不保证本邮件是安全或不受任何计算机病毒影响
 的，并且对由于邮件传输而导致的邮件内容错误或缺失不承担任何责任。除非明确说
 明，本邮件并不构成具有约束力的契约。
 This e-mail may contain confidential, copyright and/or privileged
 information. If you are not the addressee or authorized to receive this,
 please inform us of the erroneous delivery by return e-mail, and you
 should delete it from your system and may not use, copy, disclose or take
 any action based on this e-mail or any information herein. Any opinions
 expressed by sender hereof do not necessarily represent those of SUNING
 COMMERCE GROUP CO., LTD.,SUNING COMMERCE GROUP CO., LTD.,does not
 guarantee that this email is secure or free from viruses. No liability is
 accepted for any errors or omissions in the contents of this email, which
 arise as a result of email transmission. Unless expressly stated,this
 email is not intended to form a binding contract.
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] pci pass through turing complete config options?

[Doug Hellmann]

On Nov 4, 2014, at 2:38 PM, melanie witt  wrote:

> On Nov 4, 2014, at 0:32, Doug Hellmann  wrote:
> 
 I think this is reasonable, though do we actually support setting
 the same key twice ?
>> 
>> Yes, if it is registered in different groups.
> 
> I have found that for a MultiStrOpt, the same key can be set multiple times 
> even in the same group, and the result is a list of values for that option 
> [0].

Yes, that’s the purpose of MultiStrOpt. However, it is meant to hold a list of 
related items, not a list of instances of values that are essentially 
attributes of unrelated objects. If you have more than one property for a PCI 
passthrough device, you will need a separate MultiStrOpt for each one. The user 
will then have to ensure that they specify their options and values in order 
within their configuration file so that the separate arrays are populated 
consistently so the values in position 0 are all related and the values in 
position 1 are all related, etc. That is much more error prone then defining 
new groups and taking advantage of the syntax of the configuration file to help 
the user understand that a block of options is all related.

Now, all of that said, I still think you should just use a YAML file for this 
data.

Doug

> 
> [0] 
> https://github.com/openstack/oslo.config/blob/11ecf18/oslo/config/cfg.py#L1011
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] pci pass through turing complete config options?

[Doug Hellmann]

On Nov 4, 2014, at 2:07 PM, Robert Li (baoli)  wrote:

> 
> 
> On 11/3/14, 6:32 PM, "Doug Hellmann"  wrote:
> 
>> 
>> On Oct 31, 2014, at 9:27 PM, Robert Li (baoli)  wrote:
>> 
>>> 
>>> 
>>> On 10/28/14, 11:01 AM, "Daniel P. Berrange"  wrote:
>>> 
 On Tue, Oct 28, 2014 at 10:18:37AM -0400, Jay Pipes wrote:
> On 10/28/2014 07:44 AM, Daniel P. Berrange wrote:
>> One option would be a more  CSV like syntax eg
>> 
>>  pci_passthrough_whitelist =
> address=*0a:00.*,physical_network=physnet1
>>  pci_passthrough_whitelist = vendor_id=1137,product_id=0071
>> 
>> But this gets confusing if we want to specifying multiple sets of
>> data
>> so might need to use semi-colons as first separator, and comma for
>> list
>> element separators
>> 
>>  pci_passthrough_whitelist = vendor_id=8085;product_id=4fc2,
> vendor_id=1137;product_id=0071
> 
> What about this instead (with each being a MultiStrOpt, but no comma
> or
> semicolon delimiters needed…)?
>> 
>> This is easy for a developer to access, but not easy for a deployer to
>> make sure they have configured correctly because they have to keep up
>> with the order of the options instead of making sure there is a new group
>> header for each set of options.
>> 
> 
> [pci_passthrough_whitelist]
> # Any Intel PRO/1000 F Sever Adapter
> vendor_id=8086
> product_id=1001
> address=*
> physical_network=*
> # Cisco VIC SR-IOV VF only on specified address and physical network
> vendor_id=1137
> product_id=0071
> address=*:0a:00.*
> physical_network=physnet1
 
 I think this is reasonable, though do we actually support setting
 the same key twice ?
>> 
>> Yes, if it is registered in different groups.
>> 
 
 As an alternative we could just append an index for each "element"
 in the list, eg like this:
 
 [pci_passthrough_whitelist]
 rule_count=2
 
 # Any Intel PRO/1000 F Sever Adapter
 vendor_id.0=8086
>> 
>> Be careful about constructing the names. You can’t have “.” in them
>> because then you can’t access them in python, for example:
>> cfg.CONF.pci_passthrough_whitelist.vendor_id.0
>> 
 product_id.0=1001
 address.0=*
 physical_network.0=*
 
 # Cisco VIC SR-IOV VF only on specified address and physical network
 vendor_id.1=1137
 product_id.1=0071
 address.1=*:0a:00.*
 physical_network.1=physnet1
 [pci_passthrough_whitelist]
 rule_count=2
 
 # Any Intel PRO/1000 F Sever Adapter
 vendor_id.0=8086
 product_id.0=1001
 address.0=*
 physical_network.0=*
 
 # Cisco VIC SR-IOV VF only on specified address and physical network
 vendor_id.1=1137
 product_id.1=0071
 address.1=*:0a:00.*
 physical_network.1=physnet1
 
 Or like this:
 
 [pci_passthrough]
 whitelist_count=2
 
 [pci_passthrough_rule.0]
 # Any Intel PRO/1000 F Sever Adapter
 vendor_id=8086
 product_id=1001
 address=*
 physical_network=*
 
 [pci_passthrough_rule.1]
 # Cisco VIC SR-IOV VF only on specified address and physical network
 vendor_id=1137
 product_id=0071
 address=*:0a:00.*
 physical_network=physnet1
>>> 
>>> Yeah, The last format (copied in below) is a good idea (without the
>>> section for the count) to handle list of dictionaries. I¹ve seen similar
>>> config examples in neutron code.
>>> [pci_passthrough_rule.0]
>>> # Any Intel PRO/1000 F Sever Adapter
>>> vendor_id=8086
>>> product_id=1001
>>> address=*
>>> physical_network=*
>>> 
>>> [pci_passthrough_rule.1]
>>> # Cisco VIC SR-IOV VF only on specified address and physical network
>>> vendor_id=1137
>>> product_id=0071
>>> address=*:0a:00.*
>>> physical_network=physnet1
>>> 
>>> Without direct oslo support, to implement it requires a small method
>>> that
>>> uses oslo cfg¹s MultiConfigParser().
>> 
>> I’m not sure what you mean needs new support? I think this would work,
>> except for the “.” in the group name.
> 
> The group header is not fixed in this case. Let’s replace “.” with “:”,
> then the user may have configured multiple groups such as
> [pci_passthrough_rule:x]. With oslo, how would you register the group and
> the options under it and access them as a list of dictionaries?

First, you MUST pick a separator character that results in the group name being 
a valid python variable name. So, instead of “:” use “_”. That gives you 
“pci_passthrough_rule_x”. Then you just pass that name when you register the 
list of options. See the second example under 
http://docs.openstack.org/developer/oslo.config/cfg.html#option-groups

Knowing which groups must exist is a separate problem, and solving that depends 
on the application. A common solution is to have a single option win a 
well-known group with a list of the names. For example, “pci_passthrough_rules 
= x, y, z” can be converted into the longer group names to register

[openstack-dev] [Nova][Schedule] how to schedule vms(like database VM, vs web server VM) to different resource pool(either LVM or GlusterFs)?

[zhang xiaobin]

Greeting,

I have some hosts in one availability zone, some hosts are solely based on LVM, 
which means their root images will be sitting on LVM;
while other hosts are setup with GlusterFS, which means their root image will 
be allocated on Gluster.

My question is: what's the best way to let VM be scheduled to the right 
resource pool(either LVM-based, or GlusterFs-based?)
how to configure and which kind of schedule filter to be used? can we use image 
metadata function to achieve this?

Many thanks!
本邮件（包括其附件）可能含有保密、专有或保留著作权的信息。如果您并非本邮件指定接受人，请即刻通知发送人并将本邮件从您的系统中删除，您不得散布、保留、复制、披露或以其他方式使用本邮件任何相关信息，并且通过邮件告知我们此次错误投递。发送人在本邮件下表达的观点并不一定代表苏宁云商集团股份有限公司的观点。苏宁云商集团股份有限公司并不保证本邮件是安全或不受任何计算机病毒影响的，并且对由于邮件传输而导致的邮件内容错误或缺失不承担任何责任。除非明确说明，本邮件并不构成具有约束力的契约。

This e-mail may contain confidential, copyright and/or privileged information. 
If you are not the addressee or authorized to receive this, please inform us of 
the erroneous delivery by return e-mail, and you should delete it from your 
system and may not use, copy, disclose or take any action based on this e-mail 
or any information herein. Any opinions expressed by sender hereof do not 
necessarily represent those of SUNING COMMERCE GROUP CO., LTD.,SUNING COMMERCE 
GROUP CO., LTD.,does not guarantee that this email is secure or free from 
viruses. No liability is accepted for any errors or omissions in the contents 
of this email, which arise as a result of email transmission. Unless expressly 
stated,this email is not intended to form a binding contract.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OVF/OVA support

[Davanum Srinivas]

Malini,

fyi, Vui/Arnaud is leading the charge in the Nova VMware driver with
this review [1]. There is a spec in Nova also for multiple disks (for
a single vm) from Tesshu [2].

thanks,
dims

[1] https://review.openstack.org/#/c/82715/
[2] https://review.openstack.org/#/c/128691/

On Thu, Nov 6, 2014 at 3:06 AM, Bhandaru, Malini K
 wrote:
> 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 artifact for OVF/OVA.
>
> What should the scope of this work be? Who are our fellow travelers?
>
> Intel is interested in parsing OVF meta data associated with images – to
> ensure that a VM image lands on the most appropriate hardware in the cloud
> instance, to ensure optimal performance.
>
> The goal is to remove the need to manually specify image meta data, allow
> the appliance provider to specify HW requirements, and in so doing reduce
> human error.
>
> Are any partners interested in writing an OVF/OVA artifact => stack
> deployment? Along the lines of heat?
>
> As a first pass, Intel we could at least
>
> 1)  Defining artifact for OVA, parsing the OVF in it, pulling out the
> images therein and storing them in the glance image database and attaching
> meta data to the same.
>
> 2)  Do not want to imply that OpenStack supports OVA/OVF -- need to be
> clear on this.
>
> 3)  An OpenStack user could create a heat template using the images
> registered in step -1
>
> 4)  OVA to Heat – there may be a loss in translation! Should we attempt
> this?
>
> 5)  What should we do with multiple volume artifacts?
>
> 6)  Are volumes read-only? Or on cloning, make copies of them?
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev