Difference between revisions of "Federated Cloud siteconf"
(35 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
{{Fedcloud_Menu}} {{TOC_right}} | {{Fedcloud_Menu}} {{TOC_right}} | ||
= Follow-up<br> = | |||
*[2017-10-03] it appears that most of the sites guarantee outcome connectivity. Exceptions will be contacted to understand if there is room to implement it, in order to develop a callback from the VMs to collect and report to VMOps information about the local VM configuration. Action: Vincenzo to contact IFCA, and push 3 sites that didn't reply yet. <br> | |||
= Site-specific configuration = | |||
The main purpose of this page is to collect site-specific configuration parameters of the Federated Cloud sites, allowing comparison among them, identify differences, get parameters for a specific site. | The main purpose of this page is to collect site-specific configuration parameters of the Federated Cloud sites, allowing comparison among them, identify differences, get parameters for a specific site. | ||
Line 22: | Line 28: | ||
'''Last update: September 2017''' | '''Last update: September 2017''' | ||
= | {| cellspacing="0" cellpadding="5" style="border:1px solid black; text-align:left;" class="wikitable" | ||
|- style="background:lightgray;" | |- style="background:lightgray;" | ||
! style="border-bottom:1px solid black;" | <br> | ! style="border-bottom:1px solid black;" | <br> | ||
Line 100: | Line 104: | ||
| style="border-bottom:1px dotted silver;" | private<br> | | style="border-bottom:1px dotted silver;" | private<br> | ||
| style="border-bottom:1px dotted silver;" | /occi1.1/network/PUBLIC<br> | | style="border-bottom:1px dotted silver;" | /occi1.1/network/PUBLIC<br> | ||
| style="border-bottom:1px dotted silver;" | | | style="border-bottom:1px dotted silver;" | Yes<br> | ||
| style="border-bottom:1px dotted silver;" | all open<br> | | style="border-bottom:1px dotted silver;" | all open<br> | ||
| style="border-bottom:1px dotted silver;" | all open<br> | | style="border-bottom:1px dotted silver;" | all open<br> | ||
Line 111: | Line 115: | ||
|- | |- | ||
| style="border-bottom:1px dotted silver;" | CYFRONET-CLOUD | | style="border-bottom:1px dotted silver;" | CYFRONET-CLOUD | ||
| style="border-bottom:1px dotted silver;" | | | style="border-bottom:1px dotted silver;" | private<br> | ||
| style="border-bottom:1px dotted silver;" | private<br> | | style="border-bottom:1px dotted silver;" | private<br> | ||
| style="border-bottom:1px dotted silver;" | public<br> | | style="border-bottom:1px dotted silver;" | public<br> | ||
Line 240: | Line 244: | ||
| style="border-bottom:1px dotted silver;" | public<br> | | style="border-bottom:1px dotted silver;" | public<br> | ||
| style="border-bottom:1px dotted silver;" | <br> | | style="border-bottom:1px dotted silver;" | <br> | ||
| style="border-bottom:1px dotted silver;" | | | style="border-bottom:1px dotted silver;" | <br> | ||
| style="border-bottom:1px dotted silver;" | all open<br> | | style="border-bottom:1px dotted silver;" | all open<br> | ||
| style="border-bottom:1px dotted silver;" | all open<br> | | style="border-bottom:1px dotted silver;" | all open<br> | ||
Line 326: | Line 330: | ||
| style="border-bottom:1px dotted silver;" | private<br> | | style="border-bottom:1px dotted silver;" | private<br> | ||
| style="border-bottom:1px dotted silver;" | public_net<br> | | style="border-bottom:1px dotted silver;" | public_net<br> | ||
| style="border-bottom:1px dotted silver;" | | | style="border-bottom:1px dotted silver;" | <br> | ||
| style="border-bottom:1px dotted silver;" | all open<br> | | style="border-bottom:1px dotted silver;" | all open<br> | ||
| style="border-bottom:1px dotted silver;" | <br> | | style="border-bottom:1px dotted silver;" | <br> | ||
Line 351: | Line 355: | ||
|} | |} | ||
= Upgrade campaigns and surveys = | <br> | ||
= Upgrade campaigns and surveys = | |||
== cASO upgrade == | == cASO upgrade == | ||
'''Started on September 21st, 2017.Still open. ''' | '''Started on September 21st, 2017.Still open. ''' | ||
''The APEL team would like to encourage OpenStack sites to upgrade their version of caso to this version https://appdb.egi.eu/store/software/caso/releases/1.x/1.1.1/ Sites that are currently running 1.0.X or were running it in the past should upgrade and republish the period that 1.0.X was in use. Sites that never run 1.0.X, i.e. they went straight to 1.1.0 or never moved away from the older 0.X.X versions, don’t need to republish, they only need to upgrade.'' | ''The APEL team would like to encourage OpenStack sites to upgrade their version of caso to this version https://appdb.egi.eu/store/software/caso/releases/1.x/1.1.1/ Sites that are currently running 1.0.X or were running it in the past should upgrade and republish the period that 1.0.X was in use. Sites that never run 1.0.X, i.e. they went straight to 1.1.0 or never moved away from the older 0.X.X versions, don’t need to republish, they only need to upgrade.'' | ||
Line 367: | Line 374: | ||
| 100IT | | 100IT | ||
| https://ggus.eu/index.php?mode=ticket_info&ticket_id=130665 | | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130665 | ||
| | | CLOSED | ||
| | | We were running Caso 1.1.0, and have now upgraded to 1.1.1. No republishing needed.<br> | ||
|- | |- | ||
| CYFRONET-CLOUD | | CYFRONET-CLOUD | ||
| https://ggus.eu/index.php?mode=ticket_info&ticket_id=130666 | | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130666 | ||
| OPEN | | OPEN | ||
| | | No reply. | ||
|- | |- | ||
| FZJ | | FZJ | ||
| https://ggus.eu/index.php?mode=ticket_info&ticket_id=130667 | | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130667 | ||
| | | ON HOLD | ||
| | | We're currently running cASO 0.3.0. When trying to run cASO 1.1.1, I have trouble extracting records due to "MissingAuthPlugin: An auth plugin is required to determine endpoint URL". I have to put this on hold due to other, more important obligations.<br> | ||
|- | |- | ||
| IFCA-LCG2 | | IFCA-LCG2 | ||
| https://ggus.eu/index.php?mode=ticket_info&ticket_id=130668 | | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130668 | ||
| | | CLOSED | ||
| already running caso 1.1.1 | | already running caso 1.1.1 | ||
|- | |- | ||
Line 398: | Line 405: | ||
| https://ggus.eu/index.php?mode=ticket_info&ticket_id=130671 | | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130671 | ||
| OPEN | | OPEN | ||
| | | Experiencing issues with the configuration of the new installation, following on the fedcloud list.<br> | ||
|- | |- | ||
| RECAS-BARI | | RECAS-BARI | ||
| https://ggus.eu/index.php?mode=ticket_info&ticket_id=130672 | | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130672 | ||
| OPEN | | OPEN | ||
| | | In progress<br> | ||
|- | |- | ||
| INFN-PADOVA-STACK | | INFN-PADOVA-STACK | ||
| https://ggus.eu/index.php?mode=ticket_info&ticket_id=130673 | | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130673 | ||
| | | CLOSED | ||
| | | <span>at the time of the CASO update the accounting data were not | ||
published since a couple of weeks due to a nfs failure. After the update | |||
and nfs repair, the old accounting data were properly pushed towards | |||
the accounting DB. Looking at the accounting portal the usage of | |||
September seems inline with the previous months, so i think that a | |||
re-publication is not needed.</span> | |||
|- | |- | ||
| TR-FC1-ULAKBIM | | TR-FC1-ULAKBIM | ||
| https://ggus.eu/index.php?mode=ticket_info&ticket_id=130674 | | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130674 | ||
| | | CLOSED | ||
| | | We are using fedcloud appliance for caso. Our version is caso-0.3.2. We will update as soon as possible. -> We have updated our fedcloud appliance with the latest docker image fedcloud/caso. Now it is caso-1.1.1-py2.7. No republishing needed.<br> | ||
|- | |- | ||
| IN2P3-IRES | | IN2P3-IRES | ||
| https://ggus.eu/index.php?mode=ticket_info&ticket_id=130675 | | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130675 | ||
| | | CLOSED | ||
| | | I have republished the data, but it is still wrong :-/ We may close this ticket. I have another ticket for the accounting issue:<br> [https://ggus.eu/index.php?mode=ticket_info&ticket_id=130327 https://ggus.eu/index.php?mode=ticket_info&ticket_id=130327] | ||
|- | |- | ||
| NCG-INGRID-PT | | NCG-INGRID-PT | ||
| https://ggus.eu/index.php?mode=ticket_info&ticket_id=130676 | | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130676 | ||
| | | CLOSED | ||
| | | No accounting at the site.<br> | ||
|- | |- | ||
| SCAI | | SCAI | ||
Line 436: | Line 448: | ||
|} | |} | ||
== Switching to default private network == | == Switching to default private network == | ||
'''Started on October 2nd, 2017. Direct emails used, no tickets. Still open. '''<br> | '''Started on October 2nd, 2017. Direct emails used, no tickets. Still open. '''<br> | ||
Line 443: | Line 455: | ||
|- style="background:lightgray;" | |- style="background:lightgray;" | ||
! style="border-bottom:1px solid black;" | Resource Centre | ! style="border-bottom:1px solid black;" | Resource Centre | ||
! style="border-bottom:1px solid black;" | | ! style="border-bottom:1px solid black;" | Result | ||
! style="border-bottom:1px solid black;" | Comments | ! style="border-bottom:1px solid black;" | Details | ||
! style="border-bottom:1px solid black;" | Comments, feedback, requests | |||
|- | |||
| CESNET-MetaCloud | |||
| bgcolor="#00ff00" | Will switch to private | |||
| | |||
CESNET-MetaCloud will enter the site decommissioning process shortly. The newly built and registered site (name still TBD) will follow this private-by-default configuration.<br> | |||
| | |||
*What does '<span class="il">private</span>' actually mean? '''<span class="il">Private</span> with NAT or without?'''<br> These have different configuration and user expectations.<br> * On OpenNebula, having <span class="il">private</span>-by-<span class="il">default</span> and attaching public means<br> having '''two interfaces in the virtual machine. Are endorsed images<br> ready for this?''' Can user applications work in a multi-home<br> environment?<br> * In case of combining <span class="il">private</span> with NAT and public on a single machine, users will run into routing issues unless they adjust routing metrics. This can be handled in the appliance, however the appliance<br> must be ready for this. DHCP alone doesn't support setting routing metrics, so we as a provider cannot do this from the outside. | |||
*As apparent from the above, '''using this approach will highlight CMF-specific behaviors in <span class="il">networking</span>'''. | |||
|- | |||
| CESGA<br> | |||
| bgcolor="#00ff00" | Will switch to private | |||
| | |||
I agree about the benefits of using a <span class="il">private</span> IP pool.<br> | |||
To implement the change: | |||
1- I will change the IPs assigned of the current <span class="il">default</span> virtualnet from the public IP pool to the <span class="il">private</span> one. In this manner will be not necessary change the current MVs templates. | |||
2- Create a new virtualnet with the old public IPs pool assigned. <br> | |||
| | |||
In order to allow the site ask for a public IP (in a standardized manner), please clarify me if any condition is mandatory, as for example the '''name for the public virtualnet''' or so on... | |||
|- | |||
| SCAI<br> | |||
| bgcolor="#ffff00" | Trying to switch to private, network configuration issues<br> | |||
| we had <span class="il">private</span> <span class="il">networks</span> (OVS VXLAN tenant <span class="il">networks</span>) as a <span class="il">default</span> before we <span class="il">switched</span> to mitaka, but since mitaka we had problems that it didn't work to associate a floating IP through OCCI. We tried to <span class="il">switch</span> back recently but we now have problems getting the tenant <span class="il">networks</span> to work (we get no connectivity through the VXLAN tunnel). If we can fix that we will change directly. | |||
| <br> | |||
|- | |||
| MK-04-FINKICLOUD<br> | |||
| <br> | |||
| <br> | |||
| <br> | |||
|- | |||
| RECAS-BARI<br> | |||
| bgcolor="#ff0000" | Cannot switch to private<br> | |||
| <div>At RECAS-BARI we have implemented a particular setup of the <span class="il">networking</span> service provided by the CMF Openstack: a public <span class="il">network</span> is shared and visible across all the tenants whereas isolated <span class="il">private</span> <span class="il">networks</span> can be added in each tenant. It is not possible to hide the public <span class="il">network</span> and it is not possible to limit the number of public IPs to be assigned to tenants. ''This configuration is different from the most common setup used in Openstack where an external <span class="il">network</span> is used to provision floating IPs with a dedicated quota.'' Our approach, even if less common, guarantees better performances and user experience ('''in the past we provided floating IPs using overlay <span class="il">networks</span> and our users were not happy with stability and performances'''). </div><div><br></div><br> | |||
| <div>Now coming to the point about application portability, I think that this can be achieved in two ways:</div><div>1) asking sites to change their settings in order to achieve a sort of homogeneity;</div><div>2) '''accepting sites heterogeneity: publish site <span class="il">networking</span> information, provide best practices and recipes (if needed) for the users'''. </div><div><br></div><div>'''Following the first path (as you are doing) can be too invasive for sites since you are asking them to change their policies or configurations and in some cases there might be technical issues that prevent sites from changing the <span class="il">default</span> configuration as in our case.'''</div><div>The second approach would not require any critical change at site level: the site <span class="il">networking</span> characteristics might be published so that users or higher-level tools can easily retrieve that information; moreover the users should be enforced to follow some simple best practices. </div><div>For example, one of the problems that EGI users encounter when we configure the additional <span class="il">private</span> <span class="il">network</span> in the tenant is that they get the “Multiple <span class="il">networks</span>” error from occi while creating a virtual server. In fact, they are not used to specify the <span class="il">network</span> and in some cases they do not know how to do that.</div><div>Therefore today an application written for sites with the <span class="il">default</span> Openstack configuration is not portable on our cloud but it might become specifying always the <span class="il">network</span> (also for the <span class="il">default</span> Openstack configuration). Of course this is just an example, for other aspects there might be the need for better abstraction at higher level (federation) in order to provide users with transparent access to the resources of the sites.</div> | |||
|- | |||
| INFN-CATANIA-STACK<br> | |||
| bgcolor="#00ff00" | Can switch to private | |||
| we can switch to assign private IPs without problems. | |||
| '''how the user can access to a VM that has a private IP when the public<br> one is not needed?''' | |||
|- | |||
| IISAS-*<br> | |||
| bgcolor="#00ff00" | Can switch to private | |||
| <div>for the IISAS cloud sites, there are no real technical problems preventing us to change the default network to private IPs. <br></div> | |||
| The main problem for us is '''potential disruption of important services hosting on the site during the change''', therefore we must '''carefully make plan ahead before switching'''. | |||
|- | |||
| HG-09-Okeanos-Cloud<br> | |||
| <br> | |||
| <br> | |||
| <br> | |||
|- | |||
| GoeGrid<br> | |||
| <br> | |||
| <br> | |||
| <br> | |||
|- | |- | ||
| | | BEgrid-BELNET<br> | ||
| | | bgcolor="#ffff00" | Will deploy the private setup and make some tests<br> | ||
| | | | ||
We are running out of public IPs, and we also understand the security concern with having public IPs by default. | |||
On each hypervisor, we will create an isolated bridge with OVS, and then these bridges will be connected to each others with GRE tunnels in a full-mesh topology. | |||
| '''It is not yet entirely clear how users will be able to access their VMs in the private network.''' The scenario where the users adds a new public nic dynamically to his VM has to be carefully tested because adding a new nic triggers some changes in the network configuration (default route,....). We need to understand how the operating system handles this.<br> | |||
|} | |} |
Latest revision as of 10:46, 6 February 2019
Overview | For users | For resource providers | Infrastructure status | Site-specific configuration | Architecture |
Follow-up
- [2017-10-03] it appears that most of the sites guarantee outcome connectivity. Exceptions will be contacted to understand if there is room to implement it, in order to develop a callback from the VMs to collect and report to VMOps information about the local VM configuration. Action: Vincenzo to contact IFCA, and push 3 sites that didn't reply yet.
Site-specific configuration
The main purpose of this page is to collect site-specific configuration parameters of the Federated Cloud sites, allowing comparison among them, identify differences, get parameters for a specific site.
If you have any comments on the content of this page, please contact operations @ egi.eu.
Parameters provided by each site are:
- default network name, as the name of the network assigned by default when firing up a VM to the site; at the moment, it might be that the network is private, public or not assigned at all; example: /network/PRIVATE
- default network type, can be public, private, or N/A (not available)
- public network name: name of the public network to be used; usually this is different from the default network, which is private in most of the cases; example: /network/PUBLIC
- is outgoing connectivity guaranteed by default at start time: please say YES if newly started VM provide directly outgoing connection, either through public IP or, if public IP is not assigned at instantiation time, through NAT (private IP enabled to outgoing connection)
- port default firewall policy: default policy available at infrastructure level (firewall); usually it's either "all open" or "all closed"
- ports firewall configuration: port configuration on top of the default firewall policy; so you can specify i.e. which ports are open on the firewall if the default configuration is "all closed"; example: 22, ICMP open
- ports default CMF policy: on OpenStack, it is possible to open/close ports using the OpenStack user interface; these "security groups" feature is an additional firewall feature, independent from the infrastructure (low level) firewall, and can be configured by the user (using the Horizon interface) or by API, or asking for support through the EGI Helpdesk. Example: "all open" or "all closed".
- ports policy on CMF: if ports default CMF policy is "all closed", you may want to specify here if there are exceptions. Example: ssh.
- mandatory closed ports: if there are ports that cannot be opened due to local rules or national regulations or infrastructure constraints. Example: 25 is usually not available for security reasons (used 587 instead).
- port configuration requests method: how the site allows to fulfill port reconfiguration requests. Examples: GGUS, Horizon, other ways.
- users requests: please mention here any special requests come from users in the past and that you have worked in order to make a specific use case run on your site.
- comments: if you have any comments to report here that could help us in improving this page.
Last update: September 2017
default network name | default network type | public network name | is outgoing connectivity guaranteed by default at start time? | port default firewall policy | ports firewall configuration | ports default CMF policy | ports policy on CMF | mandatory closed ports | port configuration requests method | users requests | comments | |
---|---|---|---|---|---|---|---|---|---|---|---|---|
100IT | private | private | public | YES * | all open | all closed | none | OpenStack Horizon, GGUS | * Outgoing connectivity is available if an IP address is assigned to the VM's virtual router (this is the case by default). Users can disable this if desired. | |||
BEgrid-BELNET | /network/1 | public | /network/1 | YES | all closed | 22, ICMP | GGUS ticket | 80, 8080, 443 | some users have requested to limit access to their VMs to a given list of source IPs | |||
CESGA | https://fedcloud-services.egi.cesga.es:11443/network/1 |
public | https://fedcloud-services.egi.cesga.es:11443/network/1 |
YES |
all open |
all open |
NA (no OpenStack) |
NA (no OpenStack) |
none |
GGUS |
Static DHCP server (IP assigned if network contextualization fails) |
|
CESNET-MetaCloud | https://carach5.ics.muni.cz:11443/network/24 |
public |
public |
YES |
all open |
all open |
all open |
all open |
67/udp, 137/udp |
GGUS |
One request to provide a private network. |
As soon as security groups are implemented in OCCI, we will switch to a more restrictive mode where only TCP 22 is open by default. Users will have a self-service control over this via OCCI. |
CLOUDIFIN | /occi1.1/network/500ed7e7-162e-4d97-916e-bc7bc3ab9b41 |
private |
/occi1.1/network/PUBLIC |
Yes |
all open |
all open |
all open |
all open |
GGUS |
As we well know by using occi we can create, destroy VMs, attach link networks. Would it not be possible to access (ssh) VMs with private ip through occi? | ||
CYFRONET-CLOUD | private |
private |
public |
YES |
all open |
all open |
all open |
all open |
GGUS |
|||
FZJ | /network/PRIVATE |
private |
/network/PUBLIC |
YES | all closed |
22, 80, 443, 7000-7020 |
all closed |
all closed, except for 22, 80, 443, 7000-7020 |
25 |
Openstack Horizon portal, GGUS |
3306, redirected to 7000; 25 (from the inside), redirected to 587. |
Ports 7000-7020 have been defined by our network security team. We have so far redirected any requests for other ports to this range. There was a debate once when users insisted on port 3306 for MySQL, however we convinced them that their client was flawed by not supporting other ports. In the same way, users expected to be able to send email via port 25, we convinced them that port 587 is intended for that purpose. |
GoeGrid | https://occi.cloud.gwdg.de:3100/network/36 |
public |
https://occi.cloud.gwdg.de:3100/network/36 |
YES | all closed |
22, 80, 443, ICMP |
all open |
all open |
none |
GGUS |
||
HG-09-Okeanos-Cloud | public |
public |
public |
yes | all open |
all open |
Not Available |
Not Available |
None |
GGUS |
All newly created VMs are getting a public IPv4 and public IPv6 address | |
IFCA-LCG2 | provider-<project VLAN ID> |
private |
external |
NO | all open |
all closed |
any |
OpenStack Horizon, GGUS |
||||
IISAS-FedCloud | /occi1.1/network/14bd3bc2-5f1a-4948-b94e-bc95e56122e5 |
public |
/occi1.1/network/14bd3bc2-5f1a-4948-b94e-bc95e56122e5 |
YES | all open |
all closed | 22,ICMP open |
Openstack Horizon portal, GGUS |
network connections should be monitored, unusual activities (e.g. very high volumes/frequency connections) should raise alarms | |||
IISAS-Nebula | https://nebula2.ui.savba.sk:11443/network/1 |
public |
https://nebula2.ui.savba.sk:11443/network/1 |
YES | all open |
all closed | 22, ICMP open |
GGUS |
||||
IISAS-GPUCloud | https://nova3.ui.savba.sk:8787/occi1.1/network/PUBLIC |
public | https://nova3.ui.savba.sk:8787/occi1.1/network/PUBLIC |
YES | all open |
all closed | 22, ICMP open | Openstack Horizon portal, GGUS |
port 8899 by enmr.eu |
network connections should be monitored, unusual activities (e.g. very high volumes/frequency connections) should raise alarms | ||
IN2P3-IRES | /occi1.1/network/9a393ad0-057e-4d74-8a50-1818114caaba |
private |
/occi1.1/network/PUBLIC |
Yes |
all closed |
22/80/443/8080 and ICMP open |
Ports 22/tcp and ICMP open by default. Users have the ability to use additional security group to open other ports. |
21, 25 |
OpenStack for 80/443/8080, GGUS otherwise |
user are not allowed to create / modify / delete security groups (in particular in a catch-all VO). Comment from the ticket: There is no name for the default network. In deed, with OpenStack and OOI, private networks does not have default name (like the public one). Each private network has its own ID (it is different for each project / VO. | ||
INFN-CATANIA-STACK | public |
all open |
all open |
Horizon Dashboard, GGUS | ||||||||
INFN-PADOVA-STACK | /occi1.1/network/<UUID of the internal project network> |
private |
/occi1.1/network/PUBLIC |
YES |
all closed |
22 open |
al closed |
22 open |
GGUS |
upon request: 8899 (from a given IM/EC3 server), 80 to be negotiated |
||
RECAS-BARI | /occi/network/fe82ef7b-4bb7-4c1e-b4ec-ec5c1b0c7333 |
public |
public_net |
YES | all open except port 111 |
all closed |
ssh (22) open |
none |
Horizon Dashboard, GGUS | several ports because fedcloud users are currently running different services: web portals and applications (80/8080,443), onedata (9443), hadoop, elasticsearch, etc. |
Finally we are configuring the private network in the new tenants with the latest version of ooi (1.1.2) that fixes a bug in the listing of networks. So now newly created tenants will also have a private network (isolated) as well as the public one (shared). We encourage you to use the private network whenever this is compatible with the architecture of the virtual infrastructure being deployed. If needed, we can provide direct access to the private network via our VPN (accessible with personal credentials). | |
SCAI | public |
public |
public |
Yes |
all closed |
ICMP, 22, 80, 443 open |
all open |
none |
none |
GGUS |
Temporary configuration, because prior configuration with default routed internal network (VxLan) and optional public provider network didn't work, couldn't attach floating public IP through OCCI (worked through horizon). | |
TR-FC1-ULAKBIM | http://fcctrl.ulakbim.gov.tr:8787/occi1.2/network/ed61199b-baac-4524-b801-324f341b0d89 for fedcloud.egi.eu |
private |
http://fcctrl.ulakbim.gov.tr:8787/occi1.2/network/ed61199b-baac-4524-b801-324f341b0d89 | yes | all closed | 22, 443, ICMP open | all closed |
22, ICMP open |
None |
GGUS | 443 |
|
UPV-GRyCAP | private | private | /network/6 | yes | all closed | 22, 443 | NA | NA | None | GGUS, email | At this point we are considering the option of migrating to OpenStack | |
NCG-INGRID-PT | <PROJECTNAME>_private_net |
private |
public_net |
all open |
Ports 22/tcp and ICMP open by default. Users have the ability to use additional security group to open other ports. |
Horizon Dashboard, GGUS |
Horizon Dashboard, GGUS |
|||||
MK-04-FINKICLOUD | public |
public |
public |
YES |
all closed |
ICMP, 22, 80, 443 open |
Ports 22/ICMP, 22, 80, 443 are open by default. User can add additional security group for opening another port. |
none |
none |
GGUS ticket |
none |
Upgrade campaigns and surveys
cASO upgrade
Started on September 21st, 2017.Still open.
The APEL team would like to encourage OpenStack sites to upgrade their version of caso to this version https://appdb.egi.eu/store/software/caso/releases/1.x/1.1.1/ Sites that are currently running 1.0.X or were running it in the past should upgrade and republish the period that 1.0.X was in use. Sites that never run 1.0.X, i.e. they went straight to 1.1.0 or never moved away from the older 0.X.X versions, don’t need to republish, they only need to upgrade.
Resource Centre | Ticket | Status | comments |
---|---|---|---|
100IT | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130665 | CLOSED | We were running Caso 1.1.0, and have now upgraded to 1.1.1. No republishing needed. |
CYFRONET-CLOUD | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130666 | OPEN | No reply. |
FZJ | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130667 | ON HOLD | We're currently running cASO 0.3.0. When trying to run cASO 1.1.1, I have trouble extracting records due to "MissingAuthPlugin: An auth plugin is required to determine endpoint URL". I have to put this on hold due to other, more important obligations. |
IFCA-LCG2 | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130668 | CLOSED | already running caso 1.1.1 |
IISAS-FedCloud | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130669 | CLOSED | cASO v1.1.1 is already installed. Previous version was 0.3.2. |
IISAS-GPUCloud | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130670 | CLOSED | cASO v1.1.1 is already installed. Previous version was 0.3.2. |
INFN-CATANIA-STACK | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130671 | OPEN | Experiencing issues with the configuration of the new installation, following on the fedcloud list. |
RECAS-BARI | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130672 | OPEN | In progress |
INFN-PADOVA-STACK | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130673 | CLOSED | at the time of the CASO update the accounting data were not
published since a couple of weeks due to a nfs failure. After the update and nfs repair, the old accounting data were properly pushed towards the accounting DB. Looking at the accounting portal the usage of September seems inline with the previous months, so i think that a re-publication is not needed. |
TR-FC1-ULAKBIM | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130674 | CLOSED | We are using fedcloud appliance for caso. Our version is caso-0.3.2. We will update as soon as possible. -> We have updated our fedcloud appliance with the latest docker image fedcloud/caso. Now it is caso-1.1.1-py2.7. No republishing needed. |
IN2P3-IRES | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130675 | CLOSED | I have republished the data, but it is still wrong :-/ We may close this ticket. I have another ticket for the accounting issue: https://ggus.eu/index.php?mode=ticket_info&ticket_id=130327 |
NCG-INGRID-PT | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130676 | CLOSED | No accounting at the site. |
SCAI | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130677 | CLOSED | we went directly to caso 1.1.0 and skipped 1.0.X, so we should not be affected by republishing. We did the upgrade yesterday. Upgraded to caso 1.1.1 |
CLOUDIFIN | https://ggus.eu/index.php?mode=ticket_info&ticket_id=130678 | CLOSED | After upgrade (from cASO 0.3.3) we have cASO 1.1.1. |
Switching to default private network
Started on October 2nd, 2017. Direct emails used, no tickets. Still open.
Resource Centre | Result | Details | Comments, feedback, requests |
---|---|---|---|
CESNET-MetaCloud | Will switch to private |
CESNET-MetaCloud will enter the site decommissioning process shortly. The newly built and registered site (name still TBD) will follow this private-by-default configuration. |
|
CESGA |
Will switch to private |
I agree about the benefits of using a private IP pool. To implement the change: 1- I will change the IPs assigned of the current default virtualnet from the public IP pool to the private one. In this manner will be not necessary change the current MVs templates. 2- Create a new virtualnet with the old public IPs pool assigned. |
In order to allow the site ask for a public IP (in a standardized manner), please clarify me if any condition is mandatory, as for example the name for the public virtualnet or so on... |
SCAI |
Trying to switch to private, network configuration issues |
we had private networks (OVS VXLAN tenant networks) as a default before we switched to mitaka, but since mitaka we had problems that it didn't work to associate a floating IP through OCCI. We tried to switch back recently but we now have problems getting the tenant networks to work (we get no connectivity through the VXLAN tunnel). If we can fix that we will change directly. | |
MK-04-FINKICLOUD |
|||
RECAS-BARI |
Cannot switch to private |
At RECAS-BARI we have implemented a particular setup of the networking service provided by the CMF Openstack: a public network is shared and visible across all the tenants whereas isolated private networks can be added in each tenant. It is not possible to hide the public network and it is not possible to limit the number of public IPs to be assigned to tenants. This configuration is different from the most common setup used in Openstack where an external network is used to provision floating IPs with a dedicated quota. Our approach, even if less common, guarantees better performances and user experience (in the past we provided floating IPs using overlay networks and our users were not happy with stability and performances). |
Now coming to the point about application portability, I think that this can be achieved in two ways: 1) asking sites to change their settings in order to achieve a sort of homogeneity; 2) accepting sites heterogeneity: publish site networking information, provide best practices and recipes (if needed) for the users. Following the first path (as you are doing) can be too invasive for sites since you are asking them to change their policies or configurations and in some cases there might be technical issues that prevent sites from changing the default configuration as in our case. The second approach would not require any critical change at site level: the site networking characteristics might be published so that users or higher-level tools can easily retrieve that information; moreover the users should be enforced to follow some simple best practices. For example, one of the problems that EGI users encounter when we configure the additional private network in the tenant is that they get the “Multiple networks” error from occi while creating a virtual server. In fact, they are not used to specify the network and in some cases they do not know how to do that. Therefore today an application written for sites with the default Openstack configuration is not portable on our cloud but it might become specifying always the network (also for the default Openstack configuration). Of course this is just an example, for other aspects there might be the need for better abstraction at higher level (federation) in order to provide users with transparent access to the resources of the sites.
|
INFN-CATANIA-STACK |
Can switch to private | we can switch to assign private IPs without problems. | how the user can access to a VM that has a private IP when the public one is not needed? |
IISAS-* |
Can switch to private | for the IISAS cloud sites, there are no real technical problems preventing us to change the default network to private IPs.
|
The main problem for us is potential disruption of important services hosting on the site during the change, therefore we must carefully make plan ahead before switching. |
HG-09-Okeanos-Cloud |
|||
GoeGrid |
|||
BEgrid-BELNET |
Will deploy the private setup and make some tests |
We are running out of public IPs, and we also understand the security concern with having public IPs by default. On each hypervisor, we will create an isolated bridge with OVS, and then these bridges will be connected to each others with GRE tunnels in a full-mesh topology. |
It is not yet entirely clear how users will be able to access their VMs in the private network. The scenario where the users adds a new public nic dynamically to his VM has to be carefully tested because adding a new nic triggers some changes in the network configuration (default route,....). We need to understand how the operating system handles this. |