date:20160602

Re: [Openstack-operators] problem with DVR in Kilo and floating IPs

2016-06-02 Thread Daniel Russell

Hi,

We have seen this kind of behaviour and it was because the qrouter had the 
following rules :

-A neutron-postrouting-bottom -m comment --comment "Perform source NAT on 
outgoing traffic." -j neutron-l3-agent-snat
-A neutron-l3-agent-snat -j neutron-l3-agent-float-snat
-A neutron-l3-agent-float-snat -s /32 -j SNAT --to-source 


That meant that whenever traffic wasn’t going between instances in the same 
network (ie. Had to go through the router), it would NAT it to the floating IP 
even if the other server was in a directly connected network.

To see if this is happening for you, you could try adding a rule in your 
security groups to allow VM1s floating IP to access VM2 and/or vice versa.  You 
could also do a tcpdump on the router’s interfaces to the networks to see if 
you are getting some translation issues.

Regards,
Dan.


From: Gustavo Randich [mailto:gustavo.rand...@gmail.com]
Sent: Friday, 3 June 2016 7:40 AM
To: openstack-operators@lists.openstack.org; openst...@lists.openstack.org
Subject: [Openstack-operators] problem with DVR in Kilo and floating IPs

Hi,

Using DVR in Kilo, I've the following issue:

- VM1 is in tenant network 1 (fixed IP 10.97.2.4)
- VM2 is in tenant network 2 (fixed IP 10.97.0.4)
- a router connects both networks
- VM1 and VM2 both have floating IPs
- I can ping from VM1 to VM2 using fixed / internal IP
- I cannot SSH from VM1 to VM2 using fixed IP, because of 
"ssh_exchange_identification: read: Connection reset by peer"
- iperf output between both VMs using fixed IP is strange (see below)

If I remove floating IP in VM2 (target VM), SSH and iperf begin to work OK

The problem is not present with two VM1 in the *same* tenant network and both 
having floating IPs

Any ideas?

Thanks!




VM1# tracepath 10.97.0.4
 1?: [LOCALHOST] pmtu 1500
 1:  10.97.2.1 0.322ms
 1:  10.97.2.1 0.436ms
 2:  10.97.0.4 0.962ms reached
 Resume: pmtu 1500 hops 2 back 4

VM1# ping 10.97.0.4
PING 10.97.0.4 (10.97.0.4) 56(84) bytes of data.
64 bytes from 10.97.0.4: icmp_seq=1 ttl=61 time=1.23 ms
^C
--- 10.97.0.4 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.231/1.231/1.231/0.000 ms

VM1# ssh 10.97.0.4
ssh_exchange_identification: read: Connection reset by peer

VM1# iperf -c 10.97.0.4

Client connecting to 10.97.0.4, TCP port 5001
TCP window size: 85.0 KByte (default)

[  3] local 10.97.2.4 port 47014 connected with 10.97.0.4 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec  0.00 ▒ ▒▒s  14746824734997131264 Bytes/sec





VM2# # iperf -s

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)

[  4] local 10.97.0.4 port 5001 connected with 10.182.0.58 port 47014
[ ID] Interval   Transfer Bandwidth
[  4]  0.0- 0.0 sec  14.1 KBytes  9.36 Mbits/sec

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

[Openstack-operators] oslo_messaging, rabbit, ssl and mitaka and xenial

2016-06-02 Thread Sam Morrison

Hi all,

We’ve been trying out some mitaka packages as well as some Xenial hosts and 
have been having some issues with rabbit and SSL.

If using rabbitMQ 3.6.x on Trusty I can’t get a mitaka host (oslo_messaging 
4.6.1, python-amqp 1.4.9) to connect to rabbit over SSL. 

If I use rabbitMQ 3.6.x on Xenial I can get it to work BUT I need to change 
some settings on rabbit to allow some weaker ciphers.

I had to add the following to rabbitmq.config (found on some random blog and 
haven’t investigated what exactly needed to change sorry)

