canonical-ubuntu-qa team mailing list archive

[Tim Andersson <mp+456339@xxxxxxxxxxxxxxxxxx>]

Diff comments:

> diff --git a/docs/deploying.rst b/docs/deploying.rst
> index 85d853f..a0ba209 100644
> --- a/docs/deploying.rst
> +++ b/docs/deploying.rst
> @@ -228,3 +228,256 @@ 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.

add note about lpci run

> +
> +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.

Amend jujud-api to instead talk about the relevant juju controller (our controller)

> +
> +Declaration of subnets
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

fix length

> +
> +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 but are self explanatory.

"self explanatory" perhaps not good enough.

> +
> +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
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +

maybe write something lol. rules/is/ps5.yaml

> +
> +.. 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
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +This might be something we require IS' help for.

maybe we don't?

> +
> +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 (?)
> +^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Not sure if relevant (?)

remove

> +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

maybe add section on salsa as well?

> +---------------------------
> +
> +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.
> +
> +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


-- 
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.