Re: [Openstack-operators] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested

[Zeng, Bryant]

@Maish Saidel-Keesing,

Hi Maish, I’m from eBay Inc, and we’re enabling 1000+ ceilometer compute 
agents. Hope our experience could help.

We choose an OpenTSDB backend instead of MongoDB in the first place, so we 
avoid of most of the issues related to MongoDB.

However, during deployment, we still met many issues as below:

  1.  The inspector of libvirt didn’t work in nova-cell mode. We fixed it by 
using instance uuid to identify vm, and submitted to upstream. 
(https://bugs.launchpad.net/ceilometer/+bug/1396473)
  2.  There’s huge load to nova/glance client that even drag them down. We 
resolved it in 3 ways as below to reduce the load:
 *   Shuffle compute agents triggering time to avoid same time requests to 
nova client., and it’s already got approved and merged in upstream. 
(https://bugs.launchpad.net/ceilometer/+bug/1412613)
 *   Add cache layer for nova discovery results of instances, this would 
reduce quite a lot queries to nova client. It’s still in discussing with 
upstream. (https://review.openstack.org/#/c/153503/)
 *   Remove flavor and image query for vm since we didn't need the info now.

Our original thinking about MongoDB is to only store some metadata definition, 
and put most other metrics to a time series db.

So all in all, we think probably you can consider to change your main storage 
backend MongoDB, and that may improve your Ceilometer performance.
Also some performance related code enhance/modification based on your 
conditions would be better.

Thanks,
Bryant(Cloud Team, eBay Inc)

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

Re: [Openstack-operators] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested

[George Shuklin]

Ceilometer is in sad state.

1. Collector leaks memory. We ran it on same host with mongo, and it 
grab 29Gb out of 32, leaving mongo with less than gig memory available.
2. Metering agent cause huge load on neutron-server. o(n) of metering 
rules and tenants. Few bugs reported, one bugfix in review.
3. Metering agent simply do no work on multi-network-nodes installation. 
It exepects all routers be on same host. Fixed or not - I don't know, we 
have our own crude fix.
4. Many rough edges. Ceilometer much less tested than nova. Sometimes it 
traces and skip counting. Fresh example: if metadata has '.' in the 
name, ceilometer trace on it and did not count in glance usage.

5. Very slow on reports (using mongo's mapreduce).

Overall feeling: barely usable, but with my experience with cloud 
billings, not the worst thing I saw in my life.


About load: except reporting and memory leaks, it use rather small 
amount of resources.


On 02/11/2015 09:37 PM, Maish Saidel-Keesing wrote:

Is Ceilometer ready for prime time?

I would be interested in hearing from people who have deployed 
OpenStack clouds with Ceilometer, and their experience. Some of the 
topics I am looking for feedback on are:


- Database Size
- MongoDB management, Sharding, replica sets etc.
- Replication strategies
- Database backup/restore
- Overall useability
- Gripes, pains and problems (things to look out for)
- Possible replacements for Ceilometer that you have used instead


If you are willing to share - I am sure it will be beneficial to the 
whole community.


Thanks in Advance


With best regards,


Maish Saidel-Keesing
Platform Architect
Cisco




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



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

[Openstack-operators] qvb level filter

[Yaron Illouz]

Title:  qvb level filter








Hi



I am trying to do port mirroring between vms.

I did it with the openvswitch.

Packet are copied to the mirrored qvo, but then stop at the qvb Rx. I don't see where it is stuck.

>From iptable output it dosen't seem to be drop in one of the chain or many packet in fallback.

Iptables are at qvb level? If not so what block my packets





You can see only 201 packet reach qbr but more than 72 Million packet arrived to qvb

ifconfig | grep -A 5 3ede5b3

qbr3ede5b3e-39: flags=4163  mtu 1500

    inet6 fe80::e4ae:56ff:fe5f:137d  prefixlen 64  scopeid 0x20

    ether aa:8c:e8:75:72:d2  txqueuelen 0  (Ethernet)

    RX packets 201  bytes 16528 (16.1 KiB)

    RX errors 0  dropped 0  overruns 0  frame 0

    TX packets 8  bytes 648 (648.0 B)

--

qvb3ede5b3e-39: flags=4419  mtu 1500

    inet6 fe80::a88c:e8ff:fe75:72d2  prefixlen 64  scopeid 0x20

    ether aa:8c:e8:75:72:d2  txqueuelen 1000  (Ethernet)

    RX packets 72789130  bytes 20271610754 (18.8 GiB)

    RX errors 0  dropped 0  overruns 0  frame 0

    TX packets 30  bytes 3394 (3.3 KiB)

--

qvo3ede5b3e-39: flags=4419  mtu 1500

    inet6 fe80::c70:cff:fef0:d432  prefixlen 64  scopeid 0x20

    ether 0e:70:0c:f0:d4:32  txqueuelen 1000  (Ethernet)

    RX packets 30  bytes 3394 (3.3 KiB)

    RX errors 0  dropped 0  overruns 0  frame 0

    TX packets 72789140  bytes 20271612780 (18.8 GiB)

--

tap3ede5b3e-39: flags=4163  mtu 1500

    inet6 fe80::fc16:3eff:fe3b:34de  prefixlen 64  scopeid 0x20

    ether fe:16:3e:3b:34:de  txqueuelen 500  (Ethernet)

    RX packets 15  bytes 2188 (2.1 KiB)

    RX errors 0  dropped 0  overruns 0  frame 0

    TX packets 3526  bytes 91 (944.0 KiB)





Neutron port list

| 3ede5b3e-396e-48a9-b24a-6cb2dc7509fe |  | fa:16:3e:3b:34:de | {"subnet_id": "f960ee77-77a8-45c1-8eef-e3878f0bea9f", "ip_address": "10.67.82.2"}  |

| 435f35c6-80be-47ee-b30f-8376e1ea78d9 |  | fa:16:3e:41:fd:59 | {"subnet_id": "f960ee77-77a8-45c1-8eef-e3878f0bea9f", "ip_address": "10.67.82.5"}  |

| 89193daa-bf67-4237-8045-30a6e3c107a2 |  | fa:16:3e:a5:56:38 | {"subnet_id": "f960ee77-77a8-45c1-8eef-e3878f0bea9f", "ip_address": "10.67.82.4"}  |

| bd80bab5-424d-4e5c-8993-b8bb8c6f3e49 |  | fa:16:3e:f7:4f:ea | {"subnet_id": "f960ee77-77a8-45c1-8eef-e3878f0bea9f", "ip_address": "10.67.82.3"}  |





Command that I ran

ovs-vsctl -- set Bridge br-int mirrors=@m  -- --id=@qvobd80bab5-42 get Port  qvobd80bab5-42 -- --id=@qvo3ede5b3e-39 get Port qvo3ede5b3e-39 -- --id=@m create Mirror name=mymirror select-dst-port=@qvobd80bab5-42 select-src-port=@qvobd80bab5-42 output-port=@qvo3ede5b3e-39





This is iptables output filtered, you can see I added a allowed address pair.

3 3518  919K neutron-openvswi-sg-chain  all  --  *  *   0.0.0.0/0    0.0.0.0/0    PHYSDEV match --physdev-out tap3ede5b3e-39 --physdev-is-bridged

4    4  1358 neutron-openvswi-sg-chain  all  --  *  *   0.0.0.0/0    0.0.0.0/0    PHYSDEV match --physdev-in tap3ede5b3e-39 --physdev-is-bridged



Chain neutron-openvswi-INPUT (1 references)

--

2    0 0 neutron-openvswi-o3ede5b3e-3  all  --  *  *   0.0.0.0/0    0.0.0.0/0    PHYSDEV match --physdev-in tap3ede5b3e-39 --physdev-is-bridged

3    0 0 neutron-openvswi-o7e200e92-4  all  --  *  *   0.0.0.0/0    0.0.0.0/0    PHYSDEV match --physdev-in tap7e200e92-44 --physdev-is-bridged

4    0 0 neutron-openvswi-o435f35c6-8  all  --  *  *   0.0.0.0/0    0.0.0.0/0    PHYSDEV match --physdev-in tap435f35c6-80 --physdev-is-bridged

5    0 0 neutron-openvswi-o6a1bb345-9  all  --  *  *   0.0.0.0/0    0.0.0.0/0    PHYSDEV match --physdev-in tap6a1bb345-93 --physdev-is-bridged

6    0 0 neutron-openvswi-ofc0a7800-a  all  --  *  *   0.0.0.0/0    0.0.0.0/0    PHYSDEV match --physdev-in tapfc0a7800-a0 --physdev-is-bridged



Chain neutron-openvswi-OUTPUT (1 references)

num   pkts bytes target prot opt in out source   destination



Chain neutron-openvswi-i3ede5b3e-3 (1 references)

num   pkts bytes target prot opt in out source   destination

1    0 0 DROP   all  --  *  *   0.0.0.0/0    0.0.0.0/0    state INVALID

2   91  8550 RETURN all  --  *  *   0.0.0.0/0    0.0.0.0/0    state RELATED,ESTABLISHED

3    0 0 RETURN udp  --  *  *   10.67.82.4   0.0.0.0/0    udp spt:67 dpt:68

4    0 0 RETURN icmp --  *  *   0.0.0.0/0    0.0.0.0/0

5    0 0 RETURN tcp  --  *  *   0.0.0.0/0    0.0.0.0/0    tcp multiport dports 1:65535

6 3416  907K RETURN all  --  *  *   0.0.0.0/0    0.0.0.0/0  

Re: [Openstack-operators] [cinder] Driver Filters and Goodness Weighers... Who plans to use this?

[Richard Raseley]

Marc Heckmann wrote:
> I can definitely relate to the problem that it's trying to solve. We
> have a backend that has both thin-provisioning and compression. Right
> now, we have no easy way to filter which storage node that a volume
> should be created on if compression and thin provisioning is to be
> taken into account. That being said, I'm not sure about the
> implementation as such. I could see how it needs to remain flexible to
> accommodate a bunch of different types of drivers. I suppose that it's
> a start. -m
I agree with the substance of Marc's remarks. There is clearly value for
being able to discriminate between various storage backends
transparently (from the user's perspective at least). That being said, I
am not in a position to judge the quality of the code or cleanliness of
integration.

Regards,

Richard Raseley

SysOps Engineer
Puppet Labs
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[matt]

Jesse the AMT looks like it may work in so far as functionality... but it
requires unix utility amttool in place of ipmitool.

I'll report back on how these work for me.. I just ordered 4 for testing.

Only that one model of the NUCs has AMT support with vpro on it.  So if you
do go nuc

http://www.intel.com/content/www/us/en/nuc/nuc-kit-dc53427hye.html

That's the unit you want.

On Wed, Feb 11, 2015 at 3:28 PM, Jesse Keating  wrote:

> On 2/11/15 12:19 PM, Abel Lopez wrote:
>
>> There is DIY LOM for the NUC, it was demo'd at Paris Summit. It was
>> quite elegant, featuring LEGO Mindstorm robots being instructed to push
>> the power button.
>>
>>
> Remote power is not LOM. Remote power could be done with a sufficient
> power strip. Real LOM is required to demo these as a baremetal (ironic)
> target.
>
> --
> -jlk
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[matt]

Okay for clarity... a mechanical solution to pushing the buttons on the NUC
is of Rube Goldberg complexity.  It is completely unnecessary and
hellaciously prone to failure.

You can literally wire into where the on / off switch is... or optimally
directly to the jumper on the board itself with a microcontroller ( i'd use
a beaglebone black personally for the ethernet port mainly ) .  Then you
can use a GPIO pin to switch the board on and off.  More so, you can wire
the GPIO ( at 5v ) to a mechanical relay in line with the 110/220v+ line
and get hard cycling added as a capability.  Using mindstorms for this is
neat, but frankly way overly complex and less useful.

Hell if you were crazy you could wire up a usb hub to some ttyusb -> db9
cables and host it to the beaglebone as well for serial console.

Go still further down the path to damned near implementing your own IPMI
solution you could directly parasite into the on board sensors and read
them direct.

Going the final leg of the journey... you could directly ADC the VGA port
and soft render that into a RDP window along with some sort of API -> USB
HID device stack... and bob's your uncle you've built your own LOM board.
Then all you need to do is re-implement IPMI protocol and tie it to the
hardware.

Half way to an open source LOM board at that point.

But honestly, with AMT that's not really necessary here.

Still... open source LOM would be nice.

-matt

On Wed, Feb 11, 2015 at 3:19 PM, Abel Lopez  wrote:

> There is DIY LOM for the NUC, it was demo'd at Paris Summit. It was quite
> elegant, featuring LEGO Mindstorm robots being instructed to push the power
> button.
>
> On Feb 11, 2015, at 9:12 AM, Will Snow (wasnow)  wrote:
>
>  So as to 10g, it’s not like I’m going to use them for production :)
>
>  I do miss LOM on the boxes tho – the dual interface would be nice, but I
> can work around that.
> I have a covey (pod? Gaggle?) of 4 NUCs with 1 being the master to deploy
> the others. That master has 2 nics (built in 1g, wifi) so you can very
> easily connect your cloud to your network.
>
>  This allows my developers to test real multinode deploys of openstack
> repeatedly without the expense of 3 rack servers, and they can carry around
> the cloud to meetups or whereever they want to go.
>
>  There are a few tweaks to what we’re doing that are based on feedback
> from what we’ve built already. I use the NUCs as the price point is good,
> and Intel is down the street from me :)
>
>  Shameless plug: more details in our talk at the vancouver if it gets
> accepted.
>
>   --Will Snow
> was...@cisco.com
> Director, OpenStack Customer Engineering
> Mobile: +1-650-544-5460
>
>   From: matt
> Date: Wednesday, February 11, 2015 at 8:30 AM
> To: will snow
> Cc: Christian Berendt, "openstack-operators@lists.openstack.org"
> Subject: Re: [Openstack-operators] demo environment ( embedded device
> openstack ) ?
>
>   3)  no 10 gig.
>
> On Wed, Feb 11, 2015 at 11:29 AM, matt  wrote:
>
>>  i dislike 2 things about the NUCs...
>>
>>  1)  only a single interface
>>  2)  no lights out management
>>
>> =/
>>
>> On Wed, Feb 11, 2015 at 11:06 AM, Will Snow (wasnow) 
>> wrote:
>>
>>> Yes, I was considering waiting for the new NUCs but they’re March
>>> (scheduled) which means general availability sometime after that.
>>> Which would make things a bit tight for my talk at Vancouver (if it gets
>>> accepted)
>>>
>>> --Will Snow
>>> was...@cisco.com
>>> Director, OpenStack Customer Engineering
>>> Mobile: +1-650-544-5460
>>>
>>>
>>>
>>>
>>>
>>>
>>>  On 2/11/15, 3:33 AM, "Christian Berendt"  wrote:
>>>
>>> >On 02/06/2015 10:27 PM, Will Snow (wasnow) wrote:
>>> >> I’ve been building out a small cluster of intel NUC’s and have been
>>> >> quite happy with them – reasonable performance, 16g ram, and usb3 if
>>> you
>>> >> need storage.
>>> >
>>> >I think NUCs are a greate choice.
>>> >
>>> >According to
>>> >
>>> http://liliputing.com/2015/01/intel-unveils-nuc-mini-pc-core-i7-broadwell
>>> .
>>> >html
>>> >NUCs with i7 CPUs should be released this year.
>>> >
>>> >More details at
>>> >http://www.intel.com/content/www/us/en/nuc/products-overview.html.
>>> >
>>> >Christian.
>>> >
>>> >___
>>> >OpenStack-operators mailing list
>>> >OpenStack-operators@lists.openstack.org
>>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>>
>___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/o

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[Jesse Keating]

