On Wed, Mar 21, 2018 at 8:00 AM, Ina Panova <[email protected]> wrote:
> +1 to keep RepositoryVersion. > > I also do not like the fact that it is quite long, that's why i do like > the Snapshot, but thinking more of what snapshot is - is something that > *you* need to trigger and it is not triggered automatically. > I'd say, we are working with repository versioning and not snapshots. > > Back to aptly, they use the term shapshot, which you need to manually > create https://www.aptly.info/doc/aptly/snapshot/create/ > > I see two main benefits for using the term 'snapshot': - this term is not unique to Pulp so it is easier to explain to the user - this term is mush shorter in length - there is only one form of it vs 2 (repo version and repository version) David, are you still a -1 on this? > > > -------- > Regards, > > Ina Panova > Software Engineer| Pulp| Red Hat Inc. > > "Do not go where the path may lead, > go instead where there is no path and leave a trail." > > On Tue, Mar 20, 2018 at 5:14 PM, Matthias Dellweg <[email protected]> wrote: > >> I guess, you meant 'RepositoryVersions' there. Maybe it is just a typo, >> or maybe your subconciousness already adepted to this change. ;) >> >> I'm +1, because from the REST API or model view, you do not ask what >> changed, but rather what is in that snapshot|version. >> And since you are renaming all models of pulp3 atm, you are giving a >> plugin maintainer a hard time, anyway. I think, it's now or never. >> >> Matthias >> >> On Tue, 20 Mar 2018 11:55:14 -0400 >> David Davis <[email protected]> wrote: >> >> > I’m not too worried about the change being too large. However, I >> > agree with @dalley though about snapshot not fitting my mental model >> > of how I view snapshots so any work seems like a loss to me. >> > >> > I’m at -1 but am happy to talk more about it. >> > >> > >> > David >> > >> > On Tue, Mar 20, 2018 at 11:08 AM, Daniel Alley <[email protected]> >> > wrote: >> > >> > > I think of a "snapshot" like a VM snapshot or a Windows restore >> > > point - an archival copy of a very fluid and non-discrete system at >> > > one point in time. By that understanding, the term >> > > RepositoryVersion probably fits better. >> > > >> > > I acknowledge the other benefits though. -/+0? >> > > >> > > On Tue, Mar 20, 2018 at 10:51 AM, Dennis Kliban <[email protected]> >> > > wrote: >> > > >> > >> The article you link to just says that "a snapshot is the state of >> > >> a system at a particular point in time". The point in time can be >> > >> now or in the past. >> > >> >> > >> The current state of a repository's content would be described as >> > >> the latest or most recent snapshot of a repository. >> > >> >> > >> I am not too worried about the pain of doing the refactoring across >> > >> multiple repos. >> > >> >> > >> On Tue, Mar 20, 2018 at 10:20 AM, David Davis >> > >> <[email protected]> wrote: >> > >> >> > >>> I have some reservations about using the name Snapshot. >> > >>> Specifically, I don’t think the snapshot term is a good fit. As >> > >>> wikipedia says [0], in CS a snapshot represents a state of >> > >>> something "in the past.” How would we describe the current state >> > >>> of the repository’s content then? I think "current version" would >> > >>> make sense but not "current snapshot.” >> > >>> >> > >>> Also, changing the code in pulpcore and plugins is going to be a >> > >>> pain. Especially with the other things we have planned like >> > >>> renaming Importers to Remotes. I think this should factor into >> > >>> our decision as well. >> > >>> >> > >>> [0] https://en.wikipedia.org/wiki/Snapshot >> > >>> >> > >>> >> > >>> David >> > >>> >> > >>> On Tue, Mar 20, 2018 at 10:05 AM, Austin Macdonald >> > >>> <[email protected]> wrote: >> > >>> >> > >>>> "Snapshot" is a nice way to explain what a RepositoryVersion is, >> > >>>> especially in the context of Publications. "Publish a >> > >>>> snapshot." I like the idea, and I informally floated it around >> > >>>> PulpCon but decided not to propose it because: >> > >>>> >> > >>>> - Snapshot is a little misleading about the actual data we >> > >>>> store. Specifically, since RepositoryVersions are stored as >> > >>>> diffs, when a user views the "content in a version", this is >> > >>>> calculated. This is a subtle point, and hopefully not user >> > >>>> facing at all, but I think snapshot implies a little bit more >> > >>>> certainty than we can offer. >> > >>>> - A snapshot also implies a slightly different workflow to >> > >>>> me. The workflow I expect with snapshots is to change >> > >>>> Repositories "willy nilly", and when you are satisfied, you >> > >>>> "take" an snapshot. Versions imply the workflow we have, which >> > >>>> is that any time the content set of a Repository is changed, a >> > >>>> new version is created. >> > >>>> >> > >>>> However, I think those concerns are minor and are overshadowed >> > >>>> by the potential benefits. Also, I see a direct connection to >> > >>>> the thread "Plugin relationship to tasks". The name >> > >>>> Snapshot/RepositoryVersion is part of the choice of how we >> > >>>> portray the changing of content set of a repo. >> > >>>> >> > >>>> 1. We can "change a repo" which creates a new version. >> > >>>> 2. We can "create a new version" which has different content. >> > >>>> >> > >>>> To me (1) implies "dispatching a task that has the side effect of >> > >>>> creating a new repository version. It would lend itself well to >> > >>>> the concept of "managing repositories" rather than "managing >> > >>>> versions/snapshots". If we choose this way, I think the name >> > >>>> Snapshot conceptually makes sense. >> > >>>> >> > >>>> (2) implies a POST to create a new RepositoryVersion. As >> > >>>> explained in the plugin tasks thread, there are some problems >> > >>>> with this, but it is similar to the concept of creating a git >> > >>>> commit. I think we wouldn't think of "creating a new Snapshot" >> > >>>> to change the content. >> > >>>> >> > >>>> On Tue, Mar 20, 2018 at 9:33 AM, Dennis Kliban >> > >>>> <[email protected]> wrote: >> > >>>> >> > >>>>> I propose that we rename the RepositoryVersion model in Pulp 3 >> > >>>>> to Snapshot. The REST API would also change to use >> > >>>>> /api/v3/repositories/<uuid>/snapshot/ >> > >>>>> >> > >>>>> The Snapshot name is a better description of what a repository >> > >>>>> version is and it is also much shorter in length. >> > >>>>> >> > >>>>> Thoughts? >> > >>>>> >> > >>>>> >> > >>>>> -Dennis >> > >>>>> >> > >>>>> _______________________________________________ >> > >>>>> Pulp-dev mailing list >> > >>>>> [email protected] >> > >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >> > >>>>> >> > >>>>> >> > >>>> >> > >>>> _______________________________________________ >> > >>>> Pulp-dev mailing list >> > >>>> [email protected] >> > >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >> > >>>> >> > >>>> >> > >>> >> > >> >> > >> _______________________________________________ >> > >> Pulp-dev mailing list >> > >> [email protected] >> > >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > >> >> > >> >> > > >> >> >> >> >> Herzliche Grüße aus München >> >> Matthias Dellweg >> ______________________________________________________ >> Dr. Matthias M. Dellweg >> >> (Open Source Software Engineer) >> >> Tel: +49 (0)89 452 35 38-12 >> Fax: +49 (0)89 452 35 38-290 >> E-Mail: [email protected] >> >> ATIX - The Linux & Open Source Company >> >> ATIX Informationstechnologie und Consulting AG >> Parkring 15 >> 85748 Garching bei München >> www.atix.de >> >> >> Registergericht: Amtsgericht München, Registernummer: HRB 168930 >> USt.-Id.: DE209485962 >> Vorstand: Thomas Merz (Vors.), Mark Hlawatschek >> Vorsitzender des Aufsichtsrats: Dr. Martin Buss >> >> _______________________________________________ >> Pulp-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
