Re: [Openstack-operators] reminder: ops meetups team meeting on #openstack-operators

[Chris Morgan]

Sure! Sounds good!

Chris

Sent from my iPhone

> On Oct 24, 2017, at 3:57 PM, Belmiro Moreira 
>  wrote:
> 
> Hi,
> can we add this meeting into the official IRC meetings page?
> https://wiki.openstack.org/wiki/Meetings
> http://eavesdrop.openstack.org/
> 
> thanks,
> Belmiro
> 
> 
> 
>> On Tue, 24 Oct 2017 at 15:51, Chris Morgan  wrote:
>> Next meeting in about 10 minutes from now
>> 
>> Chris
>> 
>> -- 
>> Chris Morgan 
>> ___
>> 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] Best practice against DDoS on openstack

[Blair Bethwaite]

Similarly, if you have the capability in your compute gear you could do
SR-IOV and push the problem entirely into the instance (but then you miss
out on Neutron secgroups and have to rely entirely on in-instance
firewalls).

Cheers,

On 25 October 2017 at 01:41, Jeremy Stanley  wrote:

> On 2017-10-24 20:18:30 +0900 (+0900), Jean-Philippe Méthot wrote:
> > We’ve just recently been hit on by a low-level DDoS on one of our
> > compute nodes. The attack was fulling our conntrack table while
> > having no noticeable impact on our server load, which is why it
> > took us a while to detect it. Is there any recommended practice
> > regarding server configuration to reduce the impact of a DDoS on
> > the whole compute node and thus, prevent it from going down? I
> > understand that increasing the size of the conntrack table is one,
> > but outside of that?
>
> You might want to look into using iptables -j REJECT -m connlimit
> --connlimit-above some threshold with matches for the individual
> ports' addresses... I'm not a heavy on this end of operations but
> others here probably know how to add hooks for something like that.
> Of course this only moves the denial of service down to the
> individual instance being targeted or used rather than knocking the
> entire compute node offline (hopefully anyway), and is no substitute
> for actual attack mitigation devices/services inline on the network.
> --
> Jeremy Stanley
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


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

[Openstack-operators] [publiccloud-wg] Reminder meeting PublicCloud WG

[Tobias Rydberg]

Hi everyone,

Don't forget tomorrows meeting for the PublicCloudWorkingGroup.
November 25th 1400 UTC  in IRC channel 
#openstack-meeting-3


Etherpad and agenda: https://etherpad.openstack.org/p/publiccloud-wg

Regards,
Tobias Rydberg


smime.p7s
Description: S/MIME Cryptographic Signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] reminder: ops meetups team meeting on #openstack-operators

[Belmiro Moreira]

Hi,
can we add this meeting into the official IRC meetings page?
https://wiki.openstack.org/wiki/Meetings
http://eavesdrop.openstack.org/

thanks,
Belmiro



On Tue, 24 Oct 2017 at 15:51, Chris Morgan  wrote:

> Next meeting in about 10 minutes from now
>
> Chris
>
> --
> Chris Morgan 
> ___
> 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] Ops Meetups team meeting 2017-10-24

[Chris Morgan]

Meeting minutes here:

Meeting ended Tue Oct 24 15:00:00 2017 UTC. Information about MeetBot at
http://wiki.debian.org/MeetBot . (v 0.1.4)
11:00 AM Minutes:
http://eavesdrop.openstack.org/meetings/ops_meetup_team/2017/ops_meetup_team.2017-10-24-14.00.html
11:00 AM Minutes (text):
http://eavesdrop.openstack.org/meetings/ops_meetup_team/2017/ops_meetup_team.2017-10-24-14.00.txt
11:00 AM Log:
http://eavesdrop.openstack.org/meetings/ops_meetup_team/2017/ops_meetup_team.2017-10-24-14.00.log.html

next week, amongst other topics, we are planning to discuss whether future
mid-cycle meetups should be co-located with PTG. Please join if you have an
opinion you wish to express on this (either way!).

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

Re: [Openstack-operators] Ocata provider network issue failing to raise interfaces

[Matthew Czajka]

Oh hey there Curtis!

> Basically I expect there is no dhcp service. Double check the network has
dhcp?

There's DHCP running on the net nodes, but the dhcp logs don't show any
errors or warnings

In the DHCP logs, the only difference I can see is when booting from
provider it says its building the host file in /var/lib/neutron/dhcp/ while
booting from a self-service network, it says building in /var/lib/neutron/.

I have enable_isolated_metadata = True in the dhcp config.  But I noticed
that the dnsmasq logs dont show a DHCPDISCOVER or OFFER for the provider IP
I try to boot with. It shows for a self-service network.

> You could test with a config drive if you wanted to verify, or don't want
dhcp service.

I don't want to use config drive since ceph is the backend, it might mess
up instance migrations I believe?

Thanks,
Matt


On Fri, Oct 20, 2017 at 2:09 PM, Curtis  wrote:

> On Thu, Oct 19, 2017 at 5:22 PM, Matthew Czajka 
> wrote:
> > Hi All,
> >
> >
> >
> > I’m running into an issue with a new Ocata deployment. I’m unable to
> boot an
> > instance directly from the provider network. Instance logs show that it
> > keeps repeating “failed to raise interfaces” so it doesn’t get an IP
> > assigned, and then can’t reach the metatdata servers.
> >
> >
> >
> > Booting an instance from a self-service network works fine, can ping
> other
> > internal IPs within the vlan, and can assign and use a floating IP.
> >
> >
> >
> > Deployment is running linux bridge, with a flat network for provider. 3
> > controllers, 3 network nodes, and 2 compute nodes. Using dhcpdump I can
> see
> > DHCP requests being made, but no acknowledgement afterwards. If I console
> > into the server and assign the public IP statically, that IP then works.
> > It’s only at boot (or reboot), that the instance can’t grab the IP.
> >
> >
> >
> > Any help would be appreciated, I’ve been banging my head over this for a
> > while.
>
> Hey Matt :),
>
> To get metadata there has to be a dhcp server or router configured, or
> use config drive. Presumably there is no dhcp service running via
> neutron in your situation, so it can't get an IP nor the metadata
> route injected. You could test with a config drive if you wanted to
> verify, or don't want dhcp service. Sometimes organizations refuse
> dhcp services on networks, but I'm guessing that is not the case in
> this situation.
>
> Basically I expect there is no dhcp service. Double check the network has
> dhcp?
>
> Thanks,
> Curtis.
>
> >
> >
> >
> > Thanks,
> >
> > Matt C
> >
> >
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
>
>
> --
> Blog: serverascode.com
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [User-committee] UC IRC Meetings on new schedule and new channel

[Edgar Magana]

Folks,

Per our meeting discussion on 10/16:
http://eavesdrop.openstack.org/meetings/uc/2017/uc.2017-10-16-18.03.log.html#l-100

We will start having UC IRC meetings in two different times and we need to move 
our meeting from the #openstack-meeting channel to #openstack-uc
This is the commit for the change:
https://review.openstack.org/#/c/513863/

UC Members, please review and approve this change.

Thanks,

UC Team


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

Re: [Openstack-operators] Best practice against DDoS on openstack

[Jeremy Stanley]

On 2017-10-24 20:18:30 +0900 (+0900), Jean-Philippe Méthot wrote:
> We’ve just recently been hit on by a low-level DDoS on one of our
> compute nodes. The attack was fulling our conntrack table while
> having no noticeable impact on our server load, which is why it
> took us a while to detect it. Is there any recommended practice
> regarding server configuration to reduce the impact of a DDoS on
> the whole compute node and thus, prevent it from going down? I
> understand that increasing the size of the conntrack table is one,
> but outside of that?

You might want to look into using iptables -j REJECT -m connlimit
--connlimit-above some threshold with matches for the individual
ports' addresses... I'm not a heavy on this end of operations but
others here probably know how to add hooks for something like that.
Of course this only moves the denial of service down to the
individual instance being targeted or used rather than knocking the
entire compute node offline (hopefully anyway), and is no substitute
for actual attack mitigation devices/services inline on the network.
-- 
Jeremy Stanley


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

[Openstack-operators] reminder: ops meetups team meeting on #openstack-operators

[Chris Morgan]

Next meeting in about 10 minutes from now

Chris

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

[Openstack-operators] Best practice against DDoS on openstack

[Jean-Philippe Méthot]

Hi all,

We’ve just recently been hit on by a low-level DDoS on one of our compute 
nodes. The attack was fulling our conntrack table while having no noticeable 
impact on our server load, which is why it took us a while to detect it. Is 
there any recommended practice regarding server configuration to reduce the 
impact of a DDoS on the whole compute node and thus, prevent it from going 
down? I understand that increasing the size of the conntrack table is one, but 
outside of that?

Best regards,

Jean-Philippe Méthot
Openstack system administrator
Administrateur système Openstack
PlanetHoster inc.




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

Re: [Openstack-operators] [Ceilometer][Hardware] ERROR ceilometer.hardware.pollsters.generic NoMatches: No 'ceilometer.hardware.inspectors' driver found

[andres sanchez ramos]

Hello Gordon,


I had tried to configure my pipeline so it would also gather information from 
ODL since i was trying to get as much information as possible. I commented out 
everything related to ODL and the errors stopped. Any ideas about the cause of 
this behavior? I am attaching :


- My pipeline file (with the ODL part commented out).

- An extract of the output I was getting before.

- The output after commenting ODL part.


Best regards,



On 2017-10-19 09:20 AM, andres sanchez ramos wrote:
> Hello,
>
>
> I have been trying to modify my ceilometer setup in order to include
> hardware measurement but have not been able to do so. Looking into the
> logs there are a lot of errors like this:
>
>
> 2017-10-19 12:09:46.467 30274 ERROR ceilometer.agent.manager NoMatches:
> No 'ceilometer.hardware.inspectors' driver found, looking for 'opendaylight'
>
>
> I have correctly set up SNMP since i am able to do "snmpwalk" correctly
> so I suspect my problem is in the pipeline or ceilometer.conf files. If
> someone can please share the proper way to set up this files i would
> appreciate it.
>
>
> I included this in my pipeline:
>
>
>  - name: meter_snmp
>interval: 600
>resources:
>- snmp://community@x.x.x.x
>meters:
>- "hardware.cpu*"
>- "hardware.memory*"
>- "hardware.disk*"
>- "hardware.network*"
>sinks:
>- meter_sink
>

are you sure your agent is pointing to that pipeline.yaml? it says it's
looking for opendaylight.

--
gord


Enviado desde Outlook


pipeline.yaml
Description: pipeline.yaml


CeilometerOutput_NoErrors
Description: CeilometerOutput_NoErrors


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