On 2/11/15 12:19 PM, Abel Lopez wrote:

There is DIY LOM for the NUC, it was demo'd at Paris Summit. It was
quite elegant, featuring LEGO Mindstorm robots being instructed to push
the power button.



Remote power is not LOM. Remote power could be done with a sufficient 
power strip. Real LOM is required to demo these as a baremetal (ironic) 
target.


--
-jlk

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

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[Abel Lopez]

There is DIY LOM for the NUC, it was demo'd at Paris Summit. It was quite 
elegant, featuring LEGO Mindstorm robots being instructed to push the power 
button.

> On Feb 11, 2015, at 9:12 AM, Will Snow (wasnow)  wrote:
> 
> So as to 10g, it’s not like I’m going to use them for production :)
> 
> I do miss LOM on the boxes tho – the dual interface would be nice, but I can 
> work around that.
> I have a covey (pod? Gaggle?) of 4 NUCs with 1 being the master to deploy the 
> others. That master has 2 nics (built in 1g, wifi) so you can very easily 
> connect your cloud to your network.
> 
> This allows my developers to test real multinode deploys of openstack 
> repeatedly without the expense of 3 rack servers, and they can carry around 
> the cloud to meetups or whereever they want to go.
> 
> There are a few tweaks to what we’re doing that are based on feedback from 
> what we’ve built already. I use the NUCs as the price point is good, and 
> Intel is down the street from me :)
> 
> Shameless plug: more details in our talk at the vancouver if it gets accepted.
> 
> --Will Snow
> was...@cisco.com
> Director, OpenStack Customer Engineering
> Mobile: +1-650-544-5460
> 
> From: matt
> Date: Wednesday, February 11, 2015 at 8:30 AM
> To: will snow
> Cc: Christian Berendt, "openstack-operators@lists.openstack.org 
> "
> Subject: Re: [Openstack-operators] demo environment ( embedded device 
> openstack ) ?
> 
> 3)  no 10 gig.
> 
> On Wed, Feb 11, 2015 at 11:29 AM, matt  > wrote:
> i dislike 2 things about the NUCs...
> 
> 1)  only a single interface
> 2)  no lights out management
> 
> =/
> 
> On Wed, Feb 11, 2015 at 11:06 AM, Will Snow (wasnow)  > wrote:
> Yes, I was considering waiting for the new NUCs but they’re March
> (scheduled) which means general availability sometime after that.
> Which would make things a bit tight for my talk at Vancouver (if it gets
> accepted)
> 
> --Will Snow
> was...@cisco.com 
> Director, OpenStack Customer Engineering
> Mobile: +1-650-544-5460 
> 
> 
> 
> 
> 
> 
> On 2/11/15, 3:33 AM, "Christian Berendt"  > wrote:
> 
> >On 02/06/2015 10:27 PM, Will Snow (wasnow) wrote:
> >> I’ve been building out a small cluster of intel NUC’s and have been
> >> quite happy with them – reasonable performance, 16g ram, and usb3 if you
> >> need storage.
> >
> >I think NUCs are a greate choice.
> >
> >According to
> >http://liliputing.com/2015/01/intel-unveils-nuc-mini-pc-core-i7-broadwell 
> >.
> >html
> >NUCs with i7 CPUs should be released this year.
> >
> >More details at
> >http://www.intel.com/content/www/us/en/nuc/products-overview.html 
> >.
> >
> >Christian.
> >
> >___
> >OpenStack-operators mailing list
> >OpenStack-operators@lists.openstack.org 
> >
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
> >
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
> 
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[matt]

