[Openstack-operators] Ops Meetups Team - meeting minutes from today's IRC meeting
We had a brief meeting today, minutes linked below. Topic included restarting the operator-related docs, prep for Denver PTG and some organisational things for the team. We'll meet bi-weekly at 10am EST for the time being, so next meeting is 2018-6-19 at 10 am EST Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_team.2018-06-05-14.25.html 10:52 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_team.2018-06-05-14.25.txt 10:52 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_team.2018-06-05-14.25.log.html -- Chris Morgan ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [FEMDC] meetings suspended until further notice
Dear all, Following the exchanges we had during the Vancouver summit, in particular the non-sense to maintain/animate two groups targeting similar challenges (ie., the FEMDC SIG [1] and the new Edge Computing Working group [2]), FEMDC meetings are suspended until further notice. If you are interested by Edge Computing discussions, please see information available on the new edge wiki page [2]. Thanks ad_ri3n_ [1]https://wiki.openstack.org/wiki/Fog_Edge_Massively_Distributed_Clouds [2]https://wiki.openstack.org/wiki/Edge_Computing_Group ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-ansible][releases][governance] Change in OSA roles tagging
Excerpts from Jean-Philippe Evrard's message of 2018-06-05 10:14:12 +0200: > Hello, > > *TL:DR;* If you are an openstack-ansible user, consuming our roles directly, > with tags, without using openstack-ansible plays or integrated repo, > then things will change for you. Start using git shas instead of tags. > All other openstack-ansible users should not see a difference, even if > they use openstack-ansible tags. > > > During the summit, I had a discussion with dhellman (and smcginnis) > to change how openstack-ansible does its releases. > > Currently, we tag openstack-ansible + many roles under our umbrella > every two weeks. As far as I know, nobody requested to have roles > tagged every two weeks. Only OpenStack-Ansible need to be tagged > for consumption. Even people using our roles directly outside > openstack-ansible generally use sha for roles. We don't rely on > ansible galaxy. > > Because there is no need to tag the roles, there is no need to make them > part of the "openstack-ansible" deliverable [1][2]. I will therefore > clarify the governance repo for that, separating the roles, each of them > with their own deliverable, instead of grouping some roles within > openstack-ansible, and some others outside it. > > With this done, a release of openstack-ansible becomes straightforward > using the standard release tooling. The releases of openstack-ansible > becomes far simpler to request, review, and will not have timeouts > anymore :p > > There are a few issues I see from the change. Still according to the > discussion, it seems we can overcome those. > > 1. As this will be applied on all the branches, we may reach some > issues with releasing in the next days. While the validate tooling > of releases has shown me that it wouldn't be a problem (just > warning) to not have all the repos in the deliverable, I would > expect a governance change could be impactful. > However, that is only impacting openstack-ansible, releases, > and governance team: Keep in mind, openstack-ansible will not > change for its users, and will still be tagged as you know it. > > 2. We will keep branching our roles the same way we do now. What > we liked for roles being part of this deliverable, is the ability > of having them automatically branched and their files adapted. > To what I heard, it is still possible to do so, by having a > devstack-like behavior, which branches on a sha, instead of > branching on tag. So I guess it means all our roles will now be > part of release files like this one [3], or even on a single release > file, similar to it. Right, you can set the stable-branch-type field to 'tagless' (see http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n462) and then set the branch location field to the SHA you want to use. If you would be ready to branch all of the roles at one time, you could put all of them into 1 deliverable file. Otherwise, you will want to split them up into their own files. And since you have so many, I will point out that we're really into automation over here on the release team, and if you wanted to work on making the edit-deliverable command smart enough to determine the SHA for you I could walk you through that code to get you started. Doug > > What I would like to have, from this email, is: > 1. Raise awareness to all the involved parties; > 2. Confirmation we can go ahead, from a governance standpoint; > 3. Confirmation we can still benefit from this automatic branch > tooling. > > Thank you in advance. > > Jean-Philippe Evrard (evrardjp) > > > [1]: > https://github.com/openstack/governance/blob/8215c5fd9b464b332b310bbb767812fefc5d9174/reference/projects.yaml#L2493-L2540 > [2]: > https://github.com/openstack/releases/blob/9db5991707458bbf26a4dd9f55c2a01fee96a45d/deliverables/queens/openstack-ansible.yaml#L768-L851 > [3]: > https://github.com/openstack/releases/blob/9db5991707458bbf26a4dd9f55c2a01fee96a45d/deliverables/queens/devstack.yaml > ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Switching from Fuel to OpenStack-Ansible
Hi both, Thanks for the info. Yep, I've had a look at the reference architecture and will probably end up running three controllers with six compute nodes using Ceph for storage. Initial thoughts are to put the Ceph OSDs on the compute nodes which each have 4x400GB SSD drives spare and use the controllers as the ceph monitors. It is a month or two until I start the migration so will hop on to IRC if I have any issues or questions! Cheers, Matt --- Dr Matt John Engineer (Service Delivery - COMSC) School of Computer Science & Informatics Cardiff University, 5 The Parade, Cardiff, CF24 3AA Tel: +44 2920 876536 joh...@cardiff.ac.uk The University welcomes correspondence in Welsh or English. Corresponding in Welsh will not lead to any delay. Dr Matt John Peiriannydd (Cyflwyno Gwasanaeth - COMSC) Ysgol Cyfrifiadureg a Gwybodeg Prifysgol Caerdydd, 5 The Parade, Caerdydd, CF24 3AA Ffôn : +44 2920 876536 joh...@caerdydd.ac.uk Mae'r Brifysgol yn croesawu gohebiaeth yn Gymraeg neu'n Saesneg. Ni fydd gohebu yn Gymraeg yn creu unrhyw oedi. From: Jean-Philippe Evrard Sent: 05 June 2018 09:14:52 To: Matthew John Cc: openstack-operators@lists.openstack.org Subject: Re: [Openstack-operators] Switching from Fuel to OpenStack-Ansible Hello, That's doable indeed! (In fact it's exactly what I did during Kilo timeframe! :p) Have you looked at the openstack-ansible deploy guide? It should help you understand the process. On the way it should link you to the reference architecture, where you can have more details about the network flows. Don't hesitate to join us on our IRC channel for more detailed questions, on freenode #openstack-ansible. If you want to continue by email, don't hesitate to put [openstack-ansible] in the email title :) Best regards, Jean-Philippe Evrard (evrardjp) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Switching from Fuel to OpenStack-Ansible
Hello, That's doable indeed! (In fact it's exactly what I did during Kilo timeframe! :p) Have you looked at the openstack-ansible deploy guide? It should help you understand the process. On the way it should link you to the reference architecture, where you can have more details about the network flows. Don't hesitate to join us on our IRC channel for more detailed questions, on freenode #openstack-ansible. If you want to continue by email, don't hesitate to put [openstack-ansible] in the email title :) Best regards, Jean-Philippe Evrard (evrardjp) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [openstack-ansible][releases][governance] Change in OSA roles tagging
Hello, *TL:DR;* If you are an openstack-ansible user, consuming our roles directly, with tags, without using openstack-ansible plays or integrated repo, then things will change for you. Start using git shas instead of tags. All other openstack-ansible users should not see a difference, even if they use openstack-ansible tags. During the summit, I had a discussion with dhellman (and smcginnis) to change how openstack-ansible does its releases. Currently, we tag openstack-ansible + many roles under our umbrella every two weeks. As far as I know, nobody requested to have roles tagged every two weeks. Only OpenStack-Ansible need to be tagged for consumption. Even people using our roles directly outside openstack-ansible generally use sha for roles. We don't rely on ansible galaxy. Because there is no need to tag the roles, there is no need to make them part of the "openstack-ansible" deliverable [1][2]. I will therefore clarify the governance repo for that, separating the roles, each of them with their own deliverable, instead of grouping some roles within openstack-ansible, and some others outside it. With this done, a release of openstack-ansible becomes straightforward using the standard release tooling. The releases of openstack-ansible becomes far simpler to request, review, and will not have timeouts anymore :p There are a few issues I see from the change. Still according to the discussion, it seems we can overcome those. 1. As this will be applied on all the branches, we may reach some issues with releasing in the next days. While the validate tooling of releases has shown me that it wouldn't be a problem (just warning) to not have all the repos in the deliverable, I would expect a governance change could be impactful. However, that is only impacting openstack-ansible, releases, and governance team: Keep in mind, openstack-ansible will not change for its users, and will still be tagged as you know it. 2. We will keep branching our roles the same way we do now. What we liked for roles being part of this deliverable, is the ability of having them automatically branched and their files adapted. To what I heard, it is still possible to do so, by having a devstack-like behavior, which branches on a sha, instead of branching on tag. So I guess it means all our roles will now be part of release files like this one [3], or even on a single release file, similar to it. What I would like to have, from this email, is: 1. Raise awareness to all the involved parties; 2. Confirmation we can go ahead, from a governance standpoint; 3. Confirmation we can still benefit from this automatic branch tooling. Thank you in advance. Jean-Philippe Evrard (evrardjp) [1]: https://github.com/openstack/governance/blob/8215c5fd9b464b332b310bbb767812fefc5d9174/reference/projects.yaml#L2493-L2540 [2]: https://github.com/openstack/releases/blob/9db5991707458bbf26a4dd9f55c2a01fee96a45d/deliverables/queens/openstack-ansible.yaml#L768-L851 [3]: https://github.com/openstack/releases/blob/9db5991707458bbf26a4dd9f55c2a01fee96a45d/deliverables/queens/devstack.yaml ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