{versions, ['tlsv1.2', 'tlsv1.1', tlsv1]},
{ciphers, 
["ECDHE-ECDSA-AES256-GCM-SHA384","ECDHE-RSA-AES256-GCM-SHA384",
   
"ECDHE-ECDSA-AES256-SHA384","ECDHE-RSA-AES256-SHA384", 
"ECDHE-ECDSA-DES-CBC3-SHA",
   
"ECDH-ECDSA-AES256-GCM-SHA384","ECDH-RSA-AES256-GCM-SHA384","ECDH-ECDSA-AES256-SHA384",
   
"ECDH-RSA-AES256-SHA384","DHE-DSS-AES256-GCM-SHA384","DHE-DSS-AES256-SHA256",
   
"AES256-GCM-SHA384","AES256-SHA256","ECDHE-ECDSA-AES128-GCM-SHA256",
   
"ECDHE-RSA-AES128-GCM-SHA256","ECDHE-ECDSA-AES128-SHA256","ECDHE-RSA-AES128-SHA256",
   
"ECDH-ECDSA-AES128-GCM-SHA256","ECDH-RSA-AES128-GCM-SHA256","ECDH-ECDSA-AES128-SHA256",
   
"ECDH-RSA-AES128-SHA256","DHE-DSS-AES128-GCM-SHA256","DHE-DSS-AES128-SHA256",
   
"AES128-GCM-SHA256","AES128-SHA256","ECDHE-ECDSA-AES256-SHA",
   
"ECDHE-RSA-AES256-SHA","DHE-DSS-AES256-SHA","ECDH-ECDSA-AES256-SHA",
   
"ECDH-RSA-AES256-SHA","AES256-SHA","ECDHE-ECDSA-AES128-SHA",
   
"ECDHE-RSA-AES128-SHA","DHE-DSS-AES128-SHA","ECDH-ECDSA-AES128-SHA",
   "ECDH-RSA-AES128-SHA","AES128-SHA"]},
{honor_cipher_order, true},


Is anyone else had a play with this and got it working where a mitaka host can 
talk to a rabbitmq server running on trusty?
The version or erlang is the difference here and I’m pretty sure that is where 
the change is.

Cheers,
Sam


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

Re: [Openstack-operators] Uptime and SLA's

2016-06-02 Thread Melvin Hillsman

Hey Matt,

I am looking into Monasca and would like to know your recommendation for 
resources regarding a) understanding and b) installing the project; especially 
since there is no install guide on the project wiki. Additionally, can you shed 
some light on whether this setup would run behind a loadbalancer in an HA 
configuration; I am looking at using three servers which will house a 
“stack”/“toolchain” for such activities.

Kind regards,
--
Melvin Hillsman
Ops Technical Lead
OpenStack Innovation Center
mrhills...@gmail.com
phone: (210) 312-1267
mobile: (210) 413-1659
Learner | Ideation | Belief | Responsibility | Command
http://osic.org

From:  Matt Fischer
Date:  Thursday, June 2, 2016 at 5:29 PM
To:  "Kingshott, Daniel"
Cc:  OpenStack Operators
Subject:  Re: [Openstack-operators] Uptime and SLA's

We do this a few different ways, some of which may meet your needs.

For API calls we measure a simple, quick, and impactless call for each service 
(like heat stack-list) and we monitor East from West and vice versa. The goal 
here is nothing added to the DBs, so nothing like neutron net-create. The 
downside here is that some of these calls work even when the service isn't 100% 
healthy so keep that in mind.

Then we also have a set of "what would a user do" calls like "spin up a VM and 
attach a FIP and ssh in" or "create and delete a volume". These run less often. 

Finally we have a reference cloud application that uses our LBaaS, GSLB, HA 
routers, and multiple front-end/back-end nodes. This has the highest 
expectation of uptime and is used as an example for our customers of how you 
can run an app with "more nines" than the underlying infra.

On any of these, especially the first two I mentioned, time series data is 
super useful. It's good to know that your create volume times (for example) are 
40% slower after your deploy. We use Monasca and Grafana for that.


On Thu, Jun 2, 2016 at 2:37 PM, Kingshott, Daniel 
 wrote:
We¹re currently in the process of writing up an internal SLA for our
openstack cloud, I¹d be interested to hear what others have done and what
metrics folks are capturing.

My initial thoughts are success / fail spawning instances, creating and
attaching volumes, API availability and so on.

Can anyone on the list share their insights?

Thanks,

Dan


Daniel Kingshott
Cloud Dude
(425) 623 4359 - Cell

Best Buy Co. Inc.
Technology Development Center
1000 Denny Way | 8th Floor | Seattle, WA | 98109 | USA


___
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] Uptime and SLA's

2016-06-02 Thread Matt Fischer

We do this a few different ways, some of which may meet your needs.

For API calls we measure a simple, quick, and impactless call for each
service (like heat stack-list) and we monitor East from West and vice
versa. The goal here is nothing added to the DBs, so nothing like neutron
net-create. The downside here is that some of these calls work even when
the service isn't 100% healthy so keep that in mind.

Then we also have a set of "what would a user do" calls like "spin up a VM
and attach a FIP and ssh in" or "create and delete a volume". These run
less often.

Finally we have a reference cloud application that uses our LBaaS, GSLB, HA
routers, and multiple front-end/back-end nodes. This has the highest
expectation of uptime and is used as an example for our customers of how
you can run an app with "more nines" than the underlying infra.

On any of these, especially the first two I mentioned, time series data is
super useful. It's good to know that your create volume times (for example)
are 40% slower after your deploy. We use Monasca and Grafana for that.

On Thu, Jun 2, 2016 at 2:37 PM, Kingshott, Daniel <
daniel.kingsh...@bestbuy.com> wrote:

> We¹re currently in the process of writing up an internal SLA for our
> openstack cloud, I¹d be interested to hear what others have done and what
> metrics folks are capturing.
>
> My initial thoughts are success / fail spawning instances, creating and
> attaching volumes, API availability and so on.
>
> Can anyone on the list share their insights?
>
> Thanks,
>
> Dan
>
>
> Daniel Kingshott
> Cloud Dude
> (425) 623 4359 - Cell
>
> Best Buy Co. Inc.
> Technology Development Center
> 1000 Denny Way | 8th Floor | Seattle, WA | 98109 | USA
>
>
> ___
> 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] problem with DVR in Kilo and floating IPs

2016-06-02 Thread Gustavo Randich

Hi,

Using DVR in Kilo, I've the following issue:

- VM1 is in tenant network 1 (fixed IP 10.97.2.4)
- VM2 is in tenant network 2 (fixed IP 10.97.0.4)
- a router connects both networks
- VM1 and VM2 both have floating IPs
- I can ping from VM1 to VM2 using fixed / internal IP
- I cannot SSH from VM1 to VM2 using fixed IP, because of
"ssh_exchange_identification: read: Connection reset by peer"
- iperf output between both VMs using fixed IP is strange (see below)


If I remove floating IP in VM2 (target VM), SSH and iperf begin to work OK

The problem is not present with two VM1 in the *same* tenant network and
both having floating IPs

Any ideas?

Thanks!





VM1# tracepath 10.97.0.4
 1?: [LOCALHOST] pmtu 1500
 1:  10.97.2.1 0.322ms
 1:  10.97.2.1 0.436ms
 2:  10.97.0.4 0.962ms reached
 Resume: pmtu 1500 hops 2 back 4

VM1# ping 10.97.0.4
PING 10.97.0.4 (10.97.0.4) 56(84) bytes of data.
64 bytes from 10.97.0.4: icmp_seq=1 ttl=61 time=1.23 ms
^C
--- 10.97.0.4 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.231/1.231/1.231/0.000 ms

VM1# ssh 10.97.0.4
ssh_exchange_identification: read: Connection reset by peer

VM1# iperf -c 10.97.0.4

Client connecting to 10.97.0.4, TCP port 5001
TCP window size: 85.0 KByte (default)

[  3] local 10.97.2.4 port 47014 connected with 10.97.0.4 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec  0.00 ▒ ▒▒s  14746824734997131264 Bytes/sec