yeah i found that and was reading... i mean it sucks it's not ipmi
compatible... but at least it's something.

would NEVER use in prod without interface isolation.  but for a demo
rig it kinda works.

still wish the nuc had a second interface... even more so now.

-matt

On Wed, Feb 11, 2015 at 2:51 PM, Jeremy Stanley  wrote:

> On 2015-02-11 12:27:42 -0500 (-0500), matt wrote:
> > the lack of lom is... difficult in this use case.  more so than
> > any of the other 3 defficiencies i listed.
> [...]
>
> According to a little searching, it seems that the Ivy Bridge based
> i5 NUCs (not the Haswell based ones) have Intel AMT support. This
> blog post is somewhat encouraging:
>
>  http://blog.dustinkirkland.com/2013/12/everything-you-need-to-know-about-intel.html
> >
>
> --
> Jeremy Stanley
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[Jeremy Stanley]

On 2015-02-11 12:27:42 -0500 (-0500), matt wrote:
> the lack of lom is... difficult in this use case.  more so than
> any of the other 3 defficiencies i listed.
[...]

According to a little searching, it seems that the Ivy Bridge based
i5 NUCs (not the Haswell based ones) have Intel AMT support. This
blog post is somewhat encouraging:

http://blog.dustinkirkland.com/2013/12/everything-you-need-to-know-about-intel.html
 >

