Re: [Openstack-operators] Ops Community Documentation - first anchor point
Reviving this thread with a fresh start. See below for the original. To recap, the ops community is willing to take over some of the operator documentation that is no longer available due to the loss of documentation team resources. From discussions, there needs to be some official governance over this operator owned repo (or repos) so it is recommended that a sig be formed. The repos can be created in the meantime, but consideration needs to be taken about naming as by default, the repo name is what is reflected in the documentation publishing location. SIG Formation - There were a couple suggestions on naming and focus for this sig, but I would like to make a slightly different proposal. I would actually like to see a sig-operator group formed. We have repos for operator tools and other useful things and we have a mix of operators, vendors, and others that work together on things like the ops meetup. I think it would make sense to make this into an official SIG that could have a broader scope than just documentation. Docs Repos -- Doug made a good suggestion that we may want these things published under something like docs.openstack.org/operations-guide. So based on this, I think for now at least we should create an opestack/operations-guide repo that will end up being owned by this SIG. I would expect most documentation generated or owned by this group would just be located somewhere under that repo, but if the need arises we can add additional repos. There are other ops repos out there right now. I would expect the ownership of those to move under this sig as well, but that is a seperate and less pressing concern at this point. Bug Tracking There should be some way to track tasks and needs for this documentation and any other repos that are moved under this sig. Since it is the currently planned direction for all OpenStack projects (or at least there is a vocal desire for it to be) I think a Storyboard project should be created for this SIG's activities. Plan So to recap above, I would propose the following actions be taken: 1. Create sig-operators as a group to manage operator efforts at least related to what needs to be done in repos. 2. Create an openstack/operations-guide repo to be the new home of the operations documentation. 3. Create a new StoryBoard project to help track work in these repos x. Document all this. 9. Profit! I'm willing to work through the steps to get these things set up. Please give feedback if this proposed plan makes sense or if there is anything different that would be preferred. Thanks, Sean On Wed, May 23, 2018 at 06:38:32PM -0700, Chris Morgan wrote: > Hello Everyone, > > In the Ops Community documentation working session today in Vancouver, we > made some really good progress (etherpad here: > https://etherpad.openstack.org/p/YVR-Ops-Community-Docs but not all of the > good stuff is yet written down). > > In short, we're going to course correct on maintaining the Operators Guide, > the HA Guide and Architecture Guide, not edit-in-place via the wiki and > instead try still maintaining them as code, but with a different, new set > of owners, possibly in a new Ops-focused repo. There was a strong consensus > that a) code workflow >> wiki workflow and that b) openstack core docs > tools are just fine. > > There is a lot still to be decided on how where and when, but we do have an > offer of a rewrite of the HA Guide, as long as the changes will be allowed > to actually land, so we expect to actually start showing some progress. > > At the end of the session, people wanted to know how to follow along as > various people work out how to do this... and so for now that place is this > very email thread. The idea is if the code for those documents goes to live > in a different repo, or if new contributors turn up, or if a new version we > will announce/discuss it here until such time as we have a better home for > this initiative. > > Cheers > > Chris > > -- > Chris Morgan > ___ > 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] Ops Community Documentation - first anchor point
This sounds great. As I understand it Sean can set up a skeleton for us to work on ops docs (and maybe other things later) with a minimum of initiation energy. Count me in. Chris On Tue, Jun 26, 2018 at 12:42 PM Sean McGinnis wrote: > Reviving this thread with a fresh start. See below for the original. > > To recap, the ops community is willing to take over some of the operator > documentation that is no longer available due to the loss of documentation > team > resources. From discussions, there needs to be some official governance > over > this operator owned repo (or repos) so it is recommended that a sig be > formed. > The repos can be created in the meantime, but consideration needs to be > taken > about naming as by default, the repo name is what is reflected in the > documentation publishing location. > > SIG Formation > - > There were a couple suggestions on naming and focus for this sig, but I > would > like to make a slightly different proposal. I would actually like to see a > sig-operator group formed. We have repos for operator tools and other > useful > things and we have a mix of operators, vendors, and others that work > together > on things like the ops meetup. I think it would make sense to make this > into an > official SIG that could have a broader scope than just documentation. > > Docs Repos > -- > Doug made a good suggestion that we may want these things published under > something like docs.openstack.org/operations-guide. So based on this, I > think > for now at least we should create an opestack/operations-guide repo that > will > end up being owned by this SIG. I would expect most documentation > generated or > owned by this group would just be located somewhere under that repo, but > if the > need arises we can add additional repos. > > There are other ops repos out there right now. I would expect the > ownership of > those to move under this sig as well, but that is a seperate and less > pressing > concern at this point. > > Bug Tracking > > There should be some way to track tasks and needs for this documentation > and > any other repos that are moved under this sig. Since it is the currently > planned direction for all OpenStack projects (or at least there is a vocal > desire for it to be) I think a Storyboard project should be created for > this > SIG's activities. > > Plan > > So to recap above, I would propose the following actions be taken: > > 1. Create sig-operators as a group to manage operator efforts at least > related >to what needs to be done in repos. > 2. Create an openstack/operations-guide repo to be the new home of the >operations documentation. > 3. Create a new StoryBoard project to help track work in these repos > x. Document all this. > 9. Profit! > > I'm willing to work through the steps to get these things set up. Please > give > feedback if this proposed plan makes sense or if there is anything > different > that would be preferred. > > Thanks, > Sean > > On Wed, May 23, 2018 at 06:38:32PM -0700, Chris Morgan wrote: > > Hello Everyone, > > > > In the Ops Community documentation working session today in Vancouver, we > > made some really good progress (etherpad here: > > https://etherpad.openstack.org/p/YVR-Ops-Community-Docs but not all of > the > > good stuff is yet written down). > > > > In short, we're going to course correct on maintaining the Operators > Guide, > > the HA Guide and Architecture Guide, not edit-in-place via the wiki and > > instead try still maintaining them as code, but with a different, new set > > of owners, possibly in a new Ops-focused repo. There was a strong > consensus > > that a) code workflow >> wiki workflow and that b) openstack core docs > > tools are just fine. > > > > There is a lot still to be decided on how where and when, but we do have > an > > offer of a rewrite of the HA Guide, as long as the changes will be > allowed > > to actually land, so we expect to actually start showing some progress. > > > > At the end of the session, people wanted to know how to follow along as > > various people work out how to do this... and so for now that place is > this > > very email thread. The idea is if the code for those documents goes to > live > > in a different repo, or if new contributors turn up, or if a new version > we > > will announce/discuss it here until such time as we have a better home > for > > this initiative. > > > > Cheers > > > > Chris > > > > -- > > Chris Morgan > > > ___ > > OpenStack-operators mailing list > > OpenStack-operators@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > -- Chris Morgan ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Ops Community Documentation - first anchor point
> > Plan > > So to recap above, I would propose the following actions be taken: > > 1. Create sig-operators as a group to manage operator efforts at least related >to what needs to be done in repos. > 2. Create an openstack/operations-guide repo to be the new home of the >operations documentation. One correction to this - that repo already exists. It has been retired, so I think the action here would just be to "un-retire" the repo and get things updated to start publishing again. > 3. Create a new StoryBoard project to help track work in these repos > x. Document all this. > 9. Profit! > > I'm willing to work through the steps to get these things set up. Please give > feedback if this proposed plan makes sense or if there is anything different > that would be preferred. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] neutron-server memcached connections
In diagnosing a situation where a Pike deployment was intermittently
slower (in general), I discovered that it was (sometimes) exceeding
memcached's maximum connection limit, which is set to 4096.
Looking closer, ~2750 of the connections are from 8 neutron-server
process. neutron-server is configured with 8 API workers, and those 8
processes have a combined total of ~2750 connections to memcached:
# lsof -i TCP:11211 | awk '/^neutron-s/ {print $2}' | sort | uniq -c
245 2611
306 2612
228 2613
406 2614
407 2615
385 2616
369 2617
398 2618
#
There doesn't seem to be much turnover - comparing samples of the
connections (incl. source port) 15 mins apart, two were dropped, and one
new one added.
In neutron.conf, keystone_authtoken.memcached_servers is configured, but
nothing else pertaining to caching, so
keystone_authtoken.memcache_pool_maxsize should default to 10.
Am I misunderstanding something, or shouldn't I see a maximum of 10
connections from each of the neutron-server API workers, with this
configuration?
Any known issues, or pointers to what I'm missing?
TIA,
~iain
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Ops Community Documentation - first anchor point
On Tue, 26 Jun 2018 12:36:52 -0500 Sean McGinnis wrote: > > > > Plan > > > > So to recap above, I would propose the following actions be taken: > > > > 1. Create sig-operators as a group to manage operator efforts at least > > related > >to what needs to be done in repos. > > 2. Create an openstack/operations-guide repo to be the new home of the > >operations documentation. > > One correction to this - that repo already exists. It has been retired, so I > think the action here would just be to "un-retire" the repo and get things > updated to start publishing again. That's great, looks like most of the skeleton from https://github.com/openstack/operations-guide/tree/c628640944c9de139b4bc9dee80885060d4b6f83 can just be reused. For step 2, let's start with moving https://github.com/openstack/openstack-manuals/tree/a1f1748478125ccd68d90a98ccc06c7ec359d3a0/doc/ops-guide from openstack-manuals, then. Other guides like ha or architecture can live in their own repos, if the new SIG wants to own them, or can be merged into the operations guide later on. > > 3. Create a new StoryBoard project to help track work in these repos > > x. Document all this. > > 9. Profit! > > > > I'm willing to work through the steps to get these things set up. Please > > give > > feedback if this proposed plan makes sense or if there is anything different > > that would be preferred. Thanks for the recap and for your help, Sean. If you need help from the docs team side, please let me know / CC me on your patches. Cheers, pk ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Ops Community Documentation - first anchor point
Sean put together some really great things here and I do think the SiG might be the way to go as far as ownership for the repos and the plan looks pretty complete. I've offered to do the Git and Gerrit Lunch and Learn at the OPS mmetup if needed to help get folks set up and going. Amy (spotz) On Tue, Jun 26, 2018 at 11:42 AM, Sean McGinnis wrote: > Reviving this thread with a fresh start. See below for the original. > > To recap, the ops community is willing to take over some of the operator > documentation that is no longer available due to the loss of documentation > team > resources. From discussions, there needs to be some official governance > over > this operator owned repo (or repos) so it is recommended that a sig be > formed. > The repos can be created in the meantime, but consideration needs to be > taken > about naming as by default, the repo name is what is reflected in the > documentation publishing location. > > SIG Formation > - > There were a couple suggestions on naming and focus for this sig, but I > would > like to make a slightly different proposal. I would actually like to see a > sig-operator group formed. We have repos for operator tools and other > useful > things and we have a mix of operators, vendors, and others that work > together > on things like the ops meetup. I think it would make sense to make this > into an > official SIG that could have a broader scope than just documentation. > > Docs Repos > -- > Doug made a good suggestion that we may want these things published under > something like docs.openstack.org/operations-guide. So based on this, I > think > for now at least we should create an opestack/operations-guide repo that > will > end up being owned by this SIG. I would expect most documentation > generated or > owned by this group would just be located somewhere under that repo, but > if the > need arises we can add additional repos. > > There are other ops repos out there right now. I would expect the > ownership of > those to move under this sig as well, but that is a seperate and less > pressing > concern at this point. > > Bug Tracking > > There should be some way to track tasks and needs for this documentation > and > any other repos that are moved under this sig. Since it is the currently > planned direction for all OpenStack projects (or at least there is a vocal > desire for it to be) I think a Storyboard project should be created for > this > SIG's activities. > > Plan > > So to recap above, I would propose the following actions be taken: > > 1. Create sig-operators as a group to manage operator efforts at least > related >to what needs to be done in repos. > 2. Create an openstack/operations-guide repo to be the new home of the >operations documentation. > 3. Create a new StoryBoard project to help track work in these repos > x. Document all this. > 9. Profit! > > I'm willing to work through the steps to get these things set up. Please > give > feedback if this proposed plan makes sense or if there is anything > different > that would be preferred. > > Thanks, > Sean > > On Wed, May 23, 2018 at 06:38:32PM -0700, Chris Morgan wrote: > > Hello Everyone, > > > > In the Ops Community documentation working session today in Vancouver, we > > made some really good progress (etherpad here: > > https://etherpad.openstack.org/p/YVR-Ops-Community-Docs but not all of > the > > good stuff is yet written down). > > > > In short, we're going to course correct on maintaining the Operators > Guide, > > the HA Guide and Architecture Guide, not edit-in-place via the wiki and > > instead try still maintaining them as code, but with a different, new set > > of owners, possibly in a new Ops-focused repo. There was a strong > consensus > > that a) code workflow >> wiki workflow and that b) openstack core docs > > tools are just fine. > > > > There is a lot still to be decided on how where and when, but we do have > an > > offer of a rewrite of the HA Guide, as long as the changes will be > allowed > > to actually land, so we expect to actually start showing some progress. > > > > At the end of the session, people wanted to know how to follow along as > > various people work out how to do this... and so for now that place is > this > > very email thread. The idea is if the code for those documents goes to > live > > in a different repo, or if new contributors turn up, or if a new version > we > > will announce/discuss it here until such time as we have a better home > for > > this initiative. > > > > Cheers > > > > Chris > > > > -- > > Chris Morgan > > > ___ > > 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/li
Re: [Openstack-operators] [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins
++ operator ML On Wed, 27 Jun 2018 10:17:33 +0900 Ghanshyam Mann wrote > > > > On Tue, 26 Jun 2018 23:12:30 +0900 Doug Hellmann > wrote > > Excerpts from Matthew Treinish's message of 2018-06-26 09:52:09 -0400: > > > On Tue, Jun 26, 2018 at 08:53:21AM -0400, Doug Hellmann wrote: > > > > Excerpts from Andrea Frittoli's message of 2018-06-26 13:35:11 +0100: > > > > > On Tue, 26 Jun 2018, 1:08 pm Thierry Carrez, > wrote: > > > > > > > > > > > Dmitry Tantsur wrote: > > > > > > > [...] > > > > > > > My suggestion: tempest has to be compatible with all supported > releases > > > > > > > (of both services and plugins) OR be branched. > > > > > > > [...] > > > > > > I tend to agree with Dmitry... We have a model for things that > need > > > > > > release alignment, and that's the cycle-bound series. The reason > tempest > > > > > > is branchless was because there was no compatibility issue. If > the split > > > > > > of tempest plugins introduces a potential incompatibility, then I > would > > > > > > prefer aligning tempest to the existing model rather than > introduce a > > > > > > parallel tempest-specific cycle just so that tempest can stay > > > > > > release-independent... > > > > > > > > > > > > I seem to remember there were drawbacks in branching tempest, > though... > > > > > > Can someone with functioning memory brain cells summarize them > again ? > > > > > > > > > > > > > > > > > > > > > Branchless Tempest enforces api stability across branches. > > > > > > > > I'm sorry, but I'm having a hard time taking this statement seriously > > > > when the current source of tension is that the Tempest API itself > > > > is breaking for its plugins. > > > > > > > > Maybe rather than talking about how to release compatible things > > > > together, we should go back and talk about why Tempest's API is > changing > > > > in a way that can't be made backwards-compatible. Can you give some > more > > > > detail about that? > > > > > > > > > > Well it's not, if it did that would violate all the stability > guarantees > > > provided by Tempest's library and plugin interface. I've not ever heard > of > > > these kind of backwards incompatibilities in those interfaces and we go > to > > > all effort to make sure we don't break them. Where did the idea that > > > backwards incompatible changes where being introduced come from? > > > > In his original post, gmann said, "There might be some changes in > > Tempest which might not work with older version of Tempest Plugins." > > I was surprised to hear that, but I'm not sure how else to interpret > > that statement. > > I did not mean to say that Tempest will introduce the changes in backward > incompatible way which can break plugins. That cannot happen as all plugins > and tempest are branchless and they are being tested with master Tempest so > if we change anything backward incompatible then it break the plugins gate. > Even we have to remove any deprecated interfaces from Tempest, we fix all > plugins first like - > https://review.openstack.org/#/q/topic:remove-support-of-cinder-v1-api+(status:open+OR+status:merged) > > > What I mean to say here is that adding new or removing deprecated interface > in Tempest might not work with all released version or unreleased Plugins. > That point is from point of view of using Tempest and Plugins in production > cloud testing not gate(where we keep the compatibility). Production Cloud > user use Tempest cycle based version. Pike based Cloud will be tested by > Tempest 17.0.0 not latest version (though latest version might work). > > This thread is not just for gate testing point of view (which seems to be > always interpreted), this is more for user using Tempest and Plugins for > their cloud testing. I am looping operator mail list also which i forgot in > initial post. > > We do not have any tag/release from plugins to know what version of plugin > can work with what version of tempest. For Example If There is new interface > introduced by Tempest 19.0.0 and pluginX start using it. Now it can create > issues for pluginX in both release model 1. plugins with no release (I will > call this PluginNR), 2. plugins with independent release (I will call it > PluginIR). > > Users (Not Gate) will face below issues: > - User cannot use PluginNR with Tempest <19.0.0 (where that new interface > was not present). And there is no PluginNR release/tag as this is unreleased > and not branched software. > - User cannot find a PluginIR particular tag/release which can work with > tempest <19.0.0 (where that new interface was not present). Only way for > user to make it work is to manually find out the PluginIR tag/commit before > PluginIR started consuming t
Re: [Openstack-operators] [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins
On Wed, 27 Jun 2018 10:19:17 +0900 Ghanshyam Mann wrote > ++ operator ML > > On Wed, 27 Jun 2018 10:17:33 +0900 Ghanshyam Mann > wrote > > > > > > > > On Tue, 26 Jun 2018 23:12:30 +0900 Doug Hellmann > wrote > > > Excerpts from Matthew Treinish's message of 2018-06-26 09:52:09 -0400: > > > > On Tue, Jun 26, 2018 at 08:53:21AM -0400, Doug Hellmann wrote: > > > > > Excerpts from Andrea Frittoli's message of 2018-06-26 13:35:11 > +0100: > > > > > > On Tue, 26 Jun 2018, 1:08 pm Thierry Carrez, > wrote: > > > > > > > > > > > > > Dmitry Tantsur wrote: > > > > > > > > [...] > > > > > > > > My suggestion: tempest has to be compatible with all > supported releases > > > > > > > > (of both services and plugins) OR be branched. > > > > > > > > [...] > > > > > > > I tend to agree with Dmitry... We have a model for things that > need > > > > > > > release alignment, and that's the cycle-bound series. The > reason tempest > > > > > > > is branchless was because there was no compatibility issue. If > the split > > > > > > > of tempest plugins introduces a potential incompatibility, > then I would > > > > > > > prefer aligning tempest to the existing model rather than > introduce a > > > > > > > parallel tempest-specific cycle just so that tempest can stay > > > > > > > release-independent... > > > > > > > > > > > > > > I seem to remember there were drawbacks in branching tempest, > though... > > > > > > > Can someone with functioning memory brain cells summarize them > again ? > > > > > > > > > > > > > > > > > > > > > > > > > Branchless Tempest enforces api stability across branches. > > > > > > > > > > I'm sorry, but I'm having a hard time taking this statement > seriously > > > > > when the current source of tension is that the Tempest API itself > > > > > is breaking for its plugins. > > > > > > > > > > Maybe rather than talking about how to release compatible things > > > > > together, we should go back and talk about why Tempest's API is > changing > > > > > in a way that can't be made backwards-compatible. Can you give > some more > > > > > detail about that? > > > > > > > > > > > > > Well it's not, if it did that would violate all the stability > guarantees > > > > provided by Tempest's library and plugin interface. I've not ever > heard of > > > > these kind of backwards incompatibilities in those interfaces and we > go to > > > > all effort to make sure we don't break them. Where did the idea that > > > > backwards incompatible changes where being introduced come from? > > > > > > In his original post, gmann said, "There might be some changes in > > > Tempest which might not work with older version of Tempest Plugins." > > > I was surprised to hear that, but I'm not sure how else to interpret > > > that statement. > > > > I did not mean to say that Tempest will introduce the changes in backward > incompatible way which can break plugins. That cannot happen as all plugins > and tempest are branchless and they are being tested with master Tempest so > if we change anything backward incompatible then it break the plugins gate. > Even we have to remove any deprecated interfaces from Tempest, we fix all > plugins first like - > https://review.openstack.org/#/q/topic:remove-support-of-cinder-v1-api+(status:open+OR+status:merged) > > > > > What I mean to say here is that adding new or removing deprecated > interface in Tempest might not work with all released version or unreleased > Plugins. That point is from point of view of using Tempest and Plugins in > production cloud testing not gate(where we keep the compatibility). > Production Cloud user use Tempest cycle based version. Pike based Cloud will > be tested by Tempest 17.0.0 not latest version (though latest version might > work). > > > > This thread is not just for gate testing point of view (which seems to be > always interpreted), this is more for user using Tempest and Plugins for > their cloud testing. I am looping operator mail list also which i forgot in > initial post. > > > > We do not have any tag/release from plugins to know what version of > plugin can work with what version of tempest. For Example If There is new > interface introduced by Tempest 19.0.0 and pluginX start using it. Now it > can create issues for pluginX in both release model 1. plugins with no > release (I will call this PluginNR), 2. plugins with independent release (I > will call it PluginIR). > > > > Users (Not Gate) will face below issues: > > - User cannot use PluginNR with Tempest <19.0.0 (where that new interface > was not present). And there is no PluginNR release/tag as this is unreleased > and not branched sof
