February 2019 - openstack-discuss

[dev][swift] Regarding fstab entries in a Swift controller
by Vedartham Bharath 25 Feb '19

25 Feb '19

Hi all, This is with regards to an issue in the documentation of Openstack Swift and mostly an issue to system administrators operating Swift.(Sorry if the subject tags are wrong!!) In the Swift Multiserver docs, When setting up an object storage server, the docs tell to use the disk labels in the disk's /etc/fstab entries. eg: /dev/sda /srv/node/sda xfs noatime............. I feel that we should encourage people to use UUIDs rather than disk labels. I have had a lot of issues with my Swift storage servers crashing whenever I reboot them. I have found out that the issue is with the /etc/fstab as the disk labels change whenever a disk is removed or added(depends on the OS's "mood" i.e boot order). I don't want to change my ring configuration every time I reboot my storage servers. Thank you Bharath

1 0

[openstack-dev] [Monasca] How to get “aggregated value of one metric statistics” ?
by Mohan Kumar 25 Feb '19

25 Feb '19

Hi Team, How to get “aggregated value of one metric statistics” from starting of month to till now . If I try to group metrics using * --period* based on timestamp it including data from previous month metrics as well [1] In below example , trying to get last ~24.5 days of metrics from particular tenant , But I can see 2019-01-26 data . With UTC_START_TIME “2019-02-01T00:00:00Z” [2] does *--merge_metrics * not Merge multiple metrics into a single result ? Please suggest how to customise my API call to get “AVG (aggregated) value of one metric statistics” from starting of month to till now . *Regards.,* Mohankumar N "*Confidentiality Warning*: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system. *Virus Warning:* Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."

2 2

[oslo] Feature freeze this week
by Ben Nemec 25 Feb '19

25 Feb '19

Just a reminder that Oslo feature freeze happens this week. Yes, it's earlier than everyone else, and if you're wondering why, we have a policy[1] that discusses it. The main thing is that if you have features you want to get into Oslo libraries this cycle, please make sure they merge by Friday. After that we'll need to go through the FFE process and there's no guarantee we can land them. Feel free to ping us on IRC if you need reviews. Thanks. -Ben 1: http://specs.openstack.org/openstack/oslo-specs/specs/policy/feature-freeze…

1 1

[tripleo] nominating Harald Jensås as a core reviewer
by Juan Antonio Osorio Robles 25 Feb '19

25 Feb '19

Hey folks! I would like to nominate Harald as a general TripleO core reviewer. He has consistently done quality reviews throughout our code base, helping us with great feedback and technical insight. While he has done a lot of work on the networking and baremetal sides of the deployment, he's also helped out on security, CI, and even on the tripleoclient side. Overall, I think he would be a great addition to the core team, and I trust his judgment on reviews. What do you think? Best regards

11 10

[openstack-dev] [Monasca] How to get “aggregated value of one metric statistics” ?
by Mohan Kumar 25 Feb '19

25 Feb '19

Hi Team, How to get “aggregated value of one metric statistics” from starting of month to till now . If I try to group metrics using * --period* based on timestamp it including data from previous month metrics as well [1] In below example , trying to get last ~24.5 days of metrics from particular tenant , But I can see 2019-01-26 data . With UTC_START_TIME “2019-02-01T00:00:00Z” [2] does *--merge_metrics * not Merge multiple metrics into a single result ? Please suggest how to customise my API call to get “AVG (aggregated) value of one metric statistics” from starting of month to till now . *Regards.,* Mohankumar N "*Confidentiality Warning*: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system. *Virus Warning:* Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."

1 0

[openstack-dev] [Monasca] How to get “aggregated value of one metric statistics” ?
by Mohan Kumar 25 Feb '19

25 Feb '19

Hi Team, How to get “aggregated value of one metric statistics” from starting of month to till now . If I try to group metrics using * --period* based on timestamp it including data from previous month metrics as well [1] In below example , trying to get last ~24.5 days of metrics from particular tenant , But I can see 2019-01-26 data . With UTC_START_TIME “2019-02-01T00:00:00Z” [2] does *--merge_metrics * not Merge multiple metrics into a single result ? Please suggest how to customise my API call to get “AVG (aggregated) value of one metric statistics” from starting of month to till now . *Regards.,* Mohankumar N "*Confidentiality Warning*: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system. *Virus Warning:* Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."

1 0

[searchlight] Team meeting cancelled today
by Trinh Nguyen 25 Feb '19

25 Feb '19

Hi team, I'll be out of the office for the rest of the day so I cannot hold the team meeting at 13:30 UTC today. Meeting will happen again on 11th March. Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[tripleo][ironic] What I had to do to get standalone ironic working with ovn enabled
by Lars Kellogg-Stedman 25 Feb '19

25 Feb '19

I'm using the tripleo standalone install to set up an Ironic test environment. With recent tripleo master, the deploy started failing because the DockerOvn*Image parameters weren't defined. Here's what I did to get everything working: 1. I added to my deploy: -e /usr/share/tripleo-heat-templates/environment/services/neutron-ovn-standalone.yaml With this change, `openstack tripleo container image prep` correctly detected that ovn was enabled and generated the appropriate image parameters. 2. environments/services/ironic.yaml sets: NeutronMechanismDrivers: ['openvswitch', 'baremetal'] Since I didn't want openvswitch enabled in this deployment, I explicitly set the mechanism drivers in a subsequent environment file: NeutronMechanismDrivers: ['ovn', 'baremetal'] 3. The neutron-ovn-standalone.yaml environment explicitly disables the non-ovn neutron services. Ironic requires the services of the neutron_dhcp_agent, so I had to add: OS::TripleO::Services::NeutronDhcpAgent: /usr/share/openstack-tripleo-heat-templates/deployment/neutron/neutron-dhcp-container-puppet.yaml With this in place, the ironic nodes were able to receive dhcp responses and were able to boot. 3. In order to provide the baremetal nodes with a route to the nova metadata service, I added the following to my deploy: NeutronEnableForceMetadata: true This provides the baremetal nodes with a route to 169.254.169.254 via the neutron dhcp namespace. 4. In order get the metadata service to respond correctly, I also had to enable the neutron metadata agent: OS::TripleO::Services::NeutronMetadataAgent: /usr/share/openstack-tripleo-heat-templates/deployment/neutron/neutron-metadata-container-puppet.yaml This returned my Ironic deployment to a functioning state: I can successfully boot baremetal nodes and provide them with configuration information via the metadata service. I'm curious if this was the *correct* solution, or if there was a better method of getting things working. -- Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ |

4 5

[tc][election] candidate question: managing change
by Doug Hellmann 23 Feb '19

23 Feb '19

We are consistently presented with the challenges of trying to convince our large community to change direction, collaborate across team boundaries, and work on features that require integration of several services. Other threads with candidate questions include discussions of some significant technical changes people would like to see in OpenStack's implementation. Taking one of those ideas, or one of your own idea, as inspiration, consider how you would make the change happen if it was your responsibility to do so. Which change management approaches that we have used unsuccessfully in the past did you expect to see work? Why do you think they failed? Which would you like to try again? How would you do things differently? What new suggestions do you have for addressing this recurring challenge? -- Doug

4 3

Re: [release] Release countdown for week R-15, May 14-18
by rocky700 23 Feb '19

23 Feb '19

The details which you have given will be very useful for the stack developers as they can know the basic process of it and developing a full stack-based programme will be easy for the developers. ----- apple ipad support -- Sent from: http://openstack.10931.n7.nabble.com/Developer-f2.html

1 0