-- 
Jeremy Stanley

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

[Openstack-operators] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested

[Maish Saidel-Keesing]

Is Ceilometer ready for prime time?

I would be interested in hearing from people who have deployed OpenStack 
clouds with Ceilometer, and their experience. Some of the topics I am 
looking for feedback on are:


- Database Size
- MongoDB management, Sharding, replica sets etc.
- Replication strategies
- Database backup/restore
- Overall useability
- Gripes, pains and problems (things to look out for)
- Possible replacements for Ceilometer that you have used instead


If you are willing to share - I am sure it will be beneficial to the 
whole community.


Thanks in Advance


With best regards,


Maish Saidel-Keesing
Platform Architect
Cisco




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

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[matt]

http://www.intel.com/content/www/us/en/nuc/nuc-kit-dc53427hye.html  has
intel AMT apparently.  this is an intel only lom like thing.

On Wed, Feb 11, 2015 at 1:55 PM, matt  wrote:

> for the record rebot is a terrible solution.  Any mcu's gpio should be
> able to take over for the on / off switch and provide digital control of
> the power on.  also you could add in power line relays very easily for hard
> reboots.
>
> the trick is terminal services and vga bios output.  how do you reset bios
> configs remotely?  how do you get serial console?
>
> that's tricky.
>
> -matt
>
> On Wed, Feb 11, 2015 at 1:42 PM, Christian Berendt 
> wrote:
>
>> On 02/11/2015 05:29 PM, matt wrote:
>> > 2)  no lights out management
>>
>> If you only have to turn on/off the NUCs have a look at reBot provided
>> by cloudbase.
>>
>> http://www.cloudbase.it/rebot/
>>
>> Christian.
>>
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [cinder] Driver Filters and Goodness Weighers... Who plans to use this?