VM2# # iperf -s

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)

[  4] local 10.97.0.4 port 5001 connected with 10.182.0.58 port 47014
[ ID] Interval   Transfer Bandwidth
[  4]  0.0- 0.0 sec  14.1 KBytes  9.36 Mbits/sec
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Ops Meetups Team - Next Meeting Coordinates and News

2016-06-02 Thread Edgar Magana

Hello,

I think we need to increase the cap for real operators and not vendors but I 
have not attended the Ops meetups WG meetings so I do not know all the context 
about it.

BTW. DO we have a place and date for the next mid-cycle one?

Edgar

On 6/2/16, 1:16 PM, "Melvin Hillsman"  wrote:

>Apologies,
>
>* On a side note, can we decide on a [email-subject-tag] to help filter these 
>in [Openstack-operators]
>* Suggestion: [ops-meetups-team]
>
>For the delay that is since rain and Houston, TX fight a lot and rain is 
>winning these days unfortunately. I was tasked with submitting to the ML a 
>request to discuss how do we handle the waiting list for those who are not 
>able to attend the Ops Midcycle due to the cap. Looking at EventBrite [ 
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.eventbrite.com_support_articles_en-5FUS_How-5FTo_how-2Dto-2Dset-2Dup-2Dan-2Devent-2Dwaitlist-3Flg-3Den-5FUS=CwIGaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Izi115xT_K7kOrj3J8Dp44KcJDfJFyu8Tb_oYoroJng=nw_xXhA2xGfTOF5BCsJDlFzdMK7SbxZIyNcY0HqN0Bg=
>  ] if we are going to do a waitlist, this looks like a great option where 
>basically we get details about the attendees we need and the waitlist is 
>automatically created once the cap is hit.
>
>Playing devil’s advocate, my only apprehension to this process is should the 
>waitlist be large, and there is a significant reason for someone who attended 
>a previous Ops Midcycle to need to attend the next, how would that be handled? 
>I am sure there are other potential issues that can be identified.
>
>Kind regards,
>--
>Melvin Hillsman
>Ops Technical Lead
>OpenStack Innovation Center 
>mrhills...@gmail.com
>phone: (210) 312-1267
>mobile: (210) 413-1659
>Learner | Ideation | Belief | Responsibility | Command
>https://urldefense.proofpoint.com/v2/url?u=http-3A__osic.org=CwIGaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Izi115xT_K7kOrj3J8Dp44KcJDfJFyu8Tb_oYoroJng=pu6FOfWP0tAP8vf2pfzIrBPY1jdEnfIjOcI4ZUUA5dU=
> 
>
>
>
>
>
>
>
>On 6/1/16, 11:33 PM, "Tom Fifield"  wrote:
>
>>Hello all,
>>
>>Thank you very much to the dozen of you who participated in our second 
>>meeting. We had some fantastic discussion, summarised below (the meeting 
>>overview can be found at [3] and the full log at [4]).
>>
>>
>>==Next Meeting==
>>Unless there is further discussion, this the next meeting is at:
>>
>>==> Tuesday, 14 of Jun at 1400 UTC[1] in #openstack-operators
>>
>>[2] will be kept up to date with information about the meeting time and 
>>agenda
>>
>>
>>==August Meetup==
>>Since there really isn't a lot of time left and we have proposals 
>>already, we decided for this time we would not do the open call.
>>So, gfa, shintano and I will be working behind the scenes with Bestbuy 
>>(Seattle) and Bloomberg (NYC) a little bit to get further details on 
>>their venues - we will report to the group as soon as we have some 
>>progress so we can make a decision for the August meetup.
>>
>>
>>
>>==Meetup size==
>>We had a great discussion on meetup size and it's looking like 150-200 
>>is the proposal, please participate in Matt Jarvis' thread at:
>>
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_pipermail_openstack-2Doperators_2016-2DJune_010607.html=CwIGaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Izi115xT_K7kOrj3J8Dp44KcJDfJFyu8Tb_oYoroJng=x-Ny3jYrVkAxC5Ma-R7qRPQaTq_j3-TL5AF1WT6Z-48=
>> 
>>
>>
>>
>>
>>==Waitlist management==
>>There was a good proposal on how to manage the waitlist (give those that 
>>missed out first go at the next one). mrhillsman will write that up and 
>>send it through to the list shortly.
>>
>>
>>
>>
>>Regards,
>>
>>
>>Tom
>>
>>
>>[1] 
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.timeanddate.com_worldclock_fixedtime.html-3Fmsg-3DOps-2BMeetups-2BTeam-26iso-3D20160614T22-26p1-3D241=CwIGaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Izi115xT_K7kOrj3J8Dp44KcJDfJFyu8Tb_oYoroJng=_tbRGlaHlXJZc78QnSYGEx_TAvFkkpOAswKsr6wnUQA=
>> 
>>
>>[2] 
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openstack.org_wiki_Ops-5FMeetups-5FTeam-23Meeting-5FInformation=CwIGaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Izi115xT_K7kOrj3J8Dp44KcJDfJFyu8Tb_oYoroJng=3GqOnGDbijK8PjA-WRrrZdpx5PavL8UmOBJ4E6izO0M=
>> 
>>
>>[3] 
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__eavesdrop.openstack.org_meetings_ops-5Fmeetups-5Fteam_2016_ops-5Fmeetups-5Fteam.2016-2D05-2D31-2D14.01.html=CwIGaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=Izi115xT_K7kOrj3J8Dp44KcJDfJFyu8Tb_oYoroJng=WbHrH47xBUdxEDDBapu5uqcHGEur4HZBdORgXqXIPMY=
>> 
>>
>>[4]

