January 2019 - openstack-discuss - lists.openstack.org

[ALL] Train TC Election Season (Yes, TC not PTL)
by Kendall Nelson 17 Jan '19

17 Jan '19

Hello All! TC and not PTL you might ask? Yes! Due to the timing of the summit and release and optimizing timing so that they don't overlap, the technical elections this cycle will trade places and we will have the TC election first and then the PTL election. If you're curious about how this decision was made, feel free to check out the conversation during TC office hours here[1]. Election details: https://governance.openstack.org/election/ Please read the stipulations and timelines for candidates and electorate contained in this governance documentation. There will be further announcements posted to the mailing list as action is required from the electorate or candidates. This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. If you have any questions that you which to discuss in private please email any of the election officials[2] so that we may address your concerns. Thank you, -Kendall (diablo_rojo) [1] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019… [2] https://governance.openstack.org/election/#election-officials

1 0

[ironic] boot.ipxe input/output error
by Zufar Dhiyaulhaq 17 Jan '19

17 Jan '19

Hi, I try to install ironic but get error boot.ipxe input/output error when trying to cleaning the node (error image: https://ibb.co/mhN5GYc) This is my ironic configuration : *[DEFAULT]enabled_drivers=pxe_ipmitoolenabled_hardware_types = ipmilog_dir=/var/log/ironictransport_url=rabbit://guest:guest@10.60.60.10:5672/ <http://guest:guest@10.60.60.10:5672/>auth_strategy=keystonenotification_driver = messaging[conductor]send_sensor_data = trueautomated_clean=true[swift]region_name = RegionOneproject_domain_id = defaultuser_domain_id = defaultproject_name = servicespassword = IRONIC_PASSWORDusername = ironicauth_url = http://10.60.60.10:5000/v3 <http://10.60.60.10:5000/v3>auth_type = password[pxe]tftp_root=/tftpboottftp_server=10.60.60.10ipxe_enabled=Truepxe_bootfile_name=undionly.kpxeuefi_pxe_bootfile_name=ipxe.efipxe_config_template=$pybasedir/drivers/modules/ipxe_config.templateuefi_pxe_config_template=$pybasedir/drivers/modules/ipxe_config.templateipxe_use_swift=True[deploy]http_root=/httpboothttp_url=http://10.60.60.10:8080 <http://10.60.60.10:8080>[service_catalog]insecure = Trueauth_uri=http://10.60.60.10:5000/v3 <http://10.60.60.10:5000/v3>auth_type=passwordauth_url=http://10.60.60.10:35357 <http://10.60.60.10:35357>project_domain_id = defaultuser_domain_id = defaultproject_name = servicesusername = ironicpassword = IRONIC_PASSWORDregion_name = RegionOne[database]connection=mysql+pymysql://ironic:IRONIC_DBPASSWORD@10.60.60.10/ironic?charset=utf8 <http://ironic:IRONIC_DBPASSWORD@10.60.60.10/ironic?charset=utf8>[keystone_authtoken]auth_url=http://10.60.60.10:35357 <http://10.60.60.10:35357>www_authenticate_uri=http://10.60.60.10:5000 <http://10.60.60.10:5000>auth_type=passwordusername=ironicpassword=IRONIC_PASSWORDuser_domain_name=Defaultproject_name=servicesproject_domain_name=Default[neutron]www_authenticate_uri=http://10.60.60.10:5000 <http://10.60.60.10:5000>auth_type=passwordauth_url=http://10.60.60.10:35357 <http://10.60.60.10:35357>project_domain_name=Defaultproject_name=servicesuser_domain_name=Defaultusername=ironicpassword=IRONIC_PASSWORDcleaning_network = 461a6663-e015-4ecf-9076-d1b502c3db25provisioning_network = 461a6663-e015-4ecf-9076-d1b502c3db25[glance]region_name = RegionOneproject_domain_id = defaultuser_domain_id = defaultproject_name = servicespassword = IRONIC_PASSWORDusername = ironicauth_url = http://10.60.60.10:5000/v3 <http://10.60.60.10:5000/v3>auth_type = passwordswift_endpoint_url = http://10.60.60.10:8080/v1/AUTH_%(tenant_id)sswift_account = AUTH_f3bb39ae2e0946e1bbf812bcde6e08a7swift_container = glanceswift_temp_url_key = secret* I try to open the URL which is http://10.60.60.10:8080/boot.ipxe but always get BAD URL error. Are the Baremetal node cannot download the boot.ipxe? are my swift is broken? Thank you. Best Regards, Zufar Dhiyaulhaq

1 0

[release] Release countdown for week R-11, January 21-25
by Sean McGinnis 17 Jan '19

17 Jan '19

Welcome to the weekly countdown email. Development Focus ----------------- Teams should be focused on implementing planned work for the cycle. It is also a good time to review those plans and reprioritize anything if needed based on the what progress has been made and what looks realistic to complete in the next few weeks. General Information ------------------- Looking ahead to Stein-3, please be aware of the various freeze dates. This varies for deliverable type, starting with non-client libraries, then client libraries, then finally services. This is to ensure we have time for requirements updates and resolving any issues prior to RC. Just as a reminder, we have freeze dates ahead of the first RC in order to stabilize our requirements. Updating global requirements close to overall code freeze increases the risk of an unforeseen side effect being introduced too late in the cycle to properly fix. For this reason, we first freeze the non-client libraries that may be used by service and client libraries, followed a week later by the client libraries. This minimizes the ripple effects that have caused projects to scamble to fix last minute issues. Please keep these deadlines in mind as you work towards wrapping up feature work that may require library changes to complete. Upcoming Deadlines & Dates -------------------------- Non-client library freeze: February 28 Client library freeze: March 7 Stein-3 milestone: March 7 -- Sean McGinnis (smcginnis)

1 0

[all] Etcd as DLM
by Ben Nemec 17 Jan '19

17 Jan '19

Hi, I wanted to revisit this topic because it has come up in some downstream discussions around Cinder A/A HA and the last time we talked about it upstream was a year and a half ago[1]. There have certainly been changes since then so I think it's worth another look. For context, the conclusion of that session was: "Let's use etcd 3.x in the devstack CI, projects that are eventlet based an use the etcd v3 http experimental API and those that don't can use the etcd v3 gRPC API. Dims will submit a patch to tooz for the new driver with v3 http experimental API. Projects should feel free to use the DLM based on tooz+etcd3 from now on. Others projects can figure out other use cases for etcd3." The main question that has come up is whether this is still the best practice or if we should revisit the preferred drivers for etcd. Gorka has gotten the grpc-based driver working in a Cinder driver that needs etcd[2], so there's a question as to whether we still need the HTTP etcd-gateway or if everything should use grpc. I will admit I'm nervous about trying to juggle eventlet and grpc, but if it works then my only argument is general misgivings about doing anything clever that involves eventlet. :-) It looks like the HTTP API for etcd has moved out of experimental status[3] at this point, so that's no longer an issue. There was some vague concern from a downstream packaging perspective that the grpc library might use a funky build system, whereas the etcd3-gateway library only depends on existing OpenStack requirements. On the other hand, I don't know how much of a hassle it is to deploy and manage a grpc-gateway. I'm kind of hoping someone has already been down this road and can advise about what they found. Thanks. -Ben 1: https://etherpad.openstack.org/p/BOS-etcd-base-service 2: https://github.com/embercsi/ember-csi/blob/5bd4dffe9107bc906d14a45cd819d9a6… 3: https://github.com/grpc-ecosystem/grpc-gateway

11 20

[tripleo] OVB is now on Gerrit
by Ben Nemec 17 Jan '19

17 Jan '19

Just a heads up that the import of OVB to Gerrit is complete. If you're using OVB you should switch your clones from the Github repo to https://git.openstack.org/cgit/openstack/openstack-virtual-baremetal I've marked the Github repo deprecated so please don't submit issues or PRs there anymore. For the moment the approval process won't meaningfully change. I'll still be reviewing and single-approving patches, and the core reviewer list for OVB is the same as it was on Github, with the addition of Juan (as TripleO PTL) and Harald (as someone who has recently done a ton of good work in OVB). See the full list here: https://review.openstack.org/#/admin/groups/1993,members Once we have E2E testing set up on the repo (that isn't me manually testing changes against my local cloud) I expect we'll open that list up more and can discuss moving to a more typical 2 +2 model. Thanks. -Ben

2 2

[TripleO] Scaling TripleO for Edge Computing
by James Slagle 17 Jan '19

17 Jan '19

Within the TripleO Edge squad, we've been collecting ideas and looking at other current in progress work as it relates to scaling TripleO. The high level goal is brainstorm about how we can scale to manage deployments that are of a order of magnitude larger than we do today (thousands of nodes instead of hundreds). We've been collecting these ideas in this google doc: https://docs.google.com/document/d/12tPc4NC5fo8ytGuFZ4DSZXXyzes1x3U7oYz9nea… As always, any feedback or other ideas are welcome. It should be open to view/comment/edit without any account required. Or, feel free to reply on the ML. Thanks! -- -- James Slagle --

1 0

[neutron] [upgrade] No meeting on Jan. 17th
by Lujin Luo 16 Jan '19

16 Jan '19

Hi team, I will not be able to chair the meeting tomorrow. And since from the review list, we do not have many updates. Let's resume next week. Sorry for any inconvenience caused. Best regards, Lujin

1 0

[bifrost][ironic-inspector] how could i use bifrost to inspector the server
by 谭明宵 16 Jan '19

16 Jan '19

Hi all: I use the bifrost to deploy ironic standalone，but I don’t know how to use it for ironic-inspector，Thanks for your help

1 0

[nova][placement][tripleo] Extracted Placement enablement status update #1
by Lee Yarwood 16 Jan '19

16 Jan '19

Hello, This is a brief status progress report on my work to enable the deployment of the extracted Placement service within TripleO ahead of the extraction check-in call later today. tl;dr TripleO isn't ready to switch to an extracted Placement service or for code to be removed from openstack/nova. # RDO (packaging) https://review.rdoproject.org/#/q/topic:placement-add This was started at the PTG in Denver and mostly completed some time ago now. I do however have a single change outstanding that includes the puppet-placement package as a dependency of puppet-tripleo but aside from that this is complete: puppet-tripleo: Require puppet-placement https://review.rdoproject.org/r/18330 FWIW in the context of the extraction check-in call, both RDO and TripleO are not ready to deal with the original placement code being deleted from the openstack/nova project at this point. This will continue to be the case until the following work is completed to enable deployments using the extracted project in TripleO. # Kolla (containers) https://review.openstack.org/#/q/topic:split-placement+OR+topic:upgrade-pla… The initial Kolla change to produce a placement-api container landed some time ago after some small delays due to the Stein UCA not being used for the Ubuntu binary jobs: Split placement-api from nova https://review.openstack.org/#/c/613589/ FWIW an additional change to copy across the DB migration script has also been posted and is pending a package promotion in RDO: Copy placement database migration script https://review.openstack.org/#/c/626382/ The above change isn't required by TripleO, I just wanted to highlight that kolla-ansible are looking to use the script during upgrades. Unfortunately due various issues with TripleO promotions the TripleO container for the placement-api was only uploaded yesterday after I manually built it: https://hub.docker.com/r/tripleomaster/centos-binary-placement-api # Puppet https://review.openstack.org/#/q/topic:tripleo-placement-extraction The initial and massive puppet-placement cookiecutter change has landed: Initial cookiecutter run and import from puppet-nova https://review.openstack.org/#/c/604182/ This is currently only tested on CentOS7 by the following POI or puppet-openstack-integration change that has itself been stuck behind a raft of Ubuntu py3 and Stein UCA issues: placement: Extract the service from Nova https://review.openstack.org/#/c/615568/ I'm attempting to unblock this by working my way through the following changes to support py3 and the Stein UCA within the Ubuntu jobs: https://review.openstack.org/#/q/status:open+topic:ubuntu-py3 https://review.openstack.org/#/q/status:open+topic:inherit_pyvers Help with these changes from any openstack-puppet Ubuntu users would obviously be appreciated here! Finally I'm currently working on the following puppet-tripleo change that makes this all usable within TripleO itself: WIP placement: Initial extraction of the Placement service from Nova https://review.openstack.org/#/c/624335/ # TripleO https://review.openstack.org/#/q/topic:tripleo-placement-extraction On the TripleO front I almost have undercloud deployment completing in a reproducer environment with various local hacks to workaround changes not being merged yet. The main tripleo-heat-template change can be found below: WIP placement: Extract the service from Nova https://review.openstack.org/#/c/630644/ # TODO Obviously there's still a lot to do here but to begin with I'll be focusing on the following tasks: - Landing the puppet-openstack-integration and puppet-tripleo changes. - Moving the tripleo-heat-templates change out of WIP. - Posting draft upgrade_tasks in a new change using the db migration script. Hopefully this is of some use to folks in the Placement and TripleO teams! Cheers, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

3 2

[nova][glance] Granting image member access for snapshots (bug 1675791)
by Matt Riedemann 16 Jan '19

16 Jan '19

I have a fix proposed for a pretty old bug (1675791 [1]). This originally came up because of a scenario where an admin shelves a server and then the owner of the shelved server cannot unshelve it since they do not have access to the shelve snapshot image. The same is true for normal snapshot and backup operations though, see this proposed spec for Stein [2]. It also came up during the cross-cell resize spec review [3] since that solution depends on snapshot to get the root disk from one cell to another. In a nutshell, when creating a snapshot now, the compute API will check if the project creating the snapshot is the same as the project owner of the server. If not, the image is created with visibility=shared and the project owner of the instance is granted member access to the image, which allows them to GET the image directly via the ID, but not list it by default (the tenant user has to accept the pending membership for that). I have tested this out in devstack today and everything seems to work well. I am posting this to (a) raise awareness of the bug and proposed fix since it is sort of a behavior change in the createImage/createBackup/shelve APIs and (b) to make sure the glance team is aware and acknowledges this is an OK thing to do, i.e. are there any kind of unforeseen side effects of automatically granting image membership like this (I would think not since the owner of the instance has access to the root disk of the server anyway - it is their data). Also note that some really crusty legacy code in most of the in-tree virt drivers had to be removed (some virt drivers would change the image visibility back to private during the actual data upload to glance) which could mean out of tree drivers have the same issue. [1] https://bugs.launchpad.net/nova/+bug/1675791 [2] https://review.openstack.org/#/c/616843/ [3] https://review.openstack.org/#/c/616037/3/specs/stein/approved/cross-cell-r… -- Thanks, Matt

4 6