[Marc Heckmann]

Hi,

On Wed, 2015-02-11 at 12:39 +0100, Christian Berendt wrote:
> On 02/11/2015 07:54 AM, Mike Perez wrote:
> > Proposed Documentation:
> > http://thing.ee/x/doc-20150210/content/driver_filter_weighing.html
> 
> Thank you for bringing this to the attention of this list. There is a
> pending review for this documentation available at
> https://review.openstack.org/#/c/152325/.
> 
> Christian.
> 

I can definitely relate to the problem that it's trying to solve. We
have a backend that has both thin-provisioning and compression. Right
now, we have no easy way to filter which storage node that a volume
should be created on if compression and thin provisioning is to be taken
into account.

That being said, I'm not sure about the implementation as such. I could
see how it needs to remain flexible to accommodate a bunch of different
types of drivers.

I suppose that it's a start.

-m

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


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

Re: [Openstack-operators] Neutron db syncs

[Jesse Keating]

On 2/11/15 11:10 AM, Kris G. Lindgren wrote:

Does anyone know why under Juno (and I assume above) - you need to
install *ALL* of the plugins in order to do a db_sync?  This seems
broken considering that we pass the config file in as a command line
parameter.  The db_sync code should know what plugins we are running and
only apply things that matter for that plugin.

