bodhi2 plans

[Kevin Fenzi]

Greetings. 

So, in the releng meeting last week we discussed about landing bodhi2
before the alpha freeze started, however there were just too many
things still up in the air to do that, so we held off. 

However, I'd like to propose a concrete date to enable it and try and
make sure we have everything we need lined up for making that work. :) 

My understanding of the current status: 
(Luke: please correct me if anything is wrong or unclear here)

* We have bodhi2 web frontend up and running fine in staging: 
https://admin.stg.fedoraproject.org/updates/
(well, right now it's down as Luke is working on a update id bug there
and is repopulating the db, but it was and will be up again soon). 

* We have a bodhi2 backend up in staging and it's successfully mashed
  updates pushes. 

* bodhi2 isn't yet packaged in Fedora (it and it's deps are in a copr): 
http://copr.fedoraproject.org/coprs/lmacken/bodhi2/

So, to get that last bit we need: 

* API users. I thought we had a list somewhere, but I cannot seem to
  find it. At least fedora-easy-karma and fedora-gooey-karma use it.
  Are all of these using python-fedora for the api? Do we need to
  update that and bodhi-client? 

* We need bodhi2 in fedora/epel. Were we going to do it as a seperate
  package, or just an update to the existing 'bodhi' package. I assume
  maintainers would need the new client to do 'fedpkg update' ?

* Do we need any fedpkg changes? Or anything else? How do we want to
  handle the switchover?

* Is taskotron all ready to go with bodhi2? or more changes there?

* We will need an outage to switch over. I assume the bodhi1->bodhi2 db
  conversion shouldn't take too long? But once we convert and make live
  we are commmited. 

* Anything else I missed?

I'd like to propose we schedule the switchover/outage for 2015-08-19. 
(Provided alpha doesn't slip). This will allow us a few days to recover
from flock and get anything lined up we need to. 

Thoughts? additions? 

kevin

[Tim Flink]

On Mon, 3 Aug 2015 11:03:38 -0600
Kevin Fenzi <kevin(a)scrye.com&gt; wrote:

>  Greetings. 
>  
>  So, in the releng meeting last week we discussed about landing bodhi2
>  before the alpha freeze started, however there were just too many
>  things still up in the air to do that, so we held off. 
>  
>  However, I'd like to propose a concrete date to enable it and try and
>  make sure we have everything we need lined up for making that
>  work. :) 
>  
>  My understanding of the current status: 
>  (Luke: please correct me if anything is wrong or unclear here)
>  
>  * We have bodhi2 web frontend up and running fine in staging: 
>  https://admin.stg.fedoraproject.org/updates/
>  (well, right now it's down as Luke is working on a update id bug there
>  and is repopulating the db, but it was and will be up again soon). 
>  
>  * We have a bodhi2 backend up in staging and it's successfully mashed
>    updates pushes. 
>  
>  * bodhi2 isn't yet packaged in Fedora (it and it's deps are in a
>  copr): http://copr.fedoraproject.org/coprs/lmacken/bodhi2/ 
I didn't think that there had been much testing of the APIs yet. Last I
heard, the API wasn't ready for testing - has that changed?


>  So, to get that last bit we need: 
>  
>  * API users. I thought we had a list somewhere, but I cannot seem to
>    find it. At least fedora-easy-karma and fedora-gooey-karma use it.
>    Are all of these using python-fedora for the api? Do we need to
>    update that and bodhi-client?  
libtaskotron, resultsdb and blockerbugs use the Bodhi API through
python-fedora. None of them have been tested against bodhi2.


>  * We need bodhi2 in fedora/epel. Were we going to do it as a
> seperate
>    package, or just an update to the existing 'bodhi' package. I assume
>    maintainers would need the new client to do 'fedpkg update' ?
>  
>  * Do we need any fedpkg changes? Or anything else? How do we want to
>    handle the switchover?
>  
>  * Is taskotron all ready to go with bodhi2? or more changes there? 
Not really. Preparing for bodhi2 has been on the back burner for us
since it didn't sound like production was going to be ready before F23
was released.

