Re: [Openstack-operators] [tc]Global Reachout Proposal
On Sat, 15 Sep 2018 02:49:40 +0900 Zhipeng Huang wrote > Hi all, > Follow up the diversity discussion we had in the tc session this morning > [0], I've proposed a resolution on facilitating technical community in large > to engage in global reachout for OpenStack more efficiently. > Your feedbacks are welcomed. Whether this should be a new resolution or not > at the end of the day, this is a conversation worthy to have. > [0] https://review.openstack.org/602697 I like that we are discussing the Global Reachout things which i personally feel is very important. There are many obstacle to have a standard global communication way. Honestly saying, there cannot be any standard communication channel which can accommodate different language, cultures , company/govt restriction. So the better we can do is best solution. I can understand that IRC cannot be used in China which is very painful and mostly it is used weChat. But there are few key points we need to consider for any social app to use? - Technical discussions which needs more people to participate and need ref of links etc cannot be done on mobile app. You need desktop version of that app. - Many of the social app have # of participation, invitation, logging restriction. - Those apps are not restricted to other place. - It does not split the community members among more than one app or exiting channel. With all those point, we need to think what all communication channel we really want to promote as community. IMO, we should educate and motivate people to participate over existing channel like IRC, ML as much as possible. At least ML does not have any issue about usage. Ambassador and local user groups people can play a critical role here or local developers (i saw Alex volunteer for nova discussion in china) and they can ask them to start communication in ML or if they cannot then they can start the thread and proxy for them. I know slack is being used for Japan community and most of the communication there is in Japanese so i cannot help there even I join it. When talking to Akira (Japan Ambassador ) and as per him most of the developers do communicate in IRC, ML but users hesitate to do so because of culture and language. So if proposal is to participate community (Developers, TC, UC, Ambassador, User Group members etc) in local chat app and encourage people to move to ML etc then it is great idea. But if we want to promote all different chat app as community practice then, it can lead to lot of other problems than solving the current one. For example: It will divide the technical discussion etc -gmann > -- > Zhipeng (Howard) Huang > Standard EngineerIT Standard & Patent/IT Product LineHuawei Technologies > Co,. LtdEmail: huangzhipeng@huawei.comOffice: Huawei Industrial Base, > Longgang, Shenzhen > (Previous) > Research AssistantMobile Ad-Hoc Network Lab, Calit2University of California, > IrvineEmail: zhipengh@uci.eduOffice: Calit2 Building Room 2402 > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > ___ > 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] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)
Hope you all safely travel back to home now. Here is the summarize from some discussions (as much as I can trigger or attend) in PTG for SIGs/WGs expose and some idea for action, http://lists.openstack.org/pipermail/openstack-dev/2018-September/134689.html I also like the idea to at least expose the information of SIGs/WGs right away. Feel free to give your feedback. And not like the following message matters to anyone, but just in case. I believe this is a goal for all group in the community so just don't let who your duty, position, or full hand of good tasks to limit what you think about the relative of this goal with you. Give your positive or negative opinions to help us get a better shape. On Wed, Sep 12, 2018 at 11:47 PM Matt Riedemann wrote: > Rather than take a tangent on Kristi's candidacy thread [1], I'll bring > this up separately. > > Kristi said: > > "Ultimately, this list isn’t exclusive and I’d love to hear your and > other people's opinions about what you think the I should focus on." > > Well since you asked... > > Some feedback I gave to the public cloud work group yesterday was to get > their RFE/bug list ranked from the operator community (because some of > the requests are not exclusive to public cloud), and then put pressure > on the TC to help project manage the delivery of the top issue. I would > like all of the SIGs to do this. The upgrades SIG should rank and > socialize their #1 issue that needs attention from the developer > community - maybe that's better upgrade CI testing for deployment > projects, maybe it's getting the pre-upgrade checks goal done for Stein. > The UC should also be doing this; maybe that's the UC saying, "we need > help on closing feature gaps in openstack client and/or the SDK". I > don't want SIGs to bombard the developers with *all* of their > requirements, but I want to get past *talking* about the *same* issues > *every* time we get together. I want each group to say, "this is our top > issue and we want developers to focus on it." For example, the extended > maintenance resolution [2] was purely birthed from frustration about > talking about LTS and stable branch EOL every time we get together. It's > also the responsibility of the operator and user communities to weigh in > on proposed release goals, but the TC should be actively trying to get > feedback from those communities about proposed goals, because I bet > operators and users don't care about mox removal [3]. > > I want to see the TC be more of a cross-project project management > group, like a group of Ildikos and what she did between nova and cinder > to get volume multi-attach done, which took persistent supervision to > herd the cats and get it delivered. Lance is already trying to do this > with unified limits. Doug is doing this with the python3 goal. I want my > elected TC members to be pushing tangible technical deliverables forward. > > I don't find any value in the TC debating ad nauseam about visions and > constellations and "what is openstack?". Scope will change over time > depending on who is contributing to openstack, we should just accept > this. And we need to realize that if we are failing to deliver value to > operators and users, they aren't going to use openstack and then "what > is openstack?" won't matter because no one will care. > > So I encourage all elected TC members to work directly with the various > SIGs to figure out their top issue and then work on managing those > deliverables across the community because the TC is particularly well > suited to do so given the elected position. I realize political and > bureaucratic "how should openstack deal with x?" things will come up, > but those should not be the priority of the TC. So instead of > philosophizing about things like, "should all compute agents be in a > single service with a REST API" for hours and hours, every few months - > immediately ask, "would doing that get us any closer to achieving top > technical priority x?" Because if not, or it's so fuzzy in scope that no > one sees the way forward, document a decision and then drop it. > > [1] > > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134490.html > [2] > > https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html > [3] https://governance.openstack.org/tc/goals/rocky/mox_removal.html > > -- > > Thanks, > > Matt > > ___ > openstack-sigs mailing list > openstack-s...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Network metadata+userdata and rate limits
Hi, We’ve been providing our VMs with metadata from the network for quite some time now and lately we’ve realized that when we reboot compute nodes for updates (so roughly 200 VMs are rebooting at once), some VM can’t access the metadata server. I believe this could be because of the nova-api ratelimiting, but I was unable to find proofs in the logs (No 403 forbidden at all in the log file). So, I was wondering : -Can I disable the nova-api ratelimiting from paste-api.ini just as it was possible in kilo? -Can I prevent cloud-init from running its latest user-data when it doesn’t receive metadata? We currently use Pike on centos 7. Jean-Philippe Méthot Openstack system administrator Administrateur système Openstack PlanetHoster inc. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Forum Topic Submission Period
Hello Everyone! The Forum Topic Submission session started September 12 and will run through September 26th. Now is the time to wrangle the topics you gathered during your Brainstorming Phase and start pushing forum topics through. Don't rely only on a PTL to make the agenda... step on up and place the items you consider important front and center. As you may have noticed on the Forum Wiki (https://wiki.openstack.org/wiki/Forum), we're reusing the normal CFP tool this year. We did our best to remove Summit specific language, but if you notice something, just know that you are submitting to the Forum. URL is here: https://www.openstack.org/summit/berlin-2018/call-for-presentations Looking forward to seeing everyone's submissions! If you have questions or concerns about the process, please don't hesitate to reach out. Cheers, Jimmy ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [TripleO] undercloud sshd config override
That solved my problem. Thank you so much, Alex. Best regards, Cody On Mon, Sep 17, 2018 at 11:42 AM Alex Schultz wrote: > > On Fri, Sep 14, 2018 at 9:41 AM, Cody wrote: > > Hello folks, > > > > I installed TripleO undercloud on a machine with a pre-existing > > sshd_config that disabled root and password login. The file was > > rewritten by Puppet after the undercloud installation and was made to > > allow for both options. This is not a good default practice. Is there > > a way to set the undercloud to respect any pre-existing sshd_config > > settings? > > > > It depends on the version you're using. The basics are that you'll > have to provide your sshd_config to the undercloud installation so > that it can be merged with the one from tripleo. > > For >= Rocky you can use a custom_env_file to provide an updated > SshServerOptions. The default can be viewed: > https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/sshd.yaml#L41 > > For <= Queens you can use a hieradata override to specify an override > for tripleo::profile::base::sshd::options. The defaults can be > viewed: > https://github.com/openstack/instack-undercloud/blob/ed96987af5a77579366b27a44d94442f33cd811a/elements/puppet-stack-config/os-apply-config/etc/puppet/hieradata/RedHat.yaml#L3 > > Thanks, > -Alex > > > Thank you to all. > > > > Regards, > > Cody > > > > ___ > > 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] [TripleO] undercloud sshd config override
On Fri, Sep 14, 2018 at 9:41 AM, Cody wrote: > Hello folks, > > I installed TripleO undercloud on a machine with a pre-existing > sshd_config that disabled root and password login. The file was > rewritten by Puppet after the undercloud installation and was made to > allow for both options. This is not a good default practice. Is there > a way to set the undercloud to respect any pre-existing sshd_config > settings? > It depends on the version you're using. The basics are that you'll have to provide your sshd_config to the undercloud installation so that it can be merged with the one from tripleo. For >= Rocky you can use a custom_env_file to provide an updated SshServerOptions. The default can be viewed: https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/sshd.yaml#L41 For <= Queens you can use a hieradata override to specify an override for tripleo::profile::base::sshd::options. The defaults can be viewed: https://github.com/openstack/instack-undercloud/blob/ed96987af5a77579366b27a44d94442f33cd811a/elements/puppet-stack-config/os-apply-config/etc/puppet/hieradata/RedHat.yaml#L3 Thanks, -Alex > Thank you to all. > > Regards, > Cody > > ___ > 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