To do the icehouse -> juno upgrade we are basically installing all the
neutron plugins on a single node, doing the db sync, then removing all
the unnecessary plugins again.


We aren't seeing this.

We're going from havana to juno, using the ml2 plugin. We just reference 
neutron.conf and ml2.ini


First we stamp it

https://github.com/blueboxgroup/ursula/blob/master/upgrade.yml#L234

then we sync it

https://github.com/blueboxgroup/ursula/blob/master/roles/neutron-control/tasks/main.yml#L25

--
-jlk

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

[Openstack-operators] Neutron db syncs

[Kris G. Lindgren]

Does anyone know why under Juno (and I assume above) - you need to install 
*ALL* of the plugins in order to do a db_sync?  This seems broken considering 
that we pass the config file in as a command line parameter.  The db_sync code 
should know what plugins we are running and only apply things that matter for 
that plugin.

To do the icehouse -> juno upgrade we are basically installing all the neutron 
plugins on a single node, doing the db sync, then removing all the unnecessary 
plugins again.


Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.

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

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[matt]

for the record rebot is a terrible solution.  Any mcu's gpio should be able
to take over for the on / off switch and provide digital control of the
power on.  also you could add in power line relays very easily for hard
reboots.

the trick is terminal services and vga bios output.  how do you reset bios
configs remotely?  how do you get serial console?

that's tricky.

-matt

On Wed, Feb 11, 2015 at 1:42 PM, Christian Berendt 
wrote:

> On 02/11/2015 05:29 PM, matt wrote:
> > 2)  no lights out management
>
> If you only have to turn on/off the NUCs have a look at reBot provided
> by cloudbase.
>
> http://www.cloudbase.it/rebot/
>
> Christian.
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[matt]

i mean for on and off i can just install a networked mcu.  that's easy.

On Wed, Feb 11, 2015 at 1:42 PM, Christian Berendt 
wrote:

> On 02/11/2015 05:29 PM, matt wrote:
> > 2)  no lights out management
>
> If you only have to turn on/off the NUCs have a look at reBot provided
> by cloudbase.
>
> http://www.cloudbase.it/rebot/
>
> Christian.
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[Christian Berendt]

On 02/11/2015 05:29 PM, matt wrote:
> 2)  no lights out management

If you only have to turn on/off the NUCs have a look at reBot provided
by cloudbase.

http://www.cloudbase.it/rebot/

Christian.

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

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[matt]

the lack of lom is... difficult in this use case.  more so than any of the
other 3 defficiencies i listed.

I wonder if an after market lom board exists.

On Wed, Feb 11, 2015 at 12:19 PM, Jesse Keating  wrote:

> On 2/11/15 9:12 AM, Will Snow (wasnow) wrote:
>
>> I do miss LOM on the boxes tho – the dual interface would be nice, but I
>> can work around that.
>> I have a covey (pod? Gaggle?) of 4 NUCs with 1 being the master to
>> deploy the others. That master has 2 nics (built in 1g, wifi) so you can
>> very easily connect your cloud to your network.
>>
>> This allows my developers to test real multinode deploys of openstack
>> repeatedly without the expense of 3 rack servers, and they can carry
>> around the cloud to meetups or whereever they want to go.
>>
>
> Unfortunately, part of our real multinode deployment scenarios include
> utilizing LOM as part of the deployment. That would make these unsuitable
> for such testing :/
>
> --
> -jlk
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[Jesse Keating]

