Tim Andersson has proposed merging ~andersson123/autopkgtest-cloud:docs-firewalls-proxy-update into autopkgtest-cloud:master.
Requested reviews: Canonical's Ubuntu QA (canonical-ubuntu-qa) For more details, see: https://code.launchpad.net/~andersson123/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/456339 -- Your team Canonical's Ubuntu QA is requested to review the proposed merge of ~andersson123/autopkgtest-cloud:docs-firewalls-proxy-update into autopkgtest-cloud:master.
diff --git a/docs/deploying.rst b/docs/deploying.rst index 85d853f..29209bf 100644 --- a/docs/deploying.rst +++ b/docs/deploying.rst @@ -228,3 +228,278 @@ merged into the main branch, you can release into *edge* with ``charm release under the staging user as usual to test your change. Staging tracks edge by default. + + +Setting up firewall configs +--------------------------- + +This section assumes the reader is familiar with the relevant repos. + +The steps here mostly apply to the scenario where the bastion is being migrated. + +Some steps are more general. + +When adding things to files in this repo, please make sure any additions are at +a point in the file which makes sense. If you're adding definitions relevant to +proposed-migration, please, if applicable, group any additions with pre-existing +config relating to proposed migration. + +Before creating an MP, please ``lpci run`` locally. This will check that the +changes you have made don't break anything and ``lpci run`` passing is a pre-requisite +for a firewall change to be merged. + +Add the new subnet +^^^^^^^^^^^^^^^^^^ + +Navigate to ``services/ues/proposed-migration.yaml``. + +Add the subnet, with a comment, to the relevant definition. + +For instance, make sure lines like the following are present: + +.. code-block:: + subnets: + XXXstack-fixed: + - subnets/scalingstack-INST-proposed-migration-fixed + psX: + - 192.168.1.0/24 # INST-proposed-migration + +The subnet should be the subnet the juju machines are on. + +You can check this subnet by connecting to the relevant bastion, +and running a ``juju status``. The machines should all be on +the same subnet, and this is the subnet you will put in the +file mentioned above. + +Allow access to juju2 controllers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Navigate to ``rules/is/juju.yaml`` and ``defs/subnets.yaml``. + +``defs/subnets.yaml`` contains the relevant information for +the subnets associated with the datacentres the run tests. + +This should be something we don't need to worry about, but it's +something notable for debugging, and to our infrastructure in +general. + +It's important that the datacentres have a connection to the jujud-api. + +Declaration of subnets +^^^^^^^^^^^^^^^^^^^^^^ + +Navigate to ``defs/subnets.yaml``. + +Search for ``proposed-migration``. There are definitions with this string +for a number of things - datacentres for workers, and bastions, old and new. +So it's imperative to check you're declaring the subnets in the appropriate manner +with appropriate naming. + +The subnet must be declared in ``developer-managed-services-networks-ps45``. +There is a section at the beginning of this section, where the subnet name is +declared. + +Laterally, still under ``developer-managed-services-networks-ps45``, the subnet +is defined using the name declared in the section above. + +You can find out the subnet by navigating to the relevant bastion and running +``juju status`` again. The subnet is the subnet all of the juju machines are on. + +There is also relevant sections regarding subnets in ``defs/prodstack.yaml`` which +need amending. There should be a section ``XX-group``, like so: + +.. code-block:: + prod-foundations: + ip: XXX.XXX.XXX.XXX + subnets: + - XXX.XXX.XXX.0/24 # subnet_XXX-proposed-migration-environment + +Don't worry about the ``ip:`` field for this section. Make sure the subnet +and the commented name are correct for the relevant bastion. + +Allow communication with influxdb +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Navigate to ``rules/is/ubuntu-kpi.yaml``. + +There is a section with the comment "Allow proposed-migration ranges to talk to influxdb" + +Make sure the subnet you declared in the steps above is in the ``from:`` section, and +that subnet will now have communication with influxdb. + +Allow communication to scalingstack +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Navigate to ``rules/is/scalingstack.yaml``. + +This is subject to change, but there should be a section which looks like this: + + +.. code-block:: + + - comment: "production proposed-migration, RT#82024" + + from: + + - services/is/prodstack/devops-management-host + + - services/ues/proposed-migration/router-ps45 + + - services/ues/proposed-migration/ps5 + + to: [services/is/scalingstack/infra] + + ports: [keystone-auth, openstack-os, openstack-s3, neutron-api, glance] + +Apply the above rule to the relevant bastion. + +Allow communication to relevant "stack" API's +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Navigate to ``rules/is/ps5.yaml``. + +A section like the following should be present in this file. + +.. code-block:: + + - comment: "Allow proposed-migration to PS5 API" + + from: [services/ues/proposed-migration/ps5] + + to: [services/is/ps5/nova] + + ports: [openstack-os] + + + + - comment: "Allow proposed-migration to PS5 Glance" + + from: [services/ues/proposed-migration/ps5] + + to: [services/is/ps5/glance] + + ports: [glance] + + + + - comment: "Allow proposed-migration to PS5 Neutron" + + from: [services/ues/proposed-migration/ps5] + + to: [services/is/ps5/neutron] + + ports: [neutron-api] + +The section above should be present and should include the relevant bastion. + +Check the relevant definitions for the above ``from:`` tags. + + +Add public IP's for haproxy and rabbitmq +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Navigate to ``defs/prodstack.yaml``. + +Under the section ``floating-ips:``, add a line like this: + +.. code-block:: + XXX.XXX.XXX.XXX: YYY.YYY.YYY.YYY + +Where the ``X`` ip is the public ip, and the ``Y`` is the private ip. + +Do this for both the haproxy machine and the rabbitmq machine on the +relevant bastion. + +The public ip's are incremental. + +Grant access to swift storage +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Navigate to ``rules/is/ps5.yaml``. + +For the new bastion, you must add a new section like so: + +.. code-block:: + - comment: "Allow prod-proposed-migration-environment to talk to PS5 swift (radosgw Object storage) to grab logs" + from: + - services/ues/proposed-migration/ps5 + - subnets/prod-proposed-migration-ps5 + to: [services/is/ps5/radosgw] + ports: [https] + +Where the relevant ``services/`` and ``subnets/`` are correct. + +Grant access to salsa (?) +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Navigate to ``rules/ues/proposed-migration.yaml``. + +A section should exist as follows: + +.. code-block:: + - comment: "production proposed-migration, RT#82024" + from: + - services/ues/proposed-migration/relevant-service + to: + - external/debian/salsa + ports: [http, https, git] + + +Allow connection to lxd images +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This is necessary for running tests on armhf, as we use lxc images for armhf. + +Navigate to ``rules/ues/proposed-migration.yaml``. + +A section should exist as follows: + +.. code-block:: + - comment: "connection to lxc images" + from: [services/ues/proposed-migration/relevant-service] + to: [external/linuxcontainers/images] + ports: [https-alt] + +Allow communication with github API +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This is necessary for github webhook integration. + +Navigate to ``rules/ues/proposed-migration.yaml``. + +A section should exist as follows: + +.. code-block:: + - comment: "allow blah to talk to github" + from: + - services/ues/proposed-migration/relevant-service + to: + - external/github/api + - external/github/git + - external/github/web + ports: [http, https, git] + + +Setting up the proxy config +--------------------------- + +This section also assumes the reader is familiar with the relevant repo. + +When adding things to files in this repo, please make sure any additions are at +a point in the file which makes sense. If you're adding definitions relevant to +proposed-migration, please, if applicable, group any additions with pre-existing +config relating to proposed migration. + +Before creating an MP, please ``lpci run`` locally. This will check that the +changes you have made don't break anything and ``lpci run`` passing is a pre-requisite +for a firewall change to be merged. + +Declare the subnet +^^^^^^^^^^^^^^^^^^ + +Navigate to ``squid.conf``. + +Add a line like so: + +.. code-block:: + acl ues_proposed_migration_XX src XXX.XXX.XXX.0/24 + +Allow communication with github +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To the same ``squid.conf`` file, add a line like so: + +.. code-block:: + http_access allow ues_proposed_migration_XX github_api + +Allow communication with snapcraft +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Again, altering ``squid.conf``, add a line like so: + +.. code-block:: + http_access allow ues_proposed_migration_XX parts_snapcraft_io + +Allow communication with salsa +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +TBD.
-- Mailing list: https://launchpad.net/~canonical-ubuntu-qa Post to : canonical-ubuntu-qa@lists.launchpad.net Unsubscribe : https://launchpad.net/~canonical-ubuntu-qa More help : https://help.launchpad.net/ListHelp