I'll try to take a look into what's left but the guy who has been doing
most of that work is on PTO until Flock.


>  * We will need an outage to switch over. I assume the
> bodhi1->bodhi2
>  db conversion shouldn't take too long? But once we convert and make
>  live we are commmited. 
>  
>  * Anything else I missed?
>  
>  I'd like to propose we schedule the switchover/outage for 2015-08-19. 
>  (Provided alpha doesn't slip). This will allow us a few days to
>  recover from flock and get anything lined up we need to.  
How heavily has bodhi2 been tested by folks who aren't bodhi2
developers?  The idea of swapping out bodhi mid-release makes me a
little nervous since hiccups could affect the release process.

I realize there are ~3 weeks between the proposed date and F23 beta
freeze and that there are going to be bumps in the road no matter
when the switchover happens. However, the tester in me is thinking
more along the lines of what might go wrong in the near future if the
more corner-casey stuff (freeze etc.) is hit so soon after deployment,
especially if there's a bug that's taken down the frontend for at least
a couple hours in addition to needing a database wipe/repopulate 2
weeks before the proposed go-live date.

Tim

[Vít Ondruch]

Just a few remarks:

* I hoped that it will be possible to combine "type" of upgrade such as
"enhancement + security", but this is not possible it seem :/
* It would be nice if I can select which bug will be closed by this
update and which stays untouched. It happens that update fixes several
bugs, but one bug should be fixed in multiple branches, so I probably
don't want to close it unless I fix the other branch. Also, it would be
nice if Bodhi can identify bugs, which are included in several updates
and the last update pushed stable would close the associated issue.
* I really don't know what is the severity good for. There are probably
people, who always know precisely, but I find this useless.

 Anyway, the "null" updates looks strange to me ...


Vít



Dne 3.8.2015 v 19:03 Kevin Fenzi napsal(a):
>  Greetings. 
>
>  So, in the releng meeting last week we discussed about landing bodhi2
>  before the alpha freeze started, however there were just too many
>  things still up in the air to do that, so we held off. 
>
>  However, I'd like to propose a concrete date to enable it and try and
>  make sure we have everything we need lined up for making that work. :) 
>
>  My understanding of the current status: 
>  (Luke: please correct me if anything is wrong or unclear here)
>
>  * We have bodhi2 web frontend up and running fine in staging: 
>  https://admin.stg.fedoraproject.org/updates/
>  (well, right now it's down as Luke is working on a update id bug there
>  and is repopulating the db, but it was and will be up again soon). 
>
>  * We have a bodhi2 backend up in staging and it's successfully mashed
>    updates pushes. 
>
>  * bodhi2 isn't yet packaged in Fedora (it and it's deps are in a copr): 
>  http://copr.fedoraproject.org/coprs/lmacken/bodhi2/
>
>  So, to get that last bit we need: 
>
>  * API users. I thought we had a list somewhere, but I cannot seem to
>    find it. At least fedora-easy-karma and fedora-gooey-karma use it.
>    Are all of these using python-fedora for the api? Do we need to
>    update that and bodhi-client? 
>
>  * We need bodhi2 in fedora/epel. Were we going to do it as a seperate
>    package, or just an update to the existing 'bodhi' package. I assume
>    maintainers would need the new client to do 'fedpkg update' ?
>
>  * Do we need any fedpkg changes? Or anything else? How do we want to
>    handle the switchover?
>
>  * Is taskotron all ready to go with bodhi2? or more changes there?
>
>  * We will need an outage to switch over. I assume the bodhi1->bodhi2 db
>    conversion shouldn't take too long? But once we convert and make live
>    we are commmited. 
>
>  * Anything else I missed?
>
>  I'd like to propose we schedule the switchover/outage for 2015-08-19. 
>  (Provided alpha doesn't slip). This will allow us a few days to recover
>  from flock and get anything lined up we need to. 
>
>  Thoughts? additions? 
>
>  kevin
>
>
>  _______________________________________________
>  infrastructure mailing list
>  infrastructure(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/infrastructure

[Kevin Fenzi]

On Mon, 3 Aug 2015 16:17:18 -0600
Tim Flink <tflink(a)redhat.com&gt; wrote:

...snip...

>  > * bodhi2 isn't yet packaged in Fedora (it and it's deps
> are in a
>  > copr): http://copr.fedoraproject.org/coprs/lmacken/bodhi2/
>  
>  I didn't think that there had been much testing of the APIs yet. Last
>  I heard, the API wasn't ready for testing - has that changed? 
I think it is now, but hopefully Luke can answer. 

The api should be handled mostly in python-fedora, so not sure how
many direct api users would be affected. 

>  > So, to get that last bit we need: 
>  > 
>  > * API users. I thought we had a list somewhere, but I cannot seem to
>  >   find it. At least fedora-easy-karma and fedora-gooey-karma use it.
>  >   Are all of these using python-fedora for the api? Do we need to
>  >   update that and bodhi-client? 
>  
>  libtaskotron, resultsdb and blockerbugs use the Bodhi API through
>  python-fedora. None of them have been tested against bodhi2. 
Right. Luke is working on python-fedora now, hopefully soon we can test
them. 

>  > * We need bodhi2 in fedora/epel. Were we going to do it as a
>  > seperate package, or just an update to the existing 'bodhi'
>  > package. I assume maintainers would need the new client to do
>  > 'fedpkg update' ?
>  > 
>  > * Do we need any fedpkg changes? Or anything else? How do we want to
>  >   handle the switchover?
>  > 
>  > * Is taskotron all ready to go with bodhi2? or more changes there?
>  
>  Not really. Preparing for bodhi2 has been on the back burner for us
>  since it didn't sound like production was going to be ready before F23
>  was released.
>  
>  I'll try to take a look into what's left but the guy who has been
>  doing most of that work is on PTO until Flock. 
Hopefully there will be very little to nothing for it to need to do
(aside from using the new python-fedora). 

>  > * We will need an outage to switch over. I assume the
> bodhi1->bodhi2
>  > db conversion shouldn't take too long? But once we convert and make
>  > live we are commmited. 
>  > 
>  > * Anything else I missed?
>  > 
>  > I'd like to propose we schedule the switchover/outage for
>  > 2015-08-19. (Provided alpha doesn't slip). This will allow us a few
>  > days to recover from flock and get anything lined up we need to. 
>  
>  How heavily has bodhi2 been tested by folks who aren't bodhi2
>  developers?  The idea of swapping out bodhi mid-release makes me a
>  little nervous since hiccups could affect the release process. 
Well, it could affect the release process no matter when it's done. 
It could affect the flow of updates anytime (always some of which are
important, we have no way to tell everyone to not have major bugs or
security issues for a while. ;) 

>  I realize there are ~3 weeks between the proposed date and F23 beta
>  freeze and that there are going to be bumps in the road no matter
>  when the switchover happens. However, the tester in me is thinking
>  more along the lines of what might go wrong in the near future if the
>  more corner-casey stuff (freeze etc.) is hit so soon after deployment,
>  especially if there's a bug that's taken down the frontend for at
>  least a couple hours in addition to needing a database
>  wipe/repopulate 2 weeks before the proposed go-live date. 
Well, frankly the longer we wait the worse things are going to get.
The problem is that while we keep using bodhi1, Luke has to bandaid and
poke at it to keep it going with our needs, which means he's NOT
working on bodhi2, which means we run further behind. 

We failed completely to 'release early and often' with bodhi2, but
really IMHO we need to bite the bullet and get it done now that we are
close.

If we find anything that is obviously needing fixing before we roll it
out, we can delay, but I do not want to wait until after f23.

kevin