On 2/11/15 9:12 AM, Will Snow (wasnow) wrote:

I do miss LOM on the boxes tho – the dual interface would be nice, but I
can work around that.
I have a covey (pod? Gaggle?) of 4 NUCs with 1 being the master to
deploy the others. That master has 2 nics (built in 1g, wifi) so you can
very easily connect your cloud to your network.

This allows my developers to test real multinode deploys of openstack
repeatedly without the expense of 3 rack servers, and they can carry
around the cloud to meetups or whereever they want to go.


Unfortunately, part of our real multinode deployment scenarios include 
utilizing LOM as part of the deployment. That would make these 
unsuitable for such testing :/


--
-jlk

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

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[Will Snow (wasnow)]

So as to 10g, it’s not like I’m going to use them for production :)

I do miss LOM on the boxes tho – the dual interface would be nice, but I can 
work around that.
I have a covey (pod? Gaggle?) of 4 NUCs with 1 being the master to deploy the 
others. That master has 2 nics (built in 1g, wifi) so you can very easily 
connect your cloud to your network.

This allows my developers to test real multinode deploys of openstack 
repeatedly without the expense of 3 rack servers, and they can carry around the 
cloud to meetups or whereever they want to go.

There are a few tweaks to what we’re doing that are based on feedback from what 
we’ve built already. I use the NUCs as the price point is good, and Intel is 
down the street from me :)

Shameless plug: more details in our talk at the vancouver if it gets accepted.

--Will Snow
was...@cisco.com
Director, OpenStack Customer Engineering
Mobile: +1-650-544-5460

From: matt
Date: Wednesday, February 11, 2015 at 8:30 AM
To: will snow
Cc: Christian Berendt, 
"openstack-operators@lists.openstack.org"
Subject: Re: [Openstack-operators] demo environment ( embedded device openstack 
) ?

3)  no 10 gig.

On Wed, Feb 11, 2015 at 11:29 AM, matt 
mailto:m...@nycresistor.com>> wrote:
i dislike 2 things about the NUCs...

1)  only a single interface
2)  no lights out management

=/

On Wed, Feb 11, 2015 at 11:06 AM, Will Snow (wasnow) 
mailto:was...@cisco.com>> wrote:
Yes, I was considering waiting for the new NUCs but they’re March
(scheduled) which means general availability sometime after that.
Which would make things a bit tight for my talk at Vancouver (if it gets
accepted)

--Will Snow
was...@cisco.com
Director, OpenStack Customer Engineering
Mobile: +1-650-544-5460






On 2/11/15, 3:33 AM, "Christian Berendt" 
mailto:christ...@berendt.io>> wrote:

>On 02/06/2015 10:27 PM, Will Snow (wasnow) wrote:
>> I’ve been building out a small cluster of intel NUC’s and have been
>> quite happy with them – reasonable performance, 16g ram, and usb3 if you
>> need storage.
>
>I think NUCs are a greate choice.
>
>According to
>http://liliputing.com/2015/01/intel-unveils-nuc-mini-pc-core-i7-broadwell.
>html
>NUCs with i7 CPUs should be released this year.
>
>More details at
>http://www.intel.com/content/www/us/en/nuc/products-overview.html.
>
>Christian.
>
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


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

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[matt]

i dislike 2 things about the NUCs...

1)  only a single interface
2)  no lights out management

=/

On Wed, Feb 11, 2015 at 11:06 AM, Will Snow (wasnow) 
wrote:

> Yes, I was considering waiting for the new NUCs but they’re March
> (scheduled) which means general availability sometime after that.
> Which would make things a bit tight for my talk at Vancouver (if it gets
> accepted)
>
> --Will Snow
> was...@cisco.com
> Director, OpenStack Customer Engineering
> Mobile: +1-650-544-5460
>
>
>
>
>
>
> On 2/11/15, 3:33 AM, "Christian Berendt"  wrote:
>
> >On 02/06/2015 10:27 PM, Will Snow (wasnow) wrote:
> >> I’ve been building out a small cluster of intel NUC’s and have been
> >> quite happy with them – reasonable performance, 16g ram, and usb3 if you
> >> need storage.
> >
> >I think NUCs are a greate choice.
> >
> >According to
> >http://liliputing.com/2015/01/intel-unveils-nuc-mini-pc-core-i7-broadwell
> .
> >html
> >NUCs with i7 CPUs should be released this year.
> >
> >More details at
> >http://www.intel.com/content/www/us/en/nuc/products-overview.html.
> >
> >Christian.
> >
> >___
> >OpenStack-operators mailing list
> >OpenStack-operators@lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[matt]

