Thursday, 2020-04-23

*** mordred has quit IRC02:43
*** ricolin_ has joined #openstack-tc02:44
*** mordred has joined #openstack-tc02:46
*** tetsuro has joined #openstack-tc03:16
*** tetsuro has quit IRC03:16
*** tetsuro has joined #openstack-tc04:11
*** evrardjp has quit IRC04:35
*** evrardjp has joined #openstack-tc04:35
*** slaweq has joined #openstack-tc05:47
*** diablo_rojo has quit IRC06:53
*** belmoreira has joined #openstack-tc06:58
*** dklyle has quit IRC07:11
*** KeithMnemonic has quit IRC07:12
*** tosky has joined #openstack-tc07:24
*** e0ne has joined #openstack-tc07:25
*** e0ne has quit IRC07:25
*** rpittau|afk is now known as rpittau07:39
*** e0ne has joined #openstack-tc08:06
*** e0ne has quit IRC08:09
*** tkajinam has quit IRC09:03
*** tetsuro has quit IRC09:24
*** e0ne has joined #openstack-tc09:47
*** rpittau is now known as rpittau|bbl10:21
*** rpittau|bbl is now known as rpittau12:02
*** ijolliffe has joined #openstack-tc12:31
gmanno/13:13
njohnstono/13:44
*** tkajinam has joined #openstack-tc13:44
knikollao/13:49
mnaseri haven't had a lot of tc members chime in on this: https://review.opendev.org/#/c/720107/14:15
mnaserappreciate comments14:15
mnaserbummer is i'm trying to drive something that will deliver a *net positive* thing and it seems like we're all arguing the details of it14:16
mnaserand a lot of proposals on doing something _that's unusual_14:16
*** e0ne has quit IRC14:17
mnaseraka "just install kolla and generate a bunch of dockerfiles using jinja and then build your image, simple!"14:17
*** e0ne has joined #openstack-tc14:17
mnaserwhich to me is a failure in the user experience because once again, we're trying to NIH things (kolla should stay, its good at providing an integrated set of images across multiple sources and distros)14:18
*** tkajinam has quit IRC14:37
knikollamnaser: i'm planning to play around with kolla today since i haven't used it before. this way i can provide some feedback from a newbie perspective who just wants some containers up.14:39
mnaserknikolla: and remember the consideration that people might wanna do this in ci14:41
knikolla++ that is one of my main concerns.14:43
knikollai think it also ties really well with efforts to have some of the services be more advertised as standalone.14:46
mnaseralso i trhink there is a lot of emphasis on like14:47
mnaser2 services that are really need to touch with the core system14:47
mnasernova/neutron, the rest are all api services mostly14:47
mnaserwith nearly no binary dependencies or very little14:47
*** dklyle has joined #openstack-tc14:49
knikollathinking out loud: could we rephrase the goal to specifically target api services?14:50
knikollawould that reduce pushback?14:50
jungleboyjo/15:01
ttx o/15:01
mnaserknikolla: i could?  i mean, i just want to start pushing code15:04
mnaserits a bummer because i have to sit and stall out until everyone is happy (which really, i dont think i can ever reach)15:04
mnaserand in the time that patch has been up, there could have been a working dockerfile in every single repository.15:04
mnaserthe only _non api_ service i can think of that is a problem is nova-compute and neutron-*-agent15:05
mnaseror rather specifically the ml2 agents fo rneutron15:05
*** ricolin_ has quit IRC15:06
ricolino/15:07
njohnstonand if you package neutron with ML2/OVN then there are no ML2 agents, just the OVN processes15:07
jrollmnaser: you don't need an accepted goal to push code15:11
jroll:)15:11
mnaserjroll: you're not wrong about that i guess15:11
jrollthis is one downfall of the goals process IMO, folks seem to think that anything across more than three projects needs to be a goal15:11
mnaserjroll: the idea was to get consensus and use the goal as a framework15:11
jrollreally all a goal does is record that it's a good idea, or soft-force projects that don't like an idea to do a thing15:12
mnaserso when patches roll up to a repo there isn't a "wat?"15:12
jrollright15:12
jrollidk if the goal framework is the right place to get consensus15:12
jrollif only because it feels like a "you must do this" thing15:12
mnaserrigth15:13
mnaserwell in that case, i can totally start pushing image builds for all projects then15:13
knikolla++ good point15:14
jrollyeah, I think showing the code might help people get it, fwiw15:15
knikollathis will also bring back some feedback on a project level, once they see the review up.15:15
mnaseri might just end up doing that then15:15
gmanngoal process has this disadvantage even in past also where osc goal is not yet there or tempest plugin took 2-3 cycle to be accepted but for various other reasons.15:15
njohnstonyes, if you link to the goal proposal in the commit message you'll get a lot more eyes I would think15:16
evrardjpo/15:17
gmannalso we have not updated this goal on V cycle goal update ML. which can be done if get more eyes form community.15:17
knikollaon a related note, i'm planning on proposing a assert:supports-standalone tag, and potentially making a blessed Dockerfile part of the requirements.15:17
mnaserknikolla: that's a pretty good idea actually15:18
njohnston+115:20
knikollawe can then have zuul automatically build and publish the images for such projects15:23
knikollawhich should drive their adoption up, and hopefully reduce the stigma of being part of openstack15:24
knikollawant to run ironic? docker pull :)15:24
*** belmoreira has quit IRC15:31
mnaserknikolla: yes +++++15:34
mnaserplus we can get consumers like metal3 to use those images :)15:34
jungleboyjmnaser:  I added my two cents in there.  Looks like a case where we are letting perfect be the enemy of good.15:35
jungleboyjWould rather we make progress on something than be paralyzed by bike shedding.15:35
mnaserbtw, for the ptg15:39
mnasertc-members: https://etherpad.opendev.org/p/tc-victoria-ptg15:40
fungiwhen we started the goals process, the idea really was to take something that several (or many) projects are already doing and codify it as a recommended practice the others should also standardize on15:43
mnaserfungi: that's interesting15:44
fungiit wasn't meant to lead design discussions, it was meant to trail them15:44
fungiwith the idea that if several projects are already having success with it, then it probably works15:44
fungiwhere the process has often fallen down is when we've tried to add goals for things nobody is actually doing yet15:45
fungiwhich almost guarantees design-by-committee madness15:46
smcginnisI would say, the goals we've had that haven't been successful have been the ones that have not trailed the design. We've had too many that were being discussed and figured out while teams have been left confused about what they were expected to do.15:46
knikolla++ makes sense15:46
openstackgerritDouglas Mendizábal proposed openstack/governance master: Add ansible role for managing Luna SA HSM  https://review.opendev.org/72134815:49
*** diablo_rojo has joined #openstack-tc15:59
fungithe other thing it was intended for early on was achieving consensus when several teams had solved similar problems in slightly different ways, so they could then realign on a common implementation16:08
fungi(often as a start to pushing that as an implementation other teams should also consider adding)16:08
fungiso at least the problem space was known, fairly well-explored, and there were solutions with known characteristics to choose among16:09
fungithe thing we did have which was intended to lead design for new cross-project efforts was the cross-project specs process16:11
fungiand that was rather quickly abandoned as unworkable because it's hard for a general review body to evaluate designs for things there's not even a poc/prototype implementation of yet16:12
gmannpop-up team is good alternate of that to start good progress on some projects and then propose/re-propose the goal16:13
fungiso i definitely caution against trying to twist the cycle goals process into the old cross-project specs process16:13
gmannexample, RBAC stuff16:14
fungiyeah, if you're looking for an official "blessing" of some sort on a cross-project effort which still needs to be designed, i agree with gmann a pop-up team is a reasonable path to take16:14
evrardjpwell I think that in this case there was already an implemention merged, no?16:21
openstackgerritKristi Nikolla proposed openstack/governance master: [draft] Add assert:supports-standalone  https://review.opendev.org/72239916:32
knikollatook a first stab at drafting ^16:32
fungifor 720107?16:32
*** evrardjp has quit IRC16:35
*** evrardjp has joined #openstack-tc16:35
fungievrardjp: i think the only thing which might count as an existing implementation for 720107 is that zuul and opendev are following a similar build process and already have basic ci jobs, but the software involved is different, with different behaviors and a different overall design from openstack's services16:35
clarkbfungi: I would say its a lot more than basic ci jobs, but agree different context16:36
fungithe goal document has an example proposed change to build an image for one service16:36
fungibut it's hard to argue for it as a goal when the initial example isn't even merged and in use anywhere16:37
fungiclarkb: well, from openstack's perspective, there's a basic framework which they could share with zuul and opendev16:38
fungia lot of openstack-specific work would likely be needed on top of that16:38
clarkbfungi: I really hope not. The whole point of that framework is to avoid that16:39
fungifor example, the uwsgi layer discussion raging in #opendev today16:39
clarkbya uwsgi is an oddity to me, but its also just an additional image. Not a change to the frameowrk16:39
clarkbwhen I think change to framework I think what rally has done and it has completely broken then16:39
clarkb(so we really want to avoid changes to the framework)16:40
fungithe point of the framework is to be able to point a generic job at any arbitrary python project repository and have a fully functional service come out the other end?16:40
clarkbfungi: nope16:40
fungiin that case, there will likely be openstack-specific jobs, or even project-specific jobs, needed right?16:40
clarkbyou need to inherit from the job to feed it your build details and auth credentials16:40
clarkbbut not modify any playbooks16:41
clarkband it doesn't intend on producing a functional service out the other end16:41
clarkbthe artifact created is an installation of the software. Not a deployment16:41
clarkb(no configs etc)16:41
fungiwell, from skimming the comments on the goal document, it seems like the fact that it's not intended as a working deployment may be a point of confusion16:43
knikollamy understadning is that it can be turned into a working deployment if you add the config16:44
fungiso i guess the idea is that it's little more than a `pip install` of the project into a container image16:45
clarkbknikolla: yes end users would plug that into k8s or docker-compose or whatever and feed the installation their configs16:45
clarkbfungi: correct16:45
clarkbfrom a technical standpoint there are a few important implementation details. The first is using multistage builds to reduce the size of the produced containers. We don't drag along intermediate build deps and artifacts. The other is we don't intend on building images for every distro. We build on the official python images because we are deploying python software16:46
clarkbthose two things are major differences when compared to existing container tooling in openstack16:47
*** rpittau is now known as rpittau|afk16:49
*** belmoreira has joined #openstack-tc17:08
*** belmoreira has quit IRC17:16
*** e0ne has quit IRC17:47
*** e0ne has joined #openstack-tc17:48
*** slaweq has quit IRC17:50
*** stephenfin has quit IRC18:03
*** stephenfin has joined #openstack-tc18:04
clarkbmnaser: I've noticed the quoting on some of the threads in 720107 is off. Is that a gerrit bug? I think you are expected to do > stuff\n\nmy response\n\n>other stuff18:16
clarkbI think a single newline might not create separation of context18:17
clarkb(if its doing that with multiple newlines it would be a gerrit bug)18:17
*** stephenfin has quit IRC18:19
*** stephenfin has joined #openstack-tc18:19
mnaserclarkb: summarized things pretty well and fungi indeed, i may have not been clear in that and i think i aimed to push more an idea of making docker images something similar to us publishing to pypi18:38
mnaseryou still have to bring your own configs and orchestration18:38
fungiyeah, maybe a lot of the concern being voiced there is over the assumption that it's yet another full distribution (or that people might mistake it for one)18:40
*** KeithMnemonic has joined #openstack-tc18:46
*** e0ne has quit IRC20:22
*** slaweq has joined #openstack-tc20:33
*** slaweq has quit IRC22:14
*** slaweq has joined #openstack-tc22:15
*** slaweq has quit IRC22:20
*** tosky has quit IRC22:58
*** tkajinam has joined #openstack-tc22:58
clarkbok tried to summarize what I said above as a comment on the change23:32

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!