[Openstack-operators] Uptime and SLA's

2016-06-02 Thread Kingshott, Daniel

We¹re currently in the process of writing up an internal SLA for our
openstack cloud, I¹d be interested to hear what others have done and what
metrics folks are capturing.

My initial thoughts are success / fail spawning instances, creating and
attaching volumes, API availability and so on.

Can anyone on the list share their insights?

Thanks,

Dan


Daniel Kingshott
Cloud Dude
(425) 623 4359 - Cell
 
Best Buy Co. Inc.
Technology Development Center
1000 Denny Way | 8th Floor | Seattle, WA | 98109 | USA


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

Re: [Openstack-operators] Ops Meetups Team - Next Meeting Coordinates and News

2016-06-02 Thread Melvin Hillsman

Apologies,

* On a side note, can we decide on a [email-subject-tag] to help filter these 
in [Openstack-operators]
* Suggestion: [ops-meetups-team]

For the delay that is since rain and Houston, TX fight a lot and rain is 
winning these days unfortunately. I was tasked with submitting to the ML a 
request to discuss how do we handle the waiting list for those who are not able 
to attend the Ops Midcycle due to the cap. Looking at EventBrite [ 
https://www.eventbrite.com/support/articles/en_US/How_To/how-to-set-up-an-event-waitlist?lg=en_US
 ] if we are going to do a waitlist, this looks like a great option where 
basically we get details about the attendees we need and the waitlist is 
automatically created once the cap is hit.

Playing devil’s advocate, my only apprehension to this process is should the 
waitlist be large, and there is a significant reason for someone who attended a 
previous Ops Midcycle to need to attend the next, how would that be handled? I 
am sure there are other potential issues that can be identified.

Kind regards,
--
Melvin Hillsman
Ops Technical Lead
OpenStack Innovation Center 
mrhills...@gmail.com
phone: (210) 312-1267
mobile: (210) 413-1659
Learner | Ideation | Belief | Responsibility | Command
http://osic.org







On 6/1/16, 11:33 PM, "Tom Fifield"  wrote:

>Hello all,
>
>Thank you very much to the dozen of you who participated in our second 
>meeting. We had some fantastic discussion, summarised below (the meeting 
>overview can be found at [3] and the full log at [4]).
>
>
>==Next Meeting==
>Unless there is further discussion, this the next meeting is at:
>
>==> Tuesday, 14 of Jun at 1400 UTC[1] in #openstack-operators
>
>[2] will be kept up to date with information about the meeting time and 
>agenda
>
>
>==August Meetup==
>Since there really isn't a lot of time left and we have proposals 
>already, we decided for this time we would not do the open call.
>So, gfa, shintano and I will be working behind the scenes with Bestbuy 
>(Seattle) and Bloomberg (NYC) a little bit to get further details on 
>their venues - we will report to the group as soon as we have some 
>progress so we can make a decision for the August meetup.
>
>
>
>==Meetup size==
>We had a great discussion on meetup size and it's looking like 150-200 
>is the proposal, please participate in Matt Jarvis' thread at:
>
>http://lists.openstack.org/pipermail/openstack-operators/2016-June/010607.html
>
>
>
>
>==Waitlist management==
>There was a good proposal on how to manage the waitlist (give those that 
>missed out first go at the next one). mrhillsman will write that up and 
>send it through to the list shortly.
>
>
>
>
>Regards,
>
>
>Tom
>
>
>[1] 
>http://www.timeanddate.com/worldclock/fixedtime.html?msg=Ops+Meetups+Team=20160614T22=241
>
>[2] https://wiki.openstack.org/wiki/Ops_Meetups_Team#Meeting_Information
>
>[3] 
>http://eavesdrop.openstack.org/meetings/ops_meetups_team/2016/ops_meetups_team.2016-05-31-14.01.html
>
>[4] 
>http://eavesdrop.openstack.org/meetings/ops_meetups_team/2016/ops_meetups_team.2016-05-31-14.01.log.html
>
>___
>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] [recognition] AUC Recognition WG Meeting Today (6/2/16)

2016-06-02 Thread Shamail Tahir

Hi everyone,

The AUC (Active User Contributor) Recognition WG will be meeting today and
the agenda has been posted on our wiki[1].

Meeting information:
Date: 6/2
Time: 1900 UTC
IRC Channel: #openstack-meeting-3

[1] *https://wiki.openstack.org/wiki/AUCRecognition#Meeting_Information
*

-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Collecting our wiki use cases

2016-06-02 Thread Thierry Carrez


Thanks to everyone who helped collecting wiki use cases on that etherpad.

I tried to categorize the various use cases and I think they fit in 4 
categories:


1/ Things that are already in the process of being moved to reference 
websites or documentation


That would be the main "portal" page with its links to all the other 
websites, the 'How To Contribute' stuff, the information about 
elections, release naming, User committee governance...


2/ Things that should probably be published elsewhere

Sprints, IRC channels, Mailing lists, Board meeting information, 
Successbot & Statusbot logging pages...


3/ "Cheap websites" for teams, working groups and some events

That is the bulk of the remaining use cases. The wiki makes for an easy 
and immediate way to publish information about a specific team or 
working group, including specific processes, self-service team signup, 
additional meeting information... They also work well as quick-and-basic 
websites for community-led events like the Design Summit or Ops Meetups.


4/ "Etherpad on steroids" - ephemeral slightly richer documents

...where the wiki is used for building very ephemeral documents like 
meeting agendas, newsletter drafts, sharing pictures



While I think we should continue the effort on (1) and (2), we need a 
long-term wiki-like solution for (3).


One interesting aspect of (3) is that all of the content there is 
clearly linked to a team of people. So it could easily be that team's 
duty to keep those pages limited in number and updated, reducing the 
nasty side-effects of stale pages. If the tool supports it, teams could 
use ACLs and/or have to vet the creation of new pages under their 
ownership, reducing the spam aspect. One issue with MediaWiki (compared 
to some other wikis or light publication platforms) is that it's 
essentially flat, so this "ownership" concept (which helps with keeping 
spam and staleness under control) is not really baked in.


That leaves (4), where using the wiki leads to stale pages with no real 
author or maintainer being returned in Google searches. I'd argue that 
unless the document is clearly owned by a team, permanent and maintained 
up to date, the wiki should not be used. We have etherpads, we have 
pastebins, we could add others similar tools if those are not sufficient 
as ephemeral collaborative scratchpads. If we keep that category under a 
wiki-like platform, that should at least be under some /tmp special 
category that we would clean up aggressively.



Another learning of this exercise is that while some teams definitely 
rely on the wiki, we have a finite number of cases to handle. So a rip 
and replace approach is not completely out of question, if we find a 
better tool and decide that selective content-copy is cleaner and faster 
than general cleanup + bulk migration.


For the immediate future (Newton) we'll likely focus on completing (1), 
find solutions for (2), and research potential tools for (3) and (4).


Thanks again for the feedback!

--
Thierry Carrez (ttx)

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

Re: [Openstack-operators] [User-committee] [scientific-wg] terminology

2016-06-02 Thread Blair Bethwaite

Hi Tim,

Firstly, thank-you for reading the logs and following up - it's great
to have further discussion generated!

On 2 June 2016 at 03:07, Tim Randles  wrote:
> Sorry I wasn't able to make yesterday's Scientific Working Group IRC
> meeting.  The discussion looked very interesting.  I would like to +1
> Blair's second idea:
>
>  #idea I want to run my (persistent) HPC platform/service using
> OpenStack as the infrastructure provisioning system
>
> This is exactly the use case I am exploring.  We're also in the early stages
> of defining and brainstorming support for complex work flows.

This and the complimentary facility - e.g., "datacloud" for
collaboration/sharing/post-processing/visualisation/..., close to the
traditional HPC and/or Research Data Store - seem to be the main
drivers for people I've spoken to recently that are looking to adopt
or expand OpenStack infrastructure.

> A problem that I see arising from these use case discussions is terminology.
> Let's consider the two main use cases thrown out yesterday, scientific
> clouds and cloud provisioning of HPC.  If someone wants to discuss
> "scheduling" that will likely mean wildly different things in the context of
> each use case.  Would it be useful, or even possible, to agree now on a set
> of standard definitions that we can use to avoid confusion?
>
> For instance, I propose the following:
>
> "Cloud scheduling" - provision-oriented (VMs/bare-metal) scheduling. Queued
> time may be similar to "HPC scheduling" but run time is measured in days,
> weeks, or even months. Example: Nova scheduler
>
> "HPC scheduling" - job-oriented, batch scheduling. Typically queued time and
> run time measured in hours or days. Examples: SLURM, Torque, PBS

Absolutely agree. Though I think I prefer "job scheduling" rather than
"HPC scheduling" (because HPC in itself is another overloaded term).

> I think "accounting" also falls under this overloaded-terminology rubric but
> it's much harder to define.  Even among traditional HPC centers there tends
> to be great variation in how accounting is done.

As you're probably aware, "accounting and scheduling" was one of the
activity areas prioritised by the scientific-wg meetings in Austin.
And I suspect this is one of the reasons why. Accounting needs seem to
be closely tied to the delivery model of the computing service (e.g.,
IaaS, Cluster-aaS, batch-job scheduler). Unfortunately we don't yet
have any planned deliverables or lead/s for the accounting and
scheduling activity, but perhaps a first deliverable would be to gain
a better idea of the ways in which people are approaching this now and
where their gaps are.

> What other terms have
> folks found to be confusing?

Federation is one that springs to mind.

-- 
Cheers,
~Blairo

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

Re: [Openstack-operators] problem with DVR in Kilo and floating IPs

[Openstack-operators] oslo_messaging, rabbit, ssl and mitaka and xenial

Re: [Openstack-operators] Uptime and SLA's

Re: [Openstack-operators] Uptime and SLA's

[Openstack-operators] problem with DVR in Kilo and floating IPs

Re: [Openstack-operators] Ops Meetups Team - Next Meeting Coordinates and News

[Openstack-operators] Uptime and SLA's

Re: [Openstack-operators] Ops Meetups Team - Next Meeting Coordinates and News

[Openstack-operators] [recognition] AUC Recognition WG Meeting Today (6/2/16)

Re: [Openstack-operators] Collecting our wiki use cases

Re: [Openstack-operators] [User-committee] [scientific-wg] terminology

11 matches

Site Navigation

Mail list logo

Footer information