3)  no 10 gig.

On Wed, Feb 11, 2015 at 11:29 AM, matt  wrote:

> i dislike 2 things about the NUCs...
>
> 1)  only a single interface
> 2)  no lights out management
>
> =/
>
> On Wed, Feb 11, 2015 at 11:06 AM, Will Snow (wasnow) 
> wrote:
>
>> Yes, I was considering waiting for the new NUCs but they’re March
>> (scheduled) which means general availability sometime after that.
>> Which would make things a bit tight for my talk at Vancouver (if it gets
>> accepted)
>>
>> --Will Snow
>> was...@cisco.com
>> Director, OpenStack Customer Engineering
>> Mobile: +1-650-544-5460
>>
>>
>>
>>
>>
>>
>> On 2/11/15, 3:33 AM, "Christian Berendt"  wrote:
>>
>> >On 02/06/2015 10:27 PM, Will Snow (wasnow) wrote:
>> >> I’ve been building out a small cluster of intel NUC’s and have been
>> >> quite happy with them – reasonable performance, 16g ram, and usb3 if
>> you
>> >> need storage.
>> >
>> >I think NUCs are a greate choice.
>> >
>> >According to
>> >
>> http://liliputing.com/2015/01/intel-unveils-nuc-mini-pc-core-i7-broadwell
>> .
>> >html
>> >NUCs with i7 CPUs should be released this year.
>> >
>> >More details at
>> >http://www.intel.com/content/www/us/en/nuc/products-overview.html.
>> >
>> >Christian.
>> >
>> >___
>> >OpenStack-operators mailing list
>> >OpenStack-operators@lists.openstack.org
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[Will Snow (wasnow)]

Yes, I was considering waiting for the new NUCs but they’re March 
(scheduled) which means general availability sometime after that.
Which would make things a bit tight for my talk at Vancouver (if it gets 
accepted)

--Will Snow
was...@cisco.com
Director, OpenStack Customer Engineering
Mobile: +1-650-544-5460






On 2/11/15, 3:33 AM, "Christian Berendt"  wrote:

>On 02/06/2015 10:27 PM, Will Snow (wasnow) wrote:
>> I’ve been building out a small cluster of intel NUC’s and have been
>> quite happy with them – reasonable performance, 16g ram, and usb3 if you
>> need storage.
>
>I think NUCs are a greate choice.
>
>According to
>http://liliputing.com/2015/01/intel-unveils-nuc-mini-pc-core-i7-broadwell.
>html
>NUCs with i7 CPUs should be released this year.
>
>More details at
>http://www.intel.com/content/www/us/en/nuc/products-overview.html.
>
>Christian.
>
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [cinder] Driver Filters and Goodness Weighers... Who plans to use this?

[Christian Berendt]

On 02/11/2015 07:54 AM, Mike Perez wrote:
> Proposed Documentation:
> http://thing.ee/x/doc-20150210/content/driver_filter_weighing.html

Thank you for bringing this to the attention of this list. There is a
pending review for this documentation available at
https://review.openstack.org/#/c/152325/.

Christian.

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

Re: [Openstack-operators] demo environment ( embedded device openstack ) ?

[Christian Berendt]

On 02/06/2015 10:27 PM, Will Snow (wasnow) wrote:
> I’ve been building out a small cluster of intel NUC’s and have been
> quite happy with them – reasonable performance, 16g ram, and usb3 if you
> need storage.

I think NUCs are a greate choice.

According to
http://liliputing.com/2015/01/intel-unveils-nuc-mini-pc-core-i7-broadwell.html
NUCs with i7 CPUs should be released this year.

More details at
http://www.intel.com/content/www/us/en/nuc/products-overview.html.

Christian.

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

Re: [Openstack-operators] Openstack deployment tool advice

[Christian Berendt]

On 02/09/2015 12:38 PM, Pedro Sousa wrote:
> I'm looking into some options to deploy Openstack. I use RDO based Juno
> distro and had been using packstack tool (based on puppet) to deploy it,
> but it's not flexible enough as it lacks some features, as HA.

Packstack does not lack features like HA. HA is not in the scope of
Packstack. The scope of Packstack is to provide proof of concept
environments. The scope is not to provide production ready environments.

Christian.

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