Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-13
21:40:19 openstackgerrit Matt Riedemann proposed openstack/nova: os-vif: convert libvirt driver to use os-vif for fast path vhostuser https://review.openstack.org/385061
21:40:20 openstackgerrit Matt Riedemann proposed openstack/nova: os-vif-util: set vif_name for vhostuser ovs os-vif port https://review.openstack.org/410737
21:51:22 dtp anyone need anything re cells v2?
21:51:40 mriedem dtp: for right now i don't think so
21:51:53 dtp ok
22:22:04 melwitt mriedem: trying to make sure I have this right in my head ... is the expectation during an upgrade to ocata that the appropriate cells v2 setup commands be run using the ocata code, before running the db sync? or is the expectation to run the setup using the newton code before starting the upgrade
22:24:25 mriedem melwitt: in grenade we run simple_cell_setup in newton before going to ocata: https://review.openstack.org/#/c/393441/2/projects/60_nova/from-newton/upgrade-nova
22:24:28 openstackgerrit Davanum Srinivas (dims) proposed openstack/nova: [WIP] Ignore me - ry py35 functional with a clean slate https://review.openstack.org/419968
22:24:42 mriedem but simple_cell_setup is meant to be idempotent so you can run it as many times as needed
22:25:04 mriedem but you're asking because we don't have create_cell in newton
22:25:08 melwitt okay. I was wondering if it's also fine to run them in ocata, just before the db sync
22:25:11 melwitt yes, pretty much
22:25:34 mriedem well, for the nova_api db sync to work, you have to have created the cell mappings and cell0
22:25:49 mriedem so (1) simple_cell_setup, (2) api-db sync
22:25:50 melwitt and also the simple_cell_setup has an enhancement in ocata to take the transport url from the conf, which is pretty important. I think it can be backported (I checked oslo.messaging stuff)
22:25:55 mriedem because (2) has the blocking schema migration
22:25:57 melwitt but I was thinking, do we need to backport all this stuff or no
22:26:10 melwitt right
22:26:20 mriedem melwitt: i remember you asking about backporting that one, i think if it was ok w/ the oslo.messaging version in newton i think we can backport it
22:26:23 mriedem if you haven't already done so
22:26:34 openstackgerrit Dan Smith proposed openstack/nova: Add some cellsv2 setup docs https://review.openstack.org/420198
22:26:42 mriedem well look who it is
22:26:44 dansmith mriedem: melwitt ^
22:26:46 melwitt yeah, I was just wondering if it's necessary. maybe not necessary but it would be nice to have the option to run them in newton?
22:27:33 dansmith after writing that, I almost think maybe we should do away with the simple command, or at least not stress its usage
22:27:40 dansmith once we have the create command
22:27:55 dansmith I think it's more straightforward to think about "create cell, discovery hosts"
22:28:18 dansmith once we merge the create command I will change devstack to do the same thing for cellsv1 and normal, removing the simple usage
22:29:04 melwitt yeah, not surprisingly the highly niched batch command ends up being more confusing than it's worth
22:29:53 dansmith well, it was supposed to make it easy for people, but...
22:29:58 mriedem dansmith: yeah i did mention something to that effect in the ML, i.e. doing different things for upgrade scripts (grenade) and fresh install scripts (devstack)
22:30:04 melwitt dansmith: I dunno if you saw my earlier question but, I was asking is it equally okay to run cells v2 setup stuff after you've gotten ocata code, just make sure you do it before any db sync?
22:30:04 mriedem but it depends on where we end up probably
22:30:13 openstackgerrit Scott DAngelo proposed openstack/nova: WIP Do Not Merge https://review.openstack.org/420201
22:30:14 melwitt or do we need to backport all these command changes to newton
22:30:33 mriedem if create_cell is going to be required for upgrade, then we're going to have to backport it to newton and change grenade
22:30:39 dansmith yeah
22:30:50 dansmith although the simple command will still work for people upgrading,
22:30:52 mriedem right
22:30:52 melwitt okay
22:31:04 mriedem i like simple_cell_setup in grenade, but not devstack
22:31:08 dansmith so maybe we just backport changes to it to make it work, and bill it as the "get you to ocata command" and then do away with it later
22:31:12 dansmith yeah
22:31:19 mriedem sure
22:31:37 scottda mriedem: That patch fixes the problem with not having cinderv3 in Nova's catalog ^^^^
22:31:47 dansmith if one of you will skim that patch to see if there's anything majorly wrong with it, then I can send it to the ML on that thread for some wider view
22:32:28 mriedem omfg my eyes https://review.openstack.org/#/c/420201/1/nova/context.py
22:32:36 mriedem scottda: you could have thrown that in the other WIP couldn't you?
22:32:43 mriedem not sure how many DNM patches we are going to have here :)
22:33:14 melwitt dansmith: the main thing I noticed is I wouldn't want to imply the db and mq urls are required by putting them in the examples. operators really don't want to put secret creds on the command line
22:33:53 dansmith melwitt: it just seems clearer to me to do that
22:34:13 scottda mriedem: Yeah, I'm going to abandon the first...was too messy to keep and change all the logic.
22:34:16 mriedem you can make a note that it's for illustration but simple_cell_setup will read the transport url and database connection url from nova.conf
22:34:19 melwitt I've been noticing feedback about it and think it will make people think they have to put them on the command line
22:34:31 dansmith melwitt: because if you don't, then you don't see the magic that $db_cell0 is used, etc
22:34:53 dansmith melwitt: then it's just three commands you run, but you don't know what thing in the config file goes with what
22:34:55 melwitt okay. maybe we'll just note that it's not required in words in each section or something
22:35:15 melwitt because I think in real life, operators will not pass those things on the command line
22:35:16 dansmith melwitt: yeah, I can add something about that
22:35:30 melwitt it's more about what --config they pass to nova-manage
22:35:36 melwitt that will determine where it gets the values from
22:35:52 dansmith melwitt: the thing is, I think the current situation we have with doing everything from the config file is just really obscure
22:35:54 openstackgerrit Scott DAngelo proposed openstack/nova: WIP Do Not Merge https://review.openstack.org/420201
22:36:12 dansmith melwitt: when writing that, I started without the args, and had to go look up how we figure out what the values would be
22:36:23 melwitt dansmith: it is. so I'm cool with just notes that they don't have to do that and probably shouldn't in a real scenario
22:37:01 melwitt that it will pull the values from the nova.conf passed to nova-manage --config <nova.conf>
22:42:18 melwitt dansmith: overall looks reasonable to me
22:42:29 mriedem i don't consider those whitespaces as reasonable
22:43:20 melwitt that's true. shame on you dansmith
22:44:02 mriedem gdi where is jay when i need him
22:44:21 dansmith melwitt: I feel like operators that are sensitive about their creds are also not hand-typing them into a history-preserving bash shell, but.. regardless, I think the changes I just made will appease the concern
22:44:21 melwitt in the air, right? I thought he mentioned he was traveling today
22:44:57 mriedem i think i figured it out
22:45:19 melwitt dansmith: what do you mean? i.e. what is the case you're talking about where they type them somewhere but don't put them in the nova-manage command?
22:46:28 openstackgerrit Dan Smith proposed openstack/nova: Add some cellsv2 setup docs https://review.openstack.org/420198
22:47:47 dansmith melwitt: not sure I grok that.. I'm just saying I think being afraid of creds on on the command line is being overly sensitive, given the lack of security we enforce on the very same systems you'd be running these on
22:47:56 dansmith melwitt: see what you think about that ^
22:51:51 melwitt dansmith: oh. I think at my last company they wouldn't put db/mq creds on the command line at all. but I have also gotten feedback from mwhahaha about the same issue recently. so I think there's enough reason to be really clear about it so people understand what their options are
22:52:28 dansmith yeah, I totally get that people are worried about it, I just think it's silly :)
22:52:33 melwitt heh, okay
22:52:39 mwhahaha well it's information leakage
22:52:53 mwhahaha it's always been a bad idea and continues to be so
22:53:06 mwhahaha even though many newer apps have all their stuff via command line
22:53:34 dansmith it didn't used to be reasonable to use secure throw-away VMs as consoles for this kind of stuff
22:53:49 dansmith and since this should be stuff you run from an administrative console...
22:53:53 dansmith but regardless,
22:54:06 dansmith the visual correlation of which url goes with which thing is what I think is important for the examples
22:54:16 mriedem figleaf: can i not use env vars in a gabbit query string like this?
22:54:17 mwhahaha well it then ends up in scripts and other stuffs
22:54:17 mriedem PUT: /resource_providers/$ENVIRON['RP_UUID']/aggregates
22:54:22 dansmith much easier to map things in your head when you're trying to grok it
22:54:42 figleaf mriedem: yes, that's pretty much how you have to do it
22:55:11 mwhahaha anyway it's something we need to be conscious of especially if we want our apps to be consumed in the finance and government space
22:55:23 mriedem ok i was missing "content-type"
22:55:25 mriedem oops
22:55:30 melwitt dansmith: cool, thanks. I see you kept the trailing whitespace though, mriedem wouldn't approve
22:55:37 mriedem i was missing the content-type: application/json request header
22:55:43 dansmith melwitt: I fixed a few
22:55:50 mwhahaha whether or not it's silly is moot in the eyes of regulations and audits
22:55:51 figleaf mriedem: I go through about 20 oops a day with gabbi

Earlier   Later