| clarkb | thinking about this more I think you are right and we want to see the config drive data | 00:02 |
|---|---|---|
| clarkb | because this must've worked before because we short circuited on the dhcp path | 00:02 |
| clarkb | but now we are gettnig something that isn't dhcp (and is unknown) and breaking glean | 00:02 |
| clarkb | its possible its just junk and we'll bring up our interface with dhcp on the next item in the list, but seems like maybe something in nova changed here? | 00:03 |
| SpamapS | woot.. running with OS_TEST_TIMEOUT=9999 produced useful things | 00:05 |
| SpamapS | Ran 211 (+27) tests in 743.023s (-9.924s) | 00:05 |
| SpamapS | FAILED (id=20, failures=9 (+5), skips=29) | 00:05 |
| * SpamapS EOD's for now | 00:06 | |
| clarkb | pabelanger: maybe https://review.openstack.org/#/c/430910/ | 00:06 |
| clarkb | when did the job start failing? ^ merged yesterday | 00:06 |
| pabelanger | clarkb: ya, yesterday | 00:06 |
| jeblair | clarkb, pabelanger: how can we get a copy of the configdrive data? | 00:10 |
| clarkb | jeblair: I'm working to boot a cirros host on this held instance and can dump it from there | 00:11 |
| jeblair | oh i see that in -infra now :) | 00:11 |
| clarkb | watch cirros not have the ability to mount th device once I get it up :/ | 00:13 |
| clarkb | {"services": [], "networks": [{"network_id": "7ee08c00-7323-4f18-94bb-67e081520e70", "link": "tap14b906ba-8c", "type": "ipv4_dhcp", "id": "network0"}, {"network_id": "7ee08c00-7323-4f18-94bb-67e081520e70", "link": "tap14b906ba-8c", "type": "ipv6_dhcp", "id": "network1"}], "links": [{"ethernet_mac_address": "fa:16:3e:9e:84:5c", "mtu": 1450, "type": "ovs", "id": "tap14b906ba-8c", "vif_id": | 00:18 |
| clarkb | "14b906ba-8c2c-4829-852e-2987d25ceabc"}]} | 00:18 |
| clarkb | the issue appears to be "ipv6_dhcp" | 00:18 |
| clarkb | glean doesn't handle that | 00:18 |
| pabelanger | is that new? | 00:19 |
| clarkb | also WHY ARE WE DHCPING IPV6. ok I fleel better after getting that out of my system | 00:19 |
| mordred | clarkb: well - at least we know what the problem is | 00:19 |
| clarkb | pabelanger: sort of, I think its been there but only if explicitly enabled, But now nova just defaults to it enabled | 00:19 |
| clarkb | so my patch to glean will work for now | 00:19 |
| mordred | I mean - sadly it means we're down the stack to a glean patch to fix it ... | 00:20 |
| mordred | oh - I missed that | 00:20 |
| clarkb | but only for ipv4 | 00:20 |
| clarkb | mordred: https://review.openstack.org/449366 | 00:20 |
| mordred | +A | 00:20 |
| clarkb | and I don't feel like untangling ipv6 dhcp tonight becuase well YOU SHOULDN"T DHCP | 00:20 |
| clarkb | there I got it out of my system more | 00:20 |
| pabelanger | well, ipv6 and glean is limited too. We don't even support centos yet | 00:21 |
| clarkb | I wonder if this means neutron's ipv6 default is dhcp not RAs now | 00:22 |
| openstackgerrit | Joshua Hesketh proposed openstack-infra/nodepool feature/zuulv3: Merge branch 'master' into feature/zuulv3 https://review.openstack.org/445325 | 00:22 |
| jlk | jesusaur: any chance you want to port over https://review.openstack.org/#/c/415750 or should I? | 00:22 |
| pabelanger | clarkb: cool, 449366 worked for fedora / centos | 00:33 |
| pabelanger | waiting for ubuntu | 00:33 |
| openstackgerrit | Joshua Hesketh proposed openstack-infra/nodepool feature/zuulv3: Fix test_leaked_node_not_deleted for v3 https://review.openstack.org/449375 | 00:47 |
| pabelanger | clarkb: mordred: cool, once we clean up line breaks, we can see the glean error: http://logs.openstack.org/30/358730/6/check/gate-dsvm-nodepool/eadd068/logs/screen-nodepool.txt.gz | 00:51 |
| pabelanger | will make debugging things easier | 00:52 |
| jesusaur | jlk: ya, I can take a stab at that if you want to take a break from the stack to work on something else | 00:53 |
| jlk | well I'm working on some that are after that, which are going to be big pains | 00:53 |
| jlk | all the status/review stuff | 00:53 |
| jesusaur | ah, ok | 00:54 |
| jesusaur | in that case, I'll take a look at porting 415750 tomorrow | 00:54 |
| pabelanger | mordred: left a comment on 358730 | 01:02 |
| *** jamielennox is now known as jamielennox|away | 01:39 | |
| openstackgerrit | Jesse Keating proposed openstack-infra/zuul feature/zuulv3: Add support for requiring github pr head status https://review.openstack.org/449390 | 01:47 |
| *** jamielennox|away is now known as jamielennox | 01:48 | |
| *** timrc has quit IRC | 02:38 | |
| *** timrc has joined #zuul | 02:49 | |
| *** bhavik1 has joined #zuul | 06:20 | |
| *** bhavik1 has quit IRC | 07:38 | |
| *** hashar has joined #zuul | 11:58 | |
| mordred | pabelanger: woot | 12:01 |
| openstackgerrit | Monty Taylor proposed openstack-infra/nodepool master: WIP Fetch server console log if ssh connection fails https://review.openstack.org/358730 | 12:03 |
| pabelanger | mordred: also left a question on^, maybe rethinking my original patch. I think we want console-log to be part of the provider section, since it deals with SSH thing, not the label. | 12:26 |
| pabelanger | yay | 13:10 |
| pabelanger | http://logs.openstack.org/30/358730/7/check/gate-dsvm-nodepool/841af13/logs/screen-nodepool.txt.gz#_2017-03-24_12_40_00_972 | 13:10 |
| Shrews | oh, so it's a glean bug? | 13:28 |
| mordred | Shrews: yup! | 13:30 |
| mordred | well - actually | 13:30 |
| mordred | we think it's an openstack bug | 13:30 |
| mordred | but ... it's also a glean bug | 13:30 |
| Shrews | bugs on bugs on bugs on bugs | 13:30 |
| mordred | pabelanger: yah - I think that makes sense too | 13:31 |
| *** hashar is now known as hasharAway | 14:29 | |
| jeblair | Shrews: https://review.openstack.org/449147 is true? i thought that was a misapprehension... | 15:22 |
| Shrews | jeblair: which part of that are you asking is true? | 15:23 |
| jeblair | Shrews: the "you must specify all azs in order to have nodes grouped" | 15:24 |
| Shrews | jeblair: yes, that is true. unless there is an existing node that it can select for the first node. if it has to build a node, there is no guarantee | 15:25 |
| Shrews | because you don't know what zone will be selected for a new node | 15:25 |
| jeblair | Shrews: and we may try to launch them all at the same time... right? | 15:26 |
| Shrews | well, no. the launch is started as soon as we determine we need a new node | 15:27 |
| jeblair | Shrews: right, but we don't wait for it to get far enough to find out what az it landed in before we start the launch for the next one | 15:28 |
| Shrews | right | 15:28 |
| jeblair | (by design because we'd never get anything done :) | 15:28 |
| Shrews | i'm open to better wording there | 15:28 |
| jeblair | Shrews: no, the wording is good, i just object to the meaning :) | 15:28 |
| jeblair | Shrews: is there a way to get the list of az's? from shade or occ maybe? | 15:29 |
| Shrews | not sure, off hand | 15:29 |
| jeblair | mordred, clarkb: ^ ? | 15:30 |
| mordred | jeblair: I do not believe so | 15:30 |
| mordred | jeblair: BUT - we could certainly make one | 15:30 |
| mordred | maybe | 15:30 |
| mordred | let me do some poking | 15:30 |
| mordred | (at the moment I am unaware of any clouds we have access to that have more than one az, so testing az things is admittedly more difficult | 15:31 |
| jeblair | if so, we can turn this into "leave blank to have nodepool select an AZ from the full set; list az's to restrict nodepool to a subset". which is, i think what a user would expect. | 15:32 |
| SpamapS | Console log also usually has SSH host keys btw. Might be good to fetch that before even sshing when we start caring about things like CD or build attestation | 15:32 |
| * SpamapS hasn't had coffee so.. grains of salt | 15:32 | |
| mordred | jeblair: ooh - neat. there is a list-azs call we can make | 15:33 |
| mordred | SpamapS: well | 15:33 |
| mordred | SpamapS: that's only true if the host runs cloud-init, which our hosts do not | 15:33 |
| mordred | SpamapS: and also rackspace does not support fetching console-log (you always get empty string) | 15:33 |
| SpamapS | Yeah let's not do attestation there. | 15:34 |
| mordred | SpamapS: this is, actually, the reason we keep requesting an API call to be added to nova that would fetch the host key over the network that exists in the cloud | 15:34 |
| mordred | SpamapS: but for whatever reason have been unable to get any traction on it being a super important thing to have | 15:34 |
| SpamapS | mordred: I think that's called DNS sec for designate? ;-) | 15:35 |
| mordred | SpamapS: well - that would be a way - but honestly having a nova api call that gets neutron to ping port 22 and return the host key should be fairly trivial to implement | 15:35 |
| mordred | but my attempts to write it up always run in to me describing a poor sample implementation | 15:36 |
| mordred | SpamapS: https://review.openstack.org/#/c/167202/ - it's been a couple of years since I tried | 15:37 |
| SpamapS | It would. Break the TOFU hegemony! | 15:37 |
| mordred | jeblair: I'll add a list_azs call to shade so that we can implement that | 15:38 |
| jeblair | mordred: cool, thanks! | 15:39 |
| mordred | in case anyone wants to see the payload it returns: | 15:39 |
| mordred | [Munch({u'zoneState': {u'available': True}, u'hosts': None, u'zoneName': u'ca-ymq-2'}), Munch({u'zoneState': {u'available': False}, u'hosts': None, u'zoneName': u'nova'})] | 15:39 |
| mordred | that's for vexxhost | 15:39 |
| mordred | there is one 'available' az and one that is not available | 15:39 |
| mordred | so I think that's pretty good | 15:39 |
| jeblair | ah cool | 15:39 |
| jeblair | i reckon we should only try the available ones. :) | 15:40 |
| mordred | c._compute_client.get('/os-availability-zone') is the call - so it's pretty nice and easy | 15:40 |
| mordred | jeblair: you're assuming that unavailable means unavailable | 15:41 |
| mordred | jeblair: it's possible we only want to try unavailable ones, since maybe "unavailable" means "can boot nodes" | 15:41 |
| mordred | sort of like how router:external does not mean "this network can route packets externally" | 15:41 |
| mordred | jeblair, Shrews: working on ipv6-preferred ... it seems like we grab "preferred_ip" and use it for the keyscan - but do not store it in the node we put in zk | 15:42 |
| mordred | am I just reading that wrong? | 15:42 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Remove SSH support from nodepool https://review.openstack.org/446683 | 15:46 |
| *** hasharAway is now known as hashar | 15:57 | |
| Shrews | mordred: not at a computer now, but I believe that is correct. | 16:06 |
| mordred | k. fixing | 16:06 |
| mordred | jeblair: also - nodepool does a keyscan as part of boot, and zuul also does one when it's making the inventory - should we just put the value of the nodepool keyscan into the zk node record? | 16:09 |
| SpamapS | I thought we already did that | 16:11 |
| jeblair | mordred: yes -- i believe we are in mid-transition on that (moving from zuul to nodepool). pabelanger has been working on that. | 16:11 |
| mordred | cool | 16:11 |
| mordred | I will not touch that right now then | 16:11 |
| pabelanger | yes! | 16:11 |
| pabelanger | mordred: https://review.openstack.org/#/c/446785/ | 16:11 |
| openstackgerrit | Monty Taylor proposed openstack-infra/nodepool feature/zuulv3: Remove ipv6-preferred and rely on interface_ip https://review.openstack.org/449705 | 16:18 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Consume interface_ip from nodepool node https://review.openstack.org/449706 | 16:18 |
| mordred | Shrews, jeblair: I'm getting a weird test failure on the nodepool change that I might need some advice on | 16:18 |
| jeblair | mordred: which test? | 16:19 |
| mordred | jeblair: a few - but for instance, nodepool.tests.test_commands.TestNodepoolCMD.test_alien_list_fail | 16:20 |
| mordred | jeblair: http://paste.openstack.org/show/604062/ | 16:20 |
| mordred | jeblair: I figured I'd push the patch up mid-flight while I look for the break | 16:21 |
| jeblair | mordred: oh, i apparently broke that in 449342 | 16:21 |
| mordred | neat! | 16:21 |
| mordred | PHEW | 16:21 |
| mordred | I could not see for the life of my how my change could have broken _that_ | 16:22 |
| mordred | jeblair: hrm. I have a philosophical question for you | 16:23 |
| jeblair | mordred: (fixing) | 16:24 |
| mordred | jeblair: the _Actual_ failure i'm producing now is that I need to add interface_ip to Dummy's _create | 16:24 |
| SpamapS | so.. this is interesting | 16:24 |
| mordred | but then in the test we have for this, I'll need to basically just implement logic in the dummy to set interface ip to the values we test for in the unit test | 16:24 |
| mordred | jeblair: which will lead us to test that our unit test matches the fake | 16:25 |
| SpamapS | The Ref/Change/etc. change I'm making produced 9 tests that it says failed | 16:25 |
| SpamapS | but none of those 9 fail when run alone | 16:25 |
| * SpamapS trys testr run --analyze-isolation | 16:25 | |
| mordred | SpamapS: I just had that in a shade change - it was something assigning to global | 16:25 |
| SpamapS | mordred: sounds about right | 16:26 |
| jeblair | mordred: yes -- however, since we're not writing a unit test of the provider manager per se, but rather, nodepool, we are able to test that nodepool functions. | 16:26 |
| mordred | jeblair: totally - it's just - the logic as to whether interface_ip contains the v6 or the v4 value is contained in shade - so I _think_ the specific v6 test might need to get stripped down a smidge | 16:27 |
| jeblair | mordred: oh, lemme look at that test | 16:27 |
| pabelanger | So, zuul question. If a job is in gate, and some body then does a -2, why doesn't zuul kick the patchset of the pipeline right away? | 16:28 |
| *** hashar has quit IRC | 16:29 | |
| jeblair | mordred: i agree, on the face, that's not very useful. | 16:30 |
| mordred | jeblair: I think I just want to make it test that if there is a v6 network specified that the v6 address is in interface_ip (and that there is a v6 address in public_v6) and if not v6 is blank, v4 and interface are the same | 16:30 |
| jeblair | pabelanger: bug | 16:30 |
| pabelanger | k | 16:30 |
| mordred | I'm still not 100% convince that's testing anything - other than exercising that we set interface_ip on the node | 16:30 |
| jeblair | mordred: yeah, the worth of this probably depends on how much other ipv6-interested code there is in nodepool. | 16:31 |
| openstackgerrit | James E. Blair proposed openstack-infra/nodepool feature/zuulv3: Remove api-timeout and provider.image-type https://review.openstack.org/449342 | 16:32 |
| openstackgerrit | James E. Blair proposed openstack-infra/nodepool feature/zuulv3: Remove deprecated networks syntax https://review.openstack.org/449354 | 16:32 |
| jeblair | mordred: ^ updated things for you to rebase on when ready | 16:32 |
| mordred | jeblair: woot! | 16:32 |
| pabelanger | follow up question, we currently have zuul enqueue for the client, is there a specific reason we don't have zuul dequeue? | 16:32 |
| jeblair | pabelanger: https://review.openstack.org/95035 | 16:33 |
| pabelanger | jeblair: Oh, nice | 16:33 |
| jeblair | we should fix that up and merge it on its 3 year anniversary. :) | 16:34 |
| pabelanger | SpamapS: ^ want to do that :) | 16:34 |
| pabelanger | I mean, I don't mined | 16:34 |
| pabelanger | mind* | 16:34 |
| mordred | wow | 16:34 |
| mordred | a 5-digit change | 16:35 |
| pabelanger | I could actually use that today, to clean up tripleo change queue | 16:35 |
| pabelanger | they are at 20hrs | 16:35 |
| mordred | committer: jeblair@hp.com | 16:36 |
| jeblair | the cool thing? it *does not need a rebase* | 16:36 |
| mordred | love it | 16:36 |
| mordred | jeblair: that's amazing | 16:36 |
| pabelanger | yar | 16:36 |
| mordred | yah- whoever fixes it - don't rebase it | 16:36 |
| pabelanger | going to take a stab at it | 16:36 |
| mordred | it'll be cool to have that merge in that state | 16:36 |
| pabelanger | mordred: so, git-review will safely do things right | 16:37 |
| pabelanger | not rebase it | 16:37 |
| mordred | yes. we removed rebase-by-default a while ago | 16:37 |
| pabelanger | cool | 16:37 |
| mordred | oh. wait | 16:37 |
| mordred | pabelanger: make sure you have rebase = false in the gitreview section of your global .gitconfig | 16:37 |
| pabelanger | k | 16:37 |
| mordred | [gitreview] | 16:37 |
| mordred | rebase = false | 16:37 |
| mordred | is in my ~/.gitconfig ... I honestly do not know if it's required, but it can't hurt :) | 16:38 |
| jeblair | i'm pretty sure it's not required | 16:38 |
| mordred | cool | 16:38 |
| * mordred wonders if he's the only human using usepushurl for git-review | 16:38 | |
| jeblair | i don't have a [gitreview] section | 16:38 |
| SpamapS | please do take that change over | 16:39 |
| SpamapS | I got in over my head pretty quickly. | 16:39 |
| mordred | with usepushurl, my origin remote for nodepool looks like this: | 16:40 |
| mordred | [remote "origin"] | 16:40 |
| mordred | url = https://git.openstack.org/openstack-infra/nodepool | 16:40 |
| mordred | fetch = +refs/heads/*:refs/remotes/origin/* | 16:40 |
| mordred | pushurl = ssh://mordred@review.openstack.org:29418/openstack-infra/nodepool.git | 16:40 |
| mordred | because I'm weird like that | 16:40 |
| mordred | jeblair: I'm now getting this: | 16:41 |
| mordred | AttributeError: 'Provider' object has no attribute 'max_servers' | 16:41 |
| mordred | but only in my test :) | 16:41 |
| pabelanger | Hmm, tests don't appear to work for me on that patch | 16:45 |
| pabelanger | let me see why | 16:45 |
| jeblair | mordred: that sounds like something missed from my change; max_servers moved to pool | 16:46 |
| jeblair | mordred: paste full tb? | 16:46 |
| mordred | http://paste.openstack.org/show/604066/ | 16:46 |
| jeblair | mordred: oh, maybe it's something that you ported over from the old ipv6 chang | 16:46 |
| jeblair | mordred: nope. apparently you are testing statsd but zuul is not. | 16:47 |
| mordred | oh - neat? | 16:47 |
| jeblair | yes, that's the right word for that. | 16:47 |
| mordred | well - maybe my venv is just old | 16:47 |
| pabelanger | there we go, working now | 16:48 |
| jeblair | i'll work on adding a statsd test | 16:48 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: Refactor out Changeish https://review.openstack.org/448913 | 16:49 |
| mordred | ooh. that'll be fun | 16:49 |
| mordred | pabelanger, clarkb, jeblair: btw - the response on clarkb's mail ot themailing list about the ipv6_dhcp value is fascinating | 16:51 |
| mordred | "Config drive claims ipv6_dhcp, neutron api says slaac" if you wanna go read | 16:51 |
| mordred | the fun line is "type ipvX_dhcp" really means "Neutron will | 16:51 |
| mordred | manage ipvX addresses", not necessarily that it will use the DHCP | 16:51 |
| mordred | protocol. | 16:51 |
| mordred | so - along with "router:external" does not mean "routes packets externally" we now have "dhcp does mean uses dhcp" | 16:52 |
| mordred | does not | 16:52 |
| jeblair | mordred: please address all followup responses to the wall! | 16:54 |
| jeblair | mordred: it looks like that statsd exception may be non-fatal, yeah? so not blocking your progress? | 16:57 |
| mordred | that's possible | 16:59 |
| SpamapS | mordred: our APIs are quite Orwellian. | 17:00 |
| SpamapS | Orwell played? | 17:00 |
| clarkb | mordred: fascinating is not the term I would use | 17:03 |
| openstackgerrit | Monty Taylor proposed openstack-infra/nodepool feature/zuulv3: Remove ipv6-preferred and rely on interface_ip https://review.openstack.org/449705 | 17:04 |
| mordred | jeblair: woot. works now | 17:04 |
| mordred | jeblair: you were right, the statsd was not blocking me | 17:04 |
| jeblair | oh interesting: nodepool.launch.requestor.NodePool:min-ready.ready:133.000000|ms | 17:05 |
| jeblair | that has 2 colons; i'm not sure if that's okay with statsd | 17:06 |
| jeblair | the "spec" does not say | 17:06 |
| * jeblair reads javascript | 17:07 | |
| jeblair | nope | 17:11 |
| jeblair | we must not have a : in the key | 17:12 |
| jeblair | https://github.com/etsy/statsd/blob/master/stats.js#L234 | 17:12 |
| clarkb | I'm responding to the glean metadata thing now | 17:12 |
| openstackgerrit | James E. Blair proposed openstack-infra/nodepool feature/zuulv3: Exercise statsd in tests and fix https://review.openstack.org/449737 | 17:18 |
| jeblair | mordred: ^ | 17:18 |
| mordred | woot | 17:18 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul master: Add a dequeue command to zuul client https://review.openstack.org/95035 | 17:32 |
| pabelanger | okay | 17:32 |
| pabelanger | jeblair: ^I hope that is what you were suggesting in your comment. | 17:33 |
| pabelanger | I also not 100% on the _doDequeueEvent() logic. | 17:33 |
| pabelanger | And jenkins +1 | 17:42 |
| pabelanger | yay | 17:42 |
| pabelanger | no rebase either | 17:42 |
| clarkb | mordred: I have added the enable_dhcp thing to my api grump etherpad | 17:47 |
| mordred | clarkb: yay! | 17:47 |
| Shrews | i have to admit, i'm having a difficult time groking the nodepool config file change stuff | 18:26 |
| jeblair | Shrews: yeah, it's another of those changes where, now that i've written it, i could probably re-write it to make sense as a series. but had no idea how to start that way. | 18:34 |
| jeblair | Shrews: probably the key thing is: i mostly just made providerworkers poolworkers, so we're going to have 1 worker thread per pool instead on one per-provider. but all the poolworkers for a provider still use the same provider manager, so requests are serialized/rate-limited through the task manager appropriately. | 18:35 |
| jeblair | Shrews: let me know if i can shed light on anything | 18:37 |
| Shrews | jeblair: the new relationship between pool-label and the outer label... why even have the outer 'label' anymore? Can't we just specify the min-ready within the pool? | 18:38 |
| Shrews | oh, i guess different providers can refer to the same label... but now each can have different specs... so i'm even more confused | 18:40 |
| jeblair | Shrews: yes, min-ready is more or less why there's a top-level label. | 18:42 |
| Shrews | So, if 'trusty' on provider A has 2G ram, and 'trusty' on provider B has 4G ram, it doesn't matter which one we choose for min-ready. | 18:42 |
| Shrews | which is weird, but... ok | 18:42 |
| jeblair | Shrews: and we've always been able to have different specs for a label in different providers (fundamentally, every provider is different, so that happens even if, say, you specify them the same way). previously, that configuration was on the *image* uploaded to the provider, which doesn't make much sense as it's not an attribute of the image, it's an attribute of the node we boot from the image. | 18:43 |
| clarkb | which got clunky when you wanted to use the same image booted in different ways | 18:44 |
| mordred | also - on HP Public we booted 30G instances because we had to to keep up with the 8G instances on RAX | 18:44 |
| Shrews | ok. i understand that part now | 18:44 |
| jeblair | Shrews: yes, so as an operator, if you feel that 4G on B is "equivalent" to 2G on A for your purposes, yes, you can do that. We probably won't. But keep in mind thet ram is really just a proxy for flavor selection, and no 2 flavors are equivalent anyway. this would probably be more obvious if, instead of specifying flavor by ram, we specified it by actual flavor name. which, perhaps, is something we should consider doing. :) | 18:45 |
| jeblair | sorry, i had typed all of that and didn't want it to go to waste. :) | 18:45 |
| Shrews | jeblair: yeah, k. found a couple of issues with the doc part of that change | 18:46 |
| jeblair | to clarkb's point -- yeah, this gets us halfway to being able to have have 2G xenial images *and* 8G xenial images. (the other half is replacing max-servers with a real understanding of quotas). | 18:46 |
| mordred | jeblair: actually - yah - maybe we should consider making flavor selectable by ram or by name | 18:46 |
| mordred | jeblair: I can make a change to do that if you like | 18:46 |
| jeblair | mordred: cool. we do have 'name filter' which is halfway there, but still also requires ram. should we even keep ram as on option? | 18:47 |
| mordred | jeblair: well - I kind of like our use of ram as a first-class citizen, because sometimes it expresses the thing you want to express in the config better than "please give me a supersonic" | 18:48 |
| mordred | but otoh - you might just know you want a supersonic and be done with it | 18:48 |
| mordred | (that's a flavor name from dreamhost, fwiw) | 18:48 |
| jeblair | mordred: yeah. oh. i see. my mental model of the real world was... inaccurate. I was imagining "Medium (8G)" or something. boy was i wrong. | 18:49 |
| clarkb | also ram happens to be our most important resource currently | 18:49 |
| mordred | jeblair: it's that thing where you imagine a world intended to make sense | 18:49 |
| jeblair | EOPENSTACK | 18:49 |
| clarkb | its the thing jobs constantly push against so it makes sense as a proxy | 18:50 |
| mordred | fwiw - shade supports jmespath expressions in the name_or_id field for this - so we could just document that and a user could use those to request a flavor by any attribute a flavor has if they wanted to | 18:50 |
| mordred | (I mean, if we expose flavor_name as a possibility, then we get that for free) | 18:50 |
| jeblair | mordred: hrm, we may want to keep this compatible with non-shade though? | 18:52 |
| mordred | good call | 18:52 |
| jeblair | mordred: for future linch-pin/aws/etc | 18:52 |
| mordred | and honestly, for flavor, putting in a name seems like a fine thing | 18:53 |
| clarkb | the really tricky thing though is this ins't a single dimension you have to operate in | 18:53 |
| mordred | then aws people can say "m1.tiny" | 18:53 |
| mordred | and dreamhost people can say "supersonic" | 18:53 |
| clarkb | disk, cpu, ram, ip addresses, ports, etc are all in play and you have to manage that matrix | 18:53 |
| mordred | and we can still say 8G for our vexxhost nodes | 18:53 |
| clarkb | oh and the total instances quota | 18:53 |
| mordred | clarkb: yah - that's why I think name is likely the most common choice for most users | 18:53 |
| clarkb | ya its mostly a "problem" when you start to mix and match within a provider | 18:54 |
| mordred | yup | 18:54 |
| jeblair | clarkb, mordred: yeah, so this may just be a matter of lifting the requirement for min-ram. most of the rest may already be in place. | 18:54 |
| clarkb | for example due to how quotas are set up today we don't get more isntances if we mixed in 2GB instances for pep8 jobs | 18:54 |
| mordred | but if the user says "supersonic" - I belive we as the api consumer can say "how many ram/cpu/disks does that have, and also hey cloud, what's my quota for each of those" | 18:55 |
| mordred | or "hey config, how many rams, disks and cpus has my user told me I can use" | 18:55 |
| clarkb | mordred: yup and find the total max you can do for that | 18:55 |
| mordred | yup | 18:55 |
| jeblair | well, quota needs to be a bit more sophisticated than that, because we'll be mixing | 18:55 |
| clarkb | jeblair: will we though? it provides zero benefit with how quotas currently work | 18:56 |
| mordred | jeblair: yha - but we'll have the bulding blocks to do the real calculations | 18:56 |
| Shrews | jeblair: why per-pool AZs? | 18:56 |
| jeblair | Shrews: pools are mostly "arbitrary grouping of cloud resources", so it seems not unreasonable that someone might say "we should only use this flavor on this AZ". | 18:57 |
| jeblair | Shrews: i can't recall if that happened or not; i'd have to look back at our hpcloud config. | 18:58 |
| jeblair | mordred: ya | 18:58 |
| mordred | I think hpcloud _talked_ about doing that for us | 18:58 |
| mordred | but never did | 18:58 |
| clarkb | we did have networks per az though iirc | 18:58 |
| clarkb | which ended up effectively pooling resources across AZs | 18:58 |
| jeblair | clarkb: i mean that if we have 2G and an 8G labels, no instance quota, but a ram quota, then for nodepool to determine whether a new node would go over quota, it needs to add up all the RAM it's allocated and make sure it's under the max ram. | 18:59 |
| Shrews | jeblair: do we want to try to group nodes for a request by az AND pool now? | 18:59 |
| jeblair | clarkb: yeah, that i remembered, so i put networks in pools. | 18:59 |
| Shrews | or is az enough, independent of pool? | 18:59 |
| jeblair | Shrews: yes, and that was my intent. i think that making providerworker into poolworker has accomplished that, unless i missed something. | 19:00 |
| jeblair | Shrews: yes == az+pool | 19:00 |
| Shrews | jeblair: you don't check pool for pre-existing, which prompted my question | 19:00 |
| jeblair | Shrews: ah, then i did miss something. :) | 19:01 |
| Shrews | jeblair: making a note for you... | 19:01 |
| jeblair | Shrews: thx. | 19:01 |
| openstackgerrit | Monty Taylor proposed openstack-infra/nodepool feature/zuulv3: Remove mention of non-clouds.yaml from docs https://review.openstack.org/449781 | 19:03 |
| openstackgerrit | Monty Taylor proposed openstack-infra/nodepool feature/zuulv3: WIP Add ability to select flavor by name or id https://review.openstack.org/449784 | 19:24 |
| mordred | jeblair: rough draft ^^ unfinished - but pushed it up to see what we think | 19:24 |
| Shrews | jeblair: oops, ignore my comment about launcher_id. You account for that in the thread name | 19:24 |
| mordred | jeblair: also, best I could see there is no way in voluptuous to say "one and only one of these two keys must be there" | 19:25 |
| openstackgerrit | K Jonathan Harker proposed openstack-infra/zuul feature/zuulv3: Add github reporter status_url config option https://review.openstack.org/449794 | 19:38 |
| jesusaur | jlk: ^ here's a port of the status_url change | 19:38 |
| jeblair | mordred: here's *a* way to do it; not sure if it's best: http://paste.openstack.org/show/604099/ | 19:41 |
| mordred | jeblair: oh neat | 19:47 |
| mordred | jeblair: you're more voluptuous than I clearly | 19:48 |
| jeblair | mordred: s2 and s3 will need an 'extra' flag: http://paste.openstack.org/show/604100/ | 19:49 |
| jeblair | (so you don't have to list the whole schema again) | 19:49 |
| mordred | jeblair: so - does Exclusive('ram', 'flavor'): int, mean "there's a field, ram, it's an int, and it's mutually exclusive with flavor | 19:50 |
| jeblair | mordred: no, 'flavor' is the group which ties it to name | 19:51 |
| jeblair | mordred: so put ram and name in the same group to make them exclusive with each other; add more items to the 'flavor' group as needed. | 19:52 |
| mordred | jeblair: ah - ok | 19:52 |
| mordred | jeblair: that hurts my brain, but in a good way which tells me I learned something | 19:53 |
| mordred | not in a bad way like when I learned that dhcp doesn't necessarily mean dhcp | 19:53 |
| jeblair | it's like radio buttons in gui programming. does that help or hurt? | 19:53 |
| mordred | jeblair: well, now I'm seeing dancing elves in front of me - is that good or bad? | 19:55 |
| jeblair | it is very good | 19:56 |
| mordred | \o/ | 19:56 |
| mordred | I've succeeded for today! | 19:56 |
| openstackgerrit | Monty Taylor proposed openstack-infra/nodepool feature/zuulv3: Encode exclusivity into voluptuous https://review.openstack.org/449801 | 20:01 |
| mordred | jeblair: so something like that ^^? | 20:01 |
| *** hashar has joined #zuul | 20:03 | |
| *** hashar has quit IRC | 20:22 | |
| *** hashar has joined #zuul | 20:25 | |
| *** yolanda has quit IRC | 20:54 | |
| *** yolanda has joined #zuul | 20:56 | |
| *** yolanda has quit IRC | 21:04 | |
| *** yolanda has joined #zuul | 21:05 | |
| *** yolanda has quit IRC | 21:17 | |
| *** yolanda has joined #zuul | 21:19 | |
| *** yolanda has quit IRC | 21:26 | |
| *** yolanda has joined #zuul | 21:32 | |
| *** yolanda has quit IRC | 21:39 | |
| *** yolanda has joined #zuul | 21:39 | |
| *** pclinuxos-lxde has joined #zuul | 21:49 | |
| *** pclinuxos-lxde has quit IRC | 21:50 | |
| *** hashar has quit IRC | 22:03 | |
| openstackgerrit | K Jonathan Harker proposed openstack-infra/zuul feature/zuulv3: Add github reporter status_url config option https://review.openstack.org/449794 | 22:30 |
| *** yolanda has quit IRC | 